Architecture and control plane

Kubernetes is a set of cooperating control loops around a strongly consistent store. Knowing the pieces explains most “mysterious” delays and outages.

Control plane

• API server — the only public front door to cluster state; authn/authz, validation, admission
• etcd — the datastore for cluster objects; lose quorum and you lose the ability to change (and eventually trust) state
• Scheduler — binds Pods to nodes based on resources and constraints
• Controller manager — Deployments, Endpoints, Jobs, and other reconcilers that watch and act
• Cloud controller (when present) — integrates load balancers, nodes, and routes with the cloud

Managed Kubernetes (EKS, GKE, AKS) still has these parts; you just operate fewer of them yourself.

Data plane

• kubelet — agent on each node; runs Pods, reports status, honors probes and volume mounts
• container runtime — CRI implementation (containerd, CRI-O, …)
• kube-proxy / dataplane — Service VIP programming (iptables, IPVS, or eBPF alternatives)
• CNI plugin — Pod network connectivity

Desired state

You write objects to the API. Controllers compare spec to status and act until they match — or until they surface a condition explaining why they cannot. Debugging is often “which controller is stuck, and what does status say?”

HA implications

Multiple API servers behind a load balancer, odd-sized etcd, and separated failure domains matter for control-plane survival. A healthy app Deployment cannot schedule if the control plane cannot accept binds.

Smell test

If an incident needs “restart everything,” ask which plane failed: etcd latency, API apiserver saturation, scheduler backlog, or kubelet/node pressure. The architecture vocabulary keeps the blast radius honest.