The reconciliation loop is the engine of everything.

Observe, compare, act, repeat forever. Every controller in Kubernetes is a variation on this loop.

Imperative

"Run these steps in this order." If step 3 fails, or the start state differs, the result is unpredictable.

Declarative

"This is the end state." Apply it a thousand times: same result, any starting point.

Process-control analogy

A plant's PID loop does not "open the valve once". It measures the process variable, compares it with the setpoint and adjusts continuously. Kubernetes controllers are control loops where the setpoint is your YAML.

Self-healing is not a feature: it is what a control loop does when a pod disappears.

Declare the state; controllers close the gap

This is the most important idea in Kubernetes. A controller is a loop that watches the actual state of some objects, compares it to the desired state recorded in the API, and takes the smallest action to close the gap. Then it does it again. A Deployment controller asked for three replicas that sees two creates one more. If it sees four, it deletes one. If it sees three, it does nothing.

Contrast this with imperative operation. A script that says create three servers, install the app, add to load balancer, works only once and only from the state the author imagined. A declarative system stores intent; the loop converges from wherever reality currently is. That convergence property makes kubectl apply idempotent and is why you can safely re-run it from CI.

The analogy for a professional audience is industrial process control: a PID controller holding a setpoint. The thermostat analogy is the same idea. Because the loop runs continuously, healing a crashed pod needs no special code path: the next iteration sees a gap and fills it.

Watch the animated packets circle the loop: observation, comparison, action, then back to observation.