Cluster architecture
Control plane vs worker nodes, and the components on each.
In plain terms
Think of a restaurant. The control plane is the manager and the order book — it decides and remembers, but never cooks. The worker nodes are the kitchen line — they cook, but make no decisions. Neither does the other’s job, on purpose.
A Kubernetes cluster is two kinds of machine working together. Control-plane nodes make decisions and store state; worker nodes run your containers. As an administrator you live on the boundary between them, so start by knowing exactly what runs where.
API requestetcd writeetcd readrun workloaduser traffic
On kubeadm clusters the control-plane components run as static pods, started by the kubelet from /etc/kubernetes/manifests — which is where you go to repair them.
The control plane never runs your workloads and the workers never make scheduling decisions. That separation is deliberate: a runaway pod can never starve the components that keep the cluster alive.
Know your control-plane count
A single control-plane node means one etcd and one API server — lose it and the cluster is frozen. Production runs three or five, so a quorum of etcd members always survives one failure.