Controllers | Kubernetes

article Kubernetes Project Apr 6, 2026

Kubernetes documentation page explaining the controller pattern. A controller is a non-terminating control loop that watches cluster state via the API server and acts to move actual state toward desired state. Controllers are simple and independent — many small controllers rather than one monolithic loop. The cluster never reaches a stable state; correctness means controllers are running and making progress, not that everything is settled.

Backlinks

A reconciliation loop continuously observes actual state, compares it to desired state, and takes the minimum action to close the gap. If actual drifts — the loop corrects automatically. →

Controller Pattern A controller is a loop that watches the declared desired state of a resource, observes actual state, and takes the minimum action to close the gap. It runs continuously and never terminates (Kubernetes docs). →

Controller Pattern Controllers compose: one controller's output becomes another's input. A Deployment controller creates ReplicaSets; the ReplicaSet controller creates Pods; the kubelet runs containers. Each level is a separate controller with its own reconciliation loop (Kubernetes docs). →

Kubernetes Controllers The Kubernetes docs define a controller as a non-terminating control loop that watches cluster state and acts to bring it closer to the desired state (bib). →

Feedback Loops

Controller Pattern — watch, diff, reconcile: the generic loop
Kubernetes Controllers — K8s implementation: many simple controllers via API server (bib)
Perpetual Disequilibrium — the system never settles, and that's correct
2039568269989036219 — desired state systems = feedback control: sensor is observation, comparator is diff, actuator is API call
2039569197378965946 — Kubernetes standardized this: CRDs + controllers for any desired state
2039302841450537164 — desired state wraps mutable with declarative (Jenco)
2039308018211586082 — NixOS as a particular case of desired state
2039290956810448985 — NixOS: describe desired, compute path to it

→

Open-Loop vs Closed-Loop Systems

Open-loop — React assumes sole ownership of the DOM. It does not re-read actual DOM state; if another script mutates the DOM, React will not detect or fix it.
Closed-loop — Terraform checks actual infrastructure against the saved plan, detecting drift caused by manual changes or other tools.
Closed-loop, continuous — Kubernetes runs reconciliation controllers in a permanent loop. Delete a pod and the controller immediately recreates it (xettel, K8s docs).

→

Perpetual Disequilibrium A desired state system with continuous reconciliation may never reach a stable state — and that is by design. The Kubernetes docs state: "your cluster could be changing at any point" and "it doesn't matter if the overall state is stable or not" as long as controllers are running and making useful changes (bib). →