Cluster Architecture
What are the moving parts of a Kubernetes cluster, and how do they talk? One contract runs under all of it: desired state lives in ETCD behind the API, the single front door, and the controllers and Scheduler compare it against observed state and loop until the gap closes. A Kubelet on every worker Node reconciles the same way and brings Pods to life, and kube-proxy programs Service rules beside it, while in a standard cluster only the API talks to ETCD.
Play the animation 7 steps, animated, best on a wide screen
Cluster Architecture, step by step
-
The API is the only way in for clients and controllers. Every read and every write passes through it, and a write clears authentication, authorization and admission before it is stored. Replicas are stateless and scale horizontally. The one path that skips it is a static Pod, which the Kubelet reads from a local file or a URL.
Play from step 1 -
ETCD holds the cluster state the API serves, and in a standard cluster the API is the only client it has. Every change is replicated through Raft, where a quorum of replicas must agree before the write is committed and the revision moves forward.
Play from step 2 -
On the way back ETCD serves reads to the API, which is a separate exchange rather than the answer to that write. A watch keeps the stream open and pushes later changes through it without another round trip. Clients watch the API, never ETCD, and it answers them from its own cache.
Play from step 3 -
The controller-manager runs the built-in control loops, roughly one per resource kind (Deployment, ReplicaSet, Job and so on), plus loops that cut across all of them like the garbage collector. Each watches the API, never ETCD, and writes back to reconcile observed state with desired state.
Play from step 4 -
The cloud-controller-manager runs the loops that talk to a cloud provider: Node lifecycle, cloud routes and Service load balancers. It is optional and a cluster on your own hardware has none. It writes what it learns back to the API, and it is split out so provider code lives outside the core.
Play from step 5 -
The Scheduler watches Pods that have no Node assignment yet, filters and scores the candidates, then posts a Binding back to the API. On the ordinary path that one write is all it does, and preemption is the exception where it also deletes victims. The Kubelet on the chosen Node takes it from there.
Play from step 6 -
The Kubelet watches the API for Pods assigned to its Node, then calls the Runtime over CRI to start their containers, and PATCHes Pod status back so the loops above have observed state to compare. Beside it kube-proxy watches the API on its own, for Services and EndpointSlices, and programs the local rules. It is optional too, and an eBPF dataplane can replace it.
Play from step 7