How a Simple Refrigerator Explains Kubernetes Controllers

Core Kubernetes Components

Kubernetes clusters consist of the etcd key‑value store, the API Server (cluster entry point), the Scheduler, the kube‑proxy, kubelet, and a set of Controllers that continuously reconcile desired state with actual state.

Refrigerator Analogy

A simple refrigerator is modelled with five subsystems: body, cooling system, lighting system, thermostat, and door. It provides two user‑visible functions:

Turn on the interior light when the door opens.

Adjust the cooling system temperature when the thermostat is set.

Unified Entry Point

The refrigerator exposes a single entry that offers two operations: Open/CloseDoor and SetThermostat. The entry updates the door state and thermostat configuration but cannot directly affect the light or cooling system.

Controller as a Bridge

A controller observes state changes on the entry and translates them into actions on the subsystems:

When the door state becomes Open, the controller turns on the interior light.

When the thermostat target temperature changes, the controller drives the cooling system to reach that temperature.

Controller Manager

Complex systems contain multiple independent controllers (e.g., lighting controller, cooling controller). A controller manager runs each controller in its own goroutine, monitors their health, and ensures they cooperate without interfering with each other.

SharedInformer

When many controllers need to watch the same resources, direct API Server queries create excessive load. SharedInformer acts as a proxy cache: it watches resources once, stores the latest state locally, and notifies each controller of events that match its interest. This reduces API Server traffic and latency.

ListWatcher

The core of SharedInformer is the ListWatcher mechanism, which combines:

List : an initial HTTP GET that retrieves the full set of objects.

Watch : a long‑running HTTP request using chunked transfer encoding. The API Server streams incremental changes as JSON objects in separate chunks, allowing controllers to react in near real‑time without re‑polling.

Real‑World Kubernetes Controllers

Typical in‑cluster controllers (Pod, Deployment, Service, ReplicaSet) are managed by kube-controller-manager. Cloud‑specific controllers (e.g., LoadBalancer Service, Route) are implemented in the cloud-controller-manager and interact with external APIs.

Service Controller

Workflow for a LoadBalancer Service:

User creates a Service of type LoadBalancer via the API Server.

API Server persists the Service object in etcd.

Service Controller watches the Service resource, detects the new LoadBalancer Service.

It calls the cloud provider’s OpenAPI to provision a cloud SLB (or equivalent).

It creates a corresponding Endpoints object that points to the SLB’s backend IPs.

Route Controller

When a new node joins the cluster, the Route Controller updates the VPC routing table to route traffic to the node’s Pod CIDR. The steps mirror the Service Controller: watch node events, invoke cloud‑provider APIs, and ensure the routing table reflects the current cluster topology.

Key Takeaways

Kubernetes controllers embody the “brain” of the cluster: they continuously observe desired state (stored in etcd), compute the required actions, and drive the actual state toward the goal. The controller manager orchestrates multiple controllers, while SharedInformer and ListWatcher provide efficient, scalable event delivery, preventing the API Server from becoming a bottleneck.