CoursesKubernetes administrationArchitecture & Core Objects

Controllers & reconciliation

The loops that turn desired state into running pods.

Intermediate12 min · lesson 5 of 65
In plain terms
A controller is a thermostat: it constantly compares the temperature you set (what you want) to the room (what is) and nudges the heater until they match. Kubernetes is a whole house full of little thermostats.

The API server stores what you want; controllers make it true. Each controller watches its object type and drives actual state toward desired state in a loop. The scheduler is a specialized one — its only decision is which node a new pod runs on.

From Deployment to a running pod
1Deploymentdesired state2ReplicaSetctrlcreates pods3schedulerassigns a node4kubeletstarts it
Nothing pushes — each controller watches the API and reconciles. Delete a pod and the loop notices the gap and replaces it. Self-healing is just reconciliation.

The controller-manager is a single binary running dozens of these loops — Deployment, ReplicaSet, Node, Job, endpoints, and more. The scheduler runs as its own component because placement is a hard enough problem to deserve one.

You edit outcomes, not steps
kubectl edit changes desired state; the controller does the work to reach it. This is why there is no “restart” verb — you describe the end state and let reconciliation converge.