Kubernetes architecture (control plane vs nodes)

Kubernetes splits cleanly into two planes. The control plane decides what should run. The nodes run it. Everything else is plumbing.

Control plane

Four components and a database.

• kube-apiserver: the only thing that talks to etcd. Every other component reads and writes through it. Stateless, horizontally scalable.
• etcd: a Raft-based key-value store. Holds the entire cluster state. Lose quorum and your cluster becomes read-only.
• kube-scheduler: watches for unscheduled pods, picks a node based on resource requests, taints, affinities, topology spread.
• kube-controller-manager: runs all the built-in controllers (Deployment, ReplicaSet, Node, Endpoint, ServiceAccount). Each one is a reconcile loop against the API server.
• cloud-controller-manager: talks to your cloud provider for LoadBalancers, node lifecycle, routes.

Worker nodes

Three things on every node.

• kubelet: registers the node, pulls pod specs, talks to the container runtime, reports back.
• container runtime: containerd or CRI-O. Docker is gone since 1.24.
• kube-proxy: programs iptables or IPVS for Service VIPs. eBPF-based CNIs like Cilium can replace it entirely.

The mental model that wins interviews

Kubernetes is a control loop machine. Every controller watches the API server, compares desired state to actual state, and nudges the world. The API server does nothing on its own. It just stores intent and emits events. That is why CRDs and operators feel natural - you are extending the exact same machinery.

Managed vs self-hosted

On EKS, GKE, AKS the control plane is the cloud provider's problem. You pay for the API server uptime and only manage worker nodes. Self-hosted with kubeadm means you own etcd backups, certificate rotation, version upgrades. For 95% of teams, managed is the right call.