Kubernetes Architecture: Control Plane & Worker Nodes
Kubernetes is a declarative container orchestration platform. A cluster splits into control plane nodes (decision-making: API Server, etcd, Scheduler, Controller Manager) and worker nodes (execution:
Kubernetes is a declarative container orchestration platform. A cluster splits into control plane nodes (decision-making: API Server, etcd, Scheduler, Controller Manager) and worker nodes (execution: kubelet, kube-proxy, container runtime, Pods). The controller pattern -- watch-compare-reconcile -- is how Kubernetes achieves self-healing. This two-tier split is the single most important mental model.
-
Every component communicates exclusively through the API Server -- no component talks directly to another.
-
etcd is the only persistent store. The API Server is stateless and the only component with direct etcd access.
-
The controller pattern: controllers watch the API Server, compare desired state to actual state, and take reconciliation actions.
-
The Scheduler runs filter (eliminate impossible nodes) then score (rank remaining), and writes only a Binding.
-
Worker nodes are autonomous -- kubelets continue running containers even if the control plane is temporarily unavailable.
-
Production clusters run 3 or 5 control plane nodes (odd for Raft quorum) distributed across availability zones.
-
kubectl sends HTTPS request to the API Server.
-
API Server authenticates, authorizes (RBAC), runs admission controllers.
-
Validated object persisted to etcd.
-
Deployment controller creates ReplicaSet and Pods.
-
Scheduler assigns Pods to nodes via Binding.
-
kubelet starts containers via CRI on the bound node.
-
Pod marked Ready once readiness probes pass.
-
Understanding why Pending Pod events show FailedScheduling rather than kubelet failures.
-
Designing multi-AZ control plane topology for production HA.
-
Explaining why running Pods survive a brief control plane outage.
-
Run 3 control plane nodes minimum in production (tolerates 1 failure), 5 for higher availability.
-
Place control plane nodes in separate AZs to survive a zone failure.
-
Back up etcd regularly and test restore -- etcd loss without backup means total cluster state loss.
-
Monitor control plane health as first-class signals: API Server latency, etcd size.
-
Using an even number of control plane nodes -- 4 tolerates only 1 failure, same as 3 but with extra cost.
-
Assuming Pending Pod is a kubelet problem -- check Scheduler events first.
-
Expecting kubectl to work when the control plane is down.
-
Use dedicated etcd nodes at high object count or write rate.
-
Enable etcd compaction and defragmentation on a schedule.
-
Treat Kubernetes upgrades as planned, tested operations.
-
Run etcd with SSD-backed storage -- high etcd latency is the most common cause of a sluggish cluster.
-
Run kubectl cluster-info and identify the API Server endpoint.
-
Run kubectl describe node and explain Capacity vs Allocatable.
-
Trace the full path a kubectl apply request takes to a running container.
-
Control plane (API Server, etcd, Scheduler, Controller Manager) makes decisions; worker nodes execute.
-
etcd is the single persistent source of truth; API Server is stateless and the only component with direct etcd access.
-
The controller pattern (watch-compare-reconcile) is the mechanism behind self-healing.
-
Running Pods survive a control plane outage -- kubelets are autonomous.
-
Production control planes run 3 or 5 nodes distributed across availability zones.
Want a visual for this concept?
Generate a diagram tailored to “Kubernetes Architecture: Control Plane & Worker Nodes” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.
Sign in to generate a visual →