Control Plane and Worker Nodes
Control Plane and Worker Nodes
Kubernetes splits into two planes: the control plane decides what should run; worker nodes run it.
Control plane, typically on dedicated machines:
- kube-apiserver — the only component allowed to write etcd; everything else watches it.
- etcd — consistent key-value store; the cluster's source of truth.
- kube-scheduler — chooses a node for each unscheduled pod.
- controller-manager — reconciliation loops for Deployments, nodes, services, and more.
On every node:
- kubelet — reports the node, starts pods through the runtime, updates status.
- kube-proxy — programs Service routing as iptables or IPVS rules.
- container runtime — containerd or CRI-O behind the CRI interface.
apiserver, scheduler, and etcd each run as leader-elected or quorum replicas; losing one member is survivable.
A Request's Round Trip
A Request's Round Trip
Follow kubectl apply -f deploy.yaml:
- kubectl sends the manifest to kube-apiserver on 6443.
- Authentication, authorization, and admission validate and mutate it; the object is written to etcd.
- The Deployment controller sees the new object and creates a ReplicaSet, which creates a Pod.
- The scheduler binds the pod by setting
spec.nodeName. - kubelet on that node observes the pod, pulls the image, and starts the containers.
- kubelet reports
status— conditions, pod IP, restart counts — back through the API.
kubectl get events --sort-by=.lastTimestamp
Events are the human-readable trace of steps 3 through 5 when something stalls.
Where High Availability Matters
Where High Availability Matters
Pitfall 1 — a lone etcd. etcd holds all state; losing it stops every write. Run an odd-sized quorum (3 or 5), snapshot with etcdctl snapshot save, and rehearse the restore before an incident demands one.
Pitfall 2 — over-provisioning the control plane. The scheduler and controllers are stateless and leader-elected, and apiserver scales horizontally behind a load balancer. Capacity limits usually come from kubelet and node resources, not the control plane.
Interview-ready: walk a pod from YAML to running container in six steps, then answer the failure question — apiserver downtime blocks new writes, but running pods keep working because kubelet and existing routing depend on no continuous API traffic.
Quiz
1. Which component is the only one permitted to write to etcd?
2. What does kube-proxy do on each node?
3. Why run an odd number of etcd members?
Flashcards
Question
Control plane components
Click to reveal answer
Answer
kube-apiserver, etcd, kube-scheduler, controller-manager (plus cloud-controller-manager when used).
Question
Node components
Click to reveal answer
Answer
kubelet, kube-proxy, and the container runtime (containerd or CRI-O).
Question
Request path for kubectl apply
Click to reveal answer
Answer
kubectl → apiserver (auth, admission) → etcd → controllers → kubelet on the target node.
Question
apiserver outage impact
Click to reveal answer
Answer
No new writes or watches; running pods continue since kubelet keeps reconciling locally.
Revision Notes
Key Takeaways
- 1. Everything talks to the API server; nothing but backups touches etcd directly
- 2. Controllers and schedulers are stateless loops — HA means replicas plus leader election
- 3. Node identity comes from kubelet registration and reported status
Interview Tips
- • Name components with their verbs: apiserver persists, scheduler binds, kubelet runs, kube-proxy routes
- • Describe failure blast radius: etcd = writes stop, scheduler = new pods wait, kubelet = that node stops reporting
Cheat Sheet
Control plane: apiserver (writes etcd), etcd (truth), scheduler (binds), controller-manager (reconciles). Nodes: kubelet runs pods, kube-proxy routes Services, runtime via CRI.