> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Lab Solution Run Observe And Test Reconciliation Boundaries
> Shows a Kubernetes controller that recreates missing child resources from a WebApp blueprint but does not repair in-place spec drift of existing child resources
This lesson demonstrates the reconciliation boundaries of a Kubernetes-style controller: it will recreate a missing child resource derived from a WebApp blueprint, but it does not automatically repair an existing child that has drifted from the blueprint. The steps below provide reproducible evidence for both behaviors by running the controller locally and performing targeted changes in the cluster.
Observe controller logs
* Start your local manager (for example, `make run` or your preferred controller run command).
* Keep the logs visible so you can observe reconcile events while you perform the changes below.
Step 1 — Apply the namespace and WebApp blueprint
* The WebApp resource is the blueprint. The controller should create the Deployment, Service, and ConfigMap from that spec.
```bash theme={null}
# Apply namespace and WebApp blueprint, then wait for the deployment to become available
kubectl apply -f ../webapp-demo-namespace.yaml
kubectl apply -f config/samples/webapp-blog.yaml
kubectl -n webapp-demo wait --for=condition=Available deploy/blog --timeout=120s
kubectl -n webapp-demo get webapp blog
# NAME AGE
kubectl -n webapp-demo get deploy blog
# Shows the deployment created by the controller (expected 3 replicas based on the WebApp spec)
```
Step 2 — Delete the Deployment (missing-child behavior)
* Deleting the Deployment demonstrates that the reconciler will recreate missing children based on the WebApp blueprint.
```bash theme={null}
kubectl -n webapp-demo get cm blog-config
# NAME DATA AGE
kubectl -n webapp-demo delete deploy blog
# Wait for the controller to recreate the deployment from the WebApp spec
kubectl -n webapp-demo wait --for=condition=Available deploy/blog --timeout=120s
kubectl -n webapp-demo get deploy blog
# deployment restored with 3 replicas (recreated from the blueprint)
```
Step 3 — Scale the existing Deployment to zero (in-place drift)
* Scaling the existing Deployment to zero simulates spec drift while the child resource still exists. In this controller implementation, the reconciler creates missing children but does not patch existing children to match the blueprint. Therefore the controller will not change the replica count back to three when the Deployment exists but has been modified.
```bash theme={null}
kubectl -n webapp-demo scale deploy/blog --replicas=0
sleep 10
kubectl -n webapp-demo get deploy blog
# Shows the deployment with 0 replicas (the controller did not patch it back to 3)
```
Step 4 — Delete the drifted Deployment and wait for recreation
* Now delete the modified (drifted) Deployment. Because it becomes a missing child again, the controller will recreate it from the WebApp spec with three replicas, restoring the application's baseline.
```bash theme={null}
kubectl -n webapp-demo delete deploy blog
kubectl -n webapp-demo wait --for=condition=Available deploy/blog --timeout=120s
kubectl -n webapp-demo get deploy blog
# deployment restored with 3 replicas (recreated from the blueprint)
```
Summary table — behavior comparison
| Scenario | Controller behavior | Notes |
| --------------------------------------------------------------- | ----------------------------------: | ----------------------------------------------------------------------------------------------------------------- |
| Deleted child resource (missing child) | Recreated from the WebApp blueprint | Controller observes no child and creates one to match the desired state. |
| Existing child resource with spec drift (in-place modification) | Not patched to match blueprint | Controller only created missing children in this implementation; it does not compare-and-patch existing children. |
This demonstrates the controller's reconciliation boundary: it heals missing child resources by recreating them from the blueprint, but it does not repair in-place drift of existing child resources (for example, it will not scale an existing Deployment back to the blueprint's replica count).
If you need automatic correction of in-place drift (for example, enforcing replica counts, updating image fields, or reconciling any spec drift), extend the reconciler logic to compare and patch existing children to match the desired blueprint spec rather than only creating missing children.
Links and references
* [Kubernetes Controllers and Operators](https://kubernetes.io/docs/concepts/architecture/controller/)
* [Kubebuilder book — Writing a Controller](https://book.kubebuilder.io/)
* [Reconciliation Pattern (controller-runtime)](https://pkg.go.dev/sigs.k8s.io/controller-runtime)