Kubernetes Architecture

How a cluster is wired: a control plane (kube-apiserver, etcd, scheduler, controller-manager, cloud-controller-manager) coordinating worker nodes (kubelet, kube-proxy, container runtime) through the pluggable CRI, CNI and CSI interfaces. Covers etcd Raft consensus, HA control-plane sizing, and managed offerings versus self-managed installers.

Overview

Almost every "how does X work in Kubernetes" question resolves to the same answer, and it is worth learning that answer once rather than memorising the surface of each feature.

Kubernetes is a closed reconciliation loop. A client writes *desired* state to the API server. The API server validates it, persists it to etcd, and emits a watch event. Controllers observe that event, compare desired state against what they observe in the world, and write back the next step. Nothing in the system pushes commands at nodes; nodes pull the work that has been assigned to them. That is why Kubernetes recovers from a control-plane outage without losing running workloads, why a deleted Pod comes back, and why "it eventually converged" is the normal failure mode rather than a hard error.

The control plane is five processes and the node is three, plus three plugin interfaces that vendors implement. Once you can name each one, say what it owns, and describe what breaks when it stops, you can reason about most cluster behaviour from first principles. This topic covers those components, how they talk to each other, and how the whole thing is laid out for high availability.

One structural note worth carrying: the API server is the only component that talks to etcd. Every other component — controllers, scheduler, kubelet, your kubectl — goes through the API. That single chokepoint is what makes authentication, authorization, admission control and audit tractable, and it is why an API server outage looks like "nothing can change" rather than "everything falls over".

Kubernetes Architecture

Overview

More DevOps topics