Kubernetes architecture explained: Control plane and worker nodes

Kubernetes manages containerised workloads across a cluster of machines. To do this reliably it splits responsibilities between two types of nodes: the control plane, which manages cluster state, and worker nodes, which run application workloads. Understanding what each component does and how they interact is the foundation for everything else in Kubernetes.

Control plane components

The control plane is responsible for the overall state of the cluster. It makes scheduling decisions, responds to API requests, and ensures the cluster converges toward its desired state.

API server

The API server is the central entry point for all communication with the cluster. Every request, whether from kubectl, an internal component, or an external tool, goes through the API server. Each request passes through three stages: authentication (who are you), authorisation (what are you allowed to do), and admission (does this request comply with cluster policies). The API server is the only component that reads from and writes to etcd.

etcd

etcd is a distributed key-value store that holds all cluster state. Every resource, configuration, and object in the cluster is stored here. If etcd is lost without a backup, the cluster state is lost entirely. In production clusters, etcd runs as a three or five node cluster for high availability. Backing it up regularly is one of the most important operational tasks in a Kubernetes cluster.

Scheduler

The scheduler watches for newly created pods that have not yet been assigned to a node. When it finds one, it selects the best node to run it on based on resource availability, node affinity rules, taints and tolerations, and other constraints. The scheduler does not run the pod itself, it only makes the placement decision and updates the API server.

Controller manager

The controller manager runs a set of controllers that continuously watch cluster state and take action to reconcile it toward the desired state. Examples include the replication controller (ensures the correct number of pod replicas are running), the DaemonSet controller, the Deployment controller, and the node controller (detects and responds to node failures). Each controller runs a reconciliation loop independently.

Worker node components

Worker nodes run the actual application workloads. Each worker node runs three core components.

Kubelet

The kubelet is the primary agent on each worker node. It continuously communicates with the API server and watches for pods scheduled to its node. When a pod is assigned, the kubelet instructs the container runtime to pull the required images and start the containers. It also monitors container health and reports status back to the API server.

Kube-proxy

Kube-proxy runs on every node and maintains the network rules that allow pods to communicate with each other and with services. It implements the Kubernetes Service abstraction by programming iptables or IPVS rules that route traffic from a Service's virtual IP to the correct pod endpoints.

Container runtime

The container runtime is responsible for pulling images and running containers. Kubernetes 1.24 removed support for Docker as a direct container runtime. Most clusters now use containerd, which was the runtime layer Docker itself used under the hood. Container images built with Docker continue to work unchanged since the image format is standardised.

How a request flows through the cluster

When you run kubectl create pod, here is what happens:

1. kubectl sends the request to the API server
2. The API server authenticates, authorises, and admits the request, then writes the pod object to etcd
3. The scheduler notices an unscheduled pod, selects a node, and updates the pod object in etcd via the API server
4. The kubelet on the selected node notices the pod is assigned to it, instructs containerd to pull the image and start the container
5. The kubelet updates pod status back to the API server, which writes it to etcd