Understanding Kubernetes architecture helps you troubleshoot problems, make better design decisions, and answer exam questions about what happens when you run a kubectl apply.
The Two Planes
A Kubernetes cluster is divided into two distinct roles:
- Control Plane (Master): The brain of the cluster. Stores cluster state, schedules Pods, and responds to changes. In managed services (EKS, GKE, AKS), this is fully managed by the cloud provider.
- Worker Nodes: The machines that actually run your containerised workloads.
Control Plane Components
kube-apiserver
The API Server is the front door to Kubernetes. Every interaction with the cluster — from kubectl commands, to internal component communication — goes through the API Server. It validates and processes requests, and stores the result in etcd.
etcd
A distributed key-value store that holds all cluster state: nodes, Pods, Deployments, ConfigMaps, Secrets, and more. If etcd is lost without a backup, the cluster state is gone. Always back up etcd in production.
kube-scheduler
Watches for newly created Pods with no node assigned, and selects a suitable node based on resource requirements, constraints, affinity rules, and available capacity. It does not actually run the Pod — it just decides where.
kube-controller-manager
Runs a collection of controllers that maintain desired state:
- Node Controller — responds to node failures
- ReplicaSet Controller — maintains the correct number of Pod replicas
- Deployment Controller — manages rolling updates
- Service Account Controller — creates default service accounts
- ...and many more
cloud-controller-manager
Integrates Kubernetes with cloud provider APIs. Handles cloud-specific features like creating load balancers, persistent disks, and managing node lifecycle in cloud environments.
Worker Node Components
kubelet
An agent running on every worker node. It watches the API Server for Pods assigned to its node, and instructs the container runtime to start, stop, or restart containers. It also reports node and Pod status back to the control plane.
kube-proxy
Runs on every node and maintains network rules (iptables or IPVS) that allow Pods to communicate with Services. It implements the Service abstraction at the network level.
Container Runtime
The software that actually runs containers. Kubernetes supports any runtime implementing the CRI (Container Runtime Interface):
- containerd — the standard runtime (used by most cloud providers)
- CRI-O — lightweight, RHEL-oriented
- Docker Engine (via the dockershim, now removed — Kubernetes uses containerd directly)
Add-On Components
- CoreDNS: Cluster DNS server — resolves service names to cluster IPs
- CNI Plugin (e.g., Calico, Flannel, Cilium): Implements the network model for Pod-to-Pod communication
- Metrics Server: Collects CPU/memory from nodes and Pods (required for HPA)
- Dashboard: Optional web UI for the cluster
What Happens When You Run kubectl apply
- kubectl sends an HTTP request to the API Server
- API Server validates the request and stores the resource in etcd
- The relevant controller notices a new resource and creates Pods
- The scheduler assigns each Pod to a suitable node
- The kubelet on that node sees the assignment and tells the container runtime to start the container
- The container starts; kubelet reports status back to the API Server
This flow — declarative intent → stored in etcd → controllers reconcile — is the fundamental pattern that makes Kubernetes reliable and self-healing.
Next: Pods and workload controllers — the objects you'll spend most of your time working with.