Understanding Kubernetes Controllers and the Reconciliation Loop Pattern

Pods serve as an abstraction layer over containers, providing additional metadata and composition capabilities. While container images encapsulate applications effectively, the standalone container concept lacks the structural properties needed for comprehensive application management. Pods address this limitation by grouping containers together and attaching essential configuration fields, enabling Kubernetes to manage workloads systematically.

The logic governing how Kubernetes manages these workloads resides within Controllers. Consider a standard Deployment manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server-deployment
spec:
  selector:
    matchLabels:
      tier: frontend
  replicas: 3
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: web-server
        image: nginx:1.7.9
        ports:
        - containerPort: 80

This Deployment ensures that the count of Pods matching the label selector tier=frontend always matches the spec.replicas value of 3. When the number of matching Pods exceeds the desired count, the controller removes excess instances; when the count falls short, new Pods are created to reach the target.

The kube-controller-manager component houses various controllers, each responsible for specific orchestration tasks:

$ cd kubernetes/pkg/controller/
$ ls -d */
deployment/         replicaset/        statefulset/
job/                cronjob/           daemon/
garbagecollector/   namespace/         serviceaccount/
...

Every controller in this directory implements a common orchestration pattern known as the control loop. This pattern can be expressed conceptually:

while (true) {
    currentState := fetchActualStateFromCluster(objectType)
    desiredState := fetchDesiredStateFromSpec(objectType)
    
    if (currentState.equals(desiredState)) {
        continue
    }
    
    reconcile(currentState, desiredState)
}

The actual state derives from the live cluster environment—kubelet heartbeats reporting container status, node health metrics, or monitoring data. The desired state originates from user-submitted manifests stored in etcd, such as the replicas field in a Deployment specification.

The Deployment controller executes this pattern through three key phases:

Observation: Query all Pods matching the label selector and count them to determine actual state.
Comparison: Compare the actual count against the spec.replicas value representing desired state.
Reconciliation: Execute create or delete operations to align actual state with desired state.

The comparison and adjustment phase is called Reconcile, and the iterative process is known as the Reconcile Loop or Sync Loop. All actions within this framework ultimately result in write operations—creating, updating, or deleting API objects.

This architecture embodies the principle of one object managing another. The controller object defines the desired state, while the controlled objects are instantiated from a template. The template field in a Deployment, formally called a PodTemplate, contains a complete Pod specification. Every Pod created by the controller derives from this template.

Each API object includes an ownerReference field in its metadata, establishing hierarchical relationships between resources. This mechanism enables garbage collection and cascade deletion behaviors essential for resource lifecycle management.

Tags: kubernetes Controllers deployment Control Loop reconciliation

Posted on Tue, 20 Oct 2026 16:00:54 +0000 by jmr3460

Freaks City

Understanding Kubernetes Controllers and the Reconciliation Loop Pattern

Hot Tags