Kubernetes Reconciliation Loop: CNPA practice questions

The reconciliation loop is the core mechanism behind Kubernetes and behind most platform tooling built on it. The Kubernetes documentation explains it with a thermostat: you set a desired temperature, the room has a current temperature, and the thermostat turns equipment on or off to bring the current state closer to the desired one. A Kubernetes controller is a non-terminating control loop that watches the state of the cluster and makes or requests changes to move the current state toward the desired state.

Each controller tracks at least one resource type. Those objects have a spec field that represents the desired state, and the controller is responsible for making reality match it, while the status describes the current state as the system observes it. Most built-in controllers do not touch containers or machines themselves; they send requests to the API server, and other components act on the result. The Job controller, for example, does not run Pods. It tells the API server to create or remove Pods so the right number run, other parts of the control plane schedule and start them, and when the work is done the controller updates the Job object to mark it finished.

Some controllers manage things outside the cluster. A controller that adds nodes when more capacity is needed finds its desired state in the API server, talks directly to an external system to change reality, and then reports the current state back to the API server. This is the same pattern Crossplane and other infrastructure controllers use to manage databases or networks through Kubernetes objects.

Several design points are worth remembering. Kubernetes uses many simple controllers, each managing one aspect of cluster state, rather than one monolithic set of interlinked loops, and it is designed to cope with controllers failing; the built-in ones run inside kube-controller-manager. Several controllers can create the same kind of object, for example Deployments and Jobs both create Pods, and they use information such as labels to act only on the objects that belong to them. The documentation also notes that, because work and failures keep happening, a cluster may never reach a stable state, which does not matter as long as the controllers keep making useful changes. The CNCF Operator White Paper adds that a good reconciliation loop cares not only about the end state but also about how the transition between states happens.

For platform teams, the loop explains self-healing: delete a Pod managed by a Deployment and a replacement appears, because the desired replica count has not changed. It also explains drift correction in GitOps, where agents such as Argo CD and Flux apply the same idea with a Git repository as the source of desired state.

Misconceptions include thinking a controller acts once at creation time and then stops, expecting a manual edit to a managed object to persist while its owner keeps reconciling it, and assuming the API server itself carries out the work rather than the controllers watching it.

Associate-level questions typically describe a change or a failure and ask which component reacts, what the desired and current states are, or why a modified resource returns to its previous configuration.