The Kubernetes Control Plane In Depth

Analogy categoryAnalogies

The control plane is the collection of processes that maintain the desired state of a Kubernetes cluster: kube-apiserver, etcd, kube-scheduler, kube-controller-manager, and, in cloud environments, cloud-controller-manager. Every change to the cluster—creating a Deployment, scaling a StatefulSet, draining a node—flows through the API server and is persisted to etcd, then acted on by controllers running independent reconciliation loops that compare observed state to desired state and issue corrective actions.

🏏

Cricket analogy: Like a captain relaying field placements while the scorer records every ball bowled, on-field calls from Virat Kohli only take effect once logged in the official scorebook, and umpires continuously check the field matches what was called.

Core Components: API Server, Scheduler, and Controller Manager

kube-apiserver is the only component that talks directly to etcd; it authenticates, authorizes, and validates every REST request before persisting it, then exposes a watch interface so every other component—scheduler, kubelets, controllers—can react to changes without polling. kube-scheduler watches for pods with no assigned node, filters candidate nodes using predicates such as resource requests, node selectors, taints and tolerations, then scores the survivors with priorities like pod anti-affinity and image locality before binding the pod. kube-controller-manager runs dozens of control loops in a single binary—the node controller, replication controller, endpoint controller, and namespace controller among them—each watching a narrow slice of the API and driving actual state toward the declared spec.

🏏

Cricket analogy: DRS reviews route every appeal through the third umpire who validates ball-tracking data before a decision counts, similar to how kube-apiserver authenticates and validates each request before it's ever recorded.

etcd and Cluster State

etcd is the sole source of truth for cluster state, storing every object as a key under a hierarchical keyspace and using the Raft consensus algorithm to replicate writes across an odd-numbered cluster of members, typically three or five. A write only succeeds once a majority of members acknowledge it, which is why etcd tolerates the loss of a minority of nodes—a five-member cluster survives two failures—but a tie-breaking majority is mandatory, which is why even-numbered clusters are avoided. The API server issues watch requests against etcd's MVCC store so that it can stream incremental changes to clients instead of re-reading the whole keyspace on every update.

🏏

Cricket analogy: A five-member panel of match referees needs at least three to agree before overturning an on-field decision, just as etcd needs a majority of its five members to acknowledge a write before it commits.

yaml

apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - name: kube-apiserver
    image: registry.k8s.io/kube-apiserver:v1.30.0
    command:
    - kube-apiserver
    - --etcd-servers=https://127.0.0.1:2379
    - --advertise-address=10.0.0.10
    - --secure-port=6443
    - --service-cluster-ip-range=10.96.0.0/12
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
    - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
    - --authorization-mode=Node,RBAC
    - --enable-admission-plugins=NodeRestriction

kubeadm-managed control planes run kube-apiserver, kube-scheduler, and kube-controller-manager as static Pods defined by manifest files in /etc/kubernetes/manifests on each control-plane node — the kubelet on that node watches the directory and restarts them directly if they crash, independent of the scheduler.

High Availability and Control Plane Topology

Production clusters run multiple kube-apiserver replicas behind a load balancer so that no single instance is a point of failure, while kube-scheduler and kube-controller-manager run as multiple replicas that use a Lease object in the API server to perform leader election, with only the elected leader actively reconciling at any moment. Control plane etcd can be deployed as a stacked topology, colocated on the same nodes as the API servers, or as an external topology on dedicated hosts—stacked is simpler to operate but couples etcd and control-plane node failures together, while external decouples the failure domains at the cost of extra machines to manage.

🏏

Cricket analogy: A cricket board keeps a reserve umpire on standby who takes over instantly if the on-field umpire is injured, just as a standby kube-controller-manager instance takes over via leader election if the active leader's lease expires.

A stacked etcd topology means an etcd quorum loss and a control-plane node outage can happen from the same event (e.g. a shared disk or power failure), so clusters with strict availability requirements should weigh external etcd despite the extra operational overhead.

kube-apiserver is the only component that reads and writes directly to etcd.
etcd uses Raft consensus and requires a majority of members to acknowledge a write before it commits.
kube-scheduler filters nodes with predicates, then ranks survivors with priority functions before binding a pod.
kube-controller-manager runs many independent reconciliation loops in a single binary.
Production clusters run multiple API server replicas behind a load balancer for availability.
Scheduler and controller-manager use Lease-based leader election so only one replica actively reconciles.
etcd can be deployed stacked with control-plane nodes or externally on dedicated hosts.