Day 47: Control plane overview: API server, scheduler, controllers
The declarative model
You never tell Kubernetes *how* to do something — you declare the desired state (e.g. "3 replicas of this container running"), and a set of controllers continuously compares desired state against actual state, taking action to close any gap. This reconcile loop pattern is the single most important mental model in all of Kubernetes.
The control plane components
- API server — the front door; every read/write, from kubectl or any controller, goes through it as REST/JSON, validated and persisted
- etcd — the cluster's single source of truth, storing all desired/actual state (Day 48)
- Scheduler — watches for newly created Pods with no node assigned, and picks a node for them based on resource fit and constraints
- Controller manager — runs the many reconcile loops (Deployment controller, ReplicaSet controller, Node controller...) that make actual state match desired state
Everything is a controller
There isn't one 'Kubernetes brain' — there are dozens of small, independent controllers, each watching one narrow slice of state and reconciling it. This is exactly the pattern you'll implement yourself in Phase 29 when you build a tiny custom operator.
kubectl get pods -n kube-system
# You'll see kube-apiserver, etcd, kube-scheduler, kube-controller-manager as actual podsKey terms
- Reconcile loop
- A controller's continuous cycle of comparing desired vs actual state and acting to close the gap.
- API server
- The single entry point for all reads/writes to cluster state.
- Scheduler
- Assigns newly created, unscheduled Pods to a specific node.
You delete a Pod that belongs to a Deployment with 3 replicas. Why does a new one appear moments later, with no one telling Kubernetes to create it?
