Introduction to Kubernetes Controllers

A single Pod is an ephemeral unit. If the node it runs on fails, the Pod is lost, and the application it serves goes down with it. To build resilient systems, we need a mechanism that actively works to maintain our application's availability without constant manual intervention.

This is where Kubernetes controllers come into play. A controller is a background process that watches the state of your cluster and works to move the current state towards a desired state. Think of it as an automated thermostat for your cluster resources. You set the desired temperature (the state you want), and the thermostat continuously acts to maintain it, turning the heat on or off as needed.

The Reconciliation Loop

At the heart of every controller is a process known as a reconciliation loop or control loop. This is not a single, monolithic piece of code but rather a design pattern that governs how controllers operate. This loop continuously performs a simple, yet powerful, sequence of operations:

1. Observe: The controller connects to the Kubernetes API Server to get the current state of the resources it is designed to manage. For example, a controller managing Pods will ask, "How many Pods with the label app=my-api are currently running?"
2. Compare: It compares this observed state against the desired state, which is defined in the manifest file you provide. If your manifest specifies replicas: 3 but the controller only observes two running Pods, a mismatch exists.
3. Act: If the current state does not match the desired state, the controller takes corrective action through the API Server. In the example above, it would send a request to the API Server to create one new Pod to satisfy the replicas: 3 requirement. Conversely, if it observed four Pods, it would terminate one.

This loop runs indefinitely, ensuring that even if a Pod is terminated or a node fails, the controller will detect the deviation and work to correct it.

A controller's reconciliation loop. It continuously observes cluster state via the API server, compares it to the desired state stored in etcd, and acts to close any gap.

This control loop is the engine that powers the declarative model in Kubernetes. When you execute kubectl apply with a YAML manifest, you are not issuing direct commands. Instead, you are updating the desired state record in etcd. The controllers notice this change and take on the responsibility of making the cluster's actual state match your declaration.

Kubernetes is built on a collection of these controllers. The kube-controller-manager, a core control plane component, runs many of them, such as the Node Controller (which handles node failures) and the ServiceAccount Controller. For managing application workloads, we primarily interact with controllers like ReplicaSets, Deployments, StatefulSets, and DaemonSets. In this chapter, we will focus on the two most common controllers for stateless applications: ReplicaSets and Deployments.

We will begin with the ReplicaSet, which provides a clear and direct example of a controller's function: ensuring a stable number of Pods are always running.