The Kubernetes reconciliation loop

WHAT THIS TESTS This checks whether you understand the declarative control loop that gives Kubernetes its self-healing behavior.

A GOOD ANSWER COVERS A reconciliation loop is a continuous process: observe the actual state of the world, compare it against the desired state declared in an object's spec, and take action to drive actual toward desired, then repeat. Crucially it is level-triggered, meaning it acts on the current difference between desired and actual rather than reacting only to discrete events; this makes it robust to missed events, restarts, and drift because the next pass simply re-evaluates reality. The ReplicaSet controller embodies this: it watches Pods matching its selector, counts how many exist, and compares to the desired replica count. If too few exist it creates Pods; if too many, it deletes some. When a Pod dies, the next reconciliation observes the shortfall and creates a replacement, which is why workloads self-heal without explicit intervention.

COMMON WRONG ANSWERS Describing it as a one-time imperative action. Saying it is purely edge-triggered and only fires on events, which would miss drift. Confusing the controller with the scheduler. Thinking it requires manual reconciliation.

LIKELY FOLLOW-UPS What is the difference between level-triggered and edge-triggered? How does a controller watch for changes? What is the controller-manager? How does this pattern extend to Operators?

ONE CONCRETE EXAMPLE A ReplicaSet desires three replicas and three Pods run. A Node fails and one Pod disappears, so actual is two. On its next reconciliation, the ReplicaSet controller observes two against the desired three, creates one new Pod, and the scheduler places it on a healthy Node. State converges back to three without anyone intervening, and the same loop would delete a Pod if someone manually created a fourth.