Reconciliation Loop & Declarative Model
You declare desired state (YAML). Controllers continuously compare desired state to actual state and take action to close the gap.
Reconciliation = a thermostat. You declare 72 degrees (desired state). The thermostat constantly checks: too cold? Heat. Too hot? Cool. It doesn't remember what it did last — it just reads the thermometer and acts. Kubernetes is a thermostat for infrastructure.
Every Kubernetes resource has a spec (desired) and a status (actual). Controllers watch the API server for changes to their resource type, read the current state, compare to desired, and take actions. This is level-triggered (not edge-triggered) — controllers react to the current state, not events. This means controllers are idempotent and self-healing by design. If a controller crashes and restarts, it re-reads all state and converges to the right answer.
The watch mechanism: controllers use the API server's watch API (long-polling with resource version). Informers (client-go) provide a local cache + watch for efficiency. The reconcile loop: observe (read current state), diff (compare to desired), act (create/update/delete resources). Custom controllers (operators) follow the same pattern. The operator pattern: encode domain knowledge about managing stateful applications (PostgreSQL, Kafka) into a controller that automates Day-2 operations like backups, failover, schema migrations. Finalizers prevent resource deletion until cleanup actions complete — preventing orphaned resources.
Kubernetes is declarative — you tell it what you want, not how to do it. Controllers run infinite reconcile loops: read desired state from spec, read actual state, compute the diff, take action. This makes the system self-healing: if a pod crashes, the ReplicaSet controller sees 'desired=3, actual=2' and creates a new pod. This model means you can safely apply the same YAML repeatedly — it converges, not accumulates.
kubectl apply is not a one-time command — it's a declaration. If the current state differs from the desired (because someone manually changed something), the next apply will correct it. This is why direct kubectl edit in production is dangerous — the next apply overwrites it.