Kubernetes Controllers

source
kubernetescontrollersdesired-statereconciliation

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).

Controller pattern

Each controller implements the controller pattern:

  1. Watch at least one resource type via the API server
  2. Read the resource’s .spec (desired state)
  3. Observe actual state (.status or dependent resources)
  4. Take the minimum action to close the gap

Most controllers do not act directly — they send messages to the API server (e.g. “create a Pod”), and other components carry out the work. This indirection decouples intent from execution.

Design philosophy

Kubernetes runs many simple, independent controllers rather than one monolithic loop. Each controller manages one aspect of cluster state. This means:

  • Controllers can fail independently without taking down the whole system
  • Multiple controllers can create the same kind of object (e.g. Deployments and Jobs both create Pods) — labels disambiguate ownership
  • The system is resilient: if a built-in controller fails, another part of the control plane takes over

Perpetual disequilibrium

The docs state explicitly: “your cluster could be changing at any point” and “potentially, your cluster never reaches a stable state.” This is not a bug — it is the design. Correctness means the controllers are running and making useful changes, not that the system has settled. See perpetual disequilibrium.

Extensibility

Controllers can be built-in (kube-controller-manager) or external. Custom Resource Definitions (CRDs) + custom controllers let anyone extend Kubernetes with new desired-state resource types (xettel).

Sources