Kubernetes Controllers: The Reconciliation Loop

WHY IT EXISTS: Kubernetes is built on declarative configuration to achieve automation and resilience. Instead of issuing imperative commands like "run pod X," you declare a final state like "I want 3 of pod X running." The controller pattern is the mechanism that makes this declarative approach work, freeing operators from constant manual intervention and enabling self-healing systems.

THE MENTAL MODEL: Think of a controller as a thermostat for your cluster. You set a desired temperature (the spec in a manifest file). The thermostat constantly checks the room's current temperature (the actual state of the cluster). If there's a difference, it takes action—turning on the heat or AC—to "reconcile" the actual state with the desired state. You don't tell it how to do its job, only the goal.

HOW IT WORKS: A controller runs a continuous "reconciliation loop." First, it watches the API server for changes to a specific resource type, like a Deployment. Second, for each object, it compares the desired state defined in the object's spec field with the actual state of the cluster (e.g., how many pods are actually running). Third, if there's a discrepancy, the controller makes API calls to create, update, or delete other objects (like Pods) to drive the actual state towards the desired state. This loop never ends, ensuring the system is always converging on the declaration.

WHEN TO USE IT: This pattern is fundamental to Kubernetes. You use it implicitly with every Deployment, ReplicaSet, StatefulSet, or DaemonSet. You would build your own controller (often called an Operator) to manage complex, stateful applications declaratively, encoding operational knowledge into software.

WHEN NOT TO USE IT: The controller pattern is for maintaining a continuous state. For tasks that should run once and terminate, like a database migration script or a batch processing job, use a Kubernetes Job or CronJob. Using a Deployment for a one-off task is an anti-pattern, as the controller would try to restart it after it completes.

ONE CANONICAL EXAMPLE: The ReplicaSet controller is the classic example. Its sole purpose is to ensure a specified number of Pod replicas exist. If its spec says replicas: 5 but it only finds 4 matching Pods, it will create a new one. If it finds 6, it will terminate one to reconcile the state. The key is that you never interact with the ReplicaSet controller directly; you just create the ReplicaSet object and trust the controller to do its job.