Skip to main content

The control plane: how Kubernetes thinks

You've been declaring desired state — "5 pods of this image" — and Kubernetes has been making it real. This final lesson opens the hood: what inside Kubernetes actually does that? The answer is an architecture split into a control plane (the cluster's brain) and worker nodes (where your containers run), tied together by a single, elegant idea — the reconciliation loop — that you've already met three times in this guide. Understanding this turns Kubernetes from magic into a system you can reason about and debug.

The two halves of a cluster​

A Kubernetes cluster is a set of machines (nodes) working together, divided into two roles:

API server\n(thefront door)("etcd\nthecluster's memory\n=desired state")Scheduler\n(placespods on nodes)Controllers\n(reconcile desired vsactual)kubelet → runs podskubelet → runs pods
  • The control plane is the brain. It makes all the decisions: what should run, where, and whether reality matches your wishes. It doesn't run your app containers itself (in managed Kubernetes, the provider runs the control plane for you).
  • The worker nodes are the muscle. These are the machines that actually run your pods. Each has an agent (the kubelet) that talks to the control plane and runs the containers it's told to.

Inside the control plane​

Four components do the brain's work:

  • The API server is the front door to the entire cluster. Everything goes through it — your kubectl commands, every internal component, every status update. When you "apply a deployment," you're sending it to the API server. It's the single point of contact, and it's where your declared desired state enters the system.
  • etcd is the cluster's memory: a reliable key-value database that stores the desired state — every object you've declared (deployments, services, config) and the cluster's current status. If the API server is the front door, etcd is the filing cabinet holding the source of truth. (Because it holds everything, etcd is the most critical thing to back up.)
  • The scheduler answers "where should this pod run?" When a new pod needs a home, the scheduler examines the nodes — their free capacity, constraints, and rules — and assigns the pod to the best-fitting node. It solves the scheduling problem from lesson 4.1.
  • Controllers are the engines of reconciliation. Each controller watches the desired state for some object type and works to make reality match it. The deployment controller, for instance, watches "I want 5 pods"; if it sees only 4 running, it creates one more. Controllers are why Kubernetes self-heals and scales.

On each worker node: the kubelet​

Every worker node runs a kubelet — an agent that registers the node with the control plane, receives instructions ("run this pod here"), starts and stops the containers accordingly, and continuously reports each pod's health back to the API server. The kubelet is the hands that carry out the brain's decisions, and the eyes that report what's actually happening.

The reconciliation loop: the one idea behind it all​

Now the payoff. Everything Kubernetes does runs on a single, continuous loop:

Desired state\n(whatyoudeclared,\nstored inController comparesActualstate\n(what'sreallyTake action\ntoclose the gapDo nothing,\nkeepwatchingthey differthey match

Forever, Kubernetes:

  1. Reads the desired state (your declarations in etcd).
  2. Observes the actual state (what the kubelets report is really running).
  3. If they differ, takes action to close the gap — start a pod, kill a pod, reschedule onto a healthy node.
  4. Repeats, continuously.

That's it. A pod crashes → actual drops to 4, desired is 5, the controller starts one → reconciled. A node dies → its pods vanish from actual, the controller reschedules them elsewhere → reconciled. You raise replicas to 20 → desired jumps, the controller and scheduler create 15 more → reconciled. Self-healing, scaling, and rolling updates are all the same loop, never a special case.

:::tip You have seen this loop three times now The declare-desired-state, reconcile-to-match loop is the throughline of this guide. It's how Terraform (Chapter 3) provisions infrastructure (declare resources, apply the diff), how Kubernetes runs containers (declare pods, controllers reconcile), and — next chapter — how GitOps (Chapter 5) deploys software (declare in git, an agent reconciles the cluster). Recognizing it as one durable idea in three places is a genuine level-up: once you see it, the entire modern cloud stack looks coherent instead of like a pile of unrelated tools. :::

Why it matters​

A Kubernetes cluster splits into a control plane (the brain: the API server as the single front door, etcd as the memory holding desired state, the scheduler placing pods, and controllers driving reconciliation) and worker nodes (the muscle, each running a kubelet that runs containers and reports health). All of it runs one reconciliation loop: read desired state, observe actual state, act to close the gap, repeat — which is why the cluster self-heals, scales, and updates without you scripting any of it. That loop is the same declarative idea behind Terraform and, next, GitOps — one durable principle unifying the modern cloud. A checkpoint locks in Kubernetes, and then the guide moves from building and running to delivering and operating in the outlined chapters ahead.

Next: Chapter 4 checkpoint →