Kubernetes Architecture — Control Plane & Worker Nodes

A Kubernetes cluster is not a single entity; it is a distributed system split into two distinct tiers: the Control Plane (the brain) and Worker Nodes (the muscle). Together, they form an autonomous reconciliation machine. When you tell Kubernetes to run three instances of your service, you are submitting an intent to the brain, which continuously commands the muscles to make that intent a physical reality.

Understanding how these internal components interact is essential for debugging outages, optimizing performance, and designing resilient workloads.

The Control Plane (Master Components)

The control plane makes global decisions about the cluster (like scheduling), detects events, and responds to cluster changes.

1. kube-apiserver

The API Server is the front door of the Kubernetes control plane. It exposes the Kubernetes HTTP REST API and serves as the central hub. Every single interaction—whether from kubectl, a CI/CD pipeline, an internal controller, or a worker node agent—goes through the API Server. It validates requests, processes authentication and authorization, and is the only component allowed to directly talk to etcd.

2. etcd

etcd is a consistent, highly-available distributed key-value store based on the Raft consensus algorithm. It holds the entire state of the cluster: which pods exist, their configuration, node health, secrets, and namespaces. If etcd is lost without backup, your cluster's brain is wiped clean.

3. kube-scheduler

The scheduler watches for newly created pods that have no assigned node and selects the optimal worker node for them to run on. It evaluates resource requirements (CPU/RAM requests), affinity and anti-affinity rules, taints and tolerations, hardware constraints, and data locality.

4. kube-controller-manager

Controllers are the heart of the reconciliation loop. The Controller Manager compiles dozens of individual control loops into a single binary:

• Node Controller: Detects when a worker node stops responding and initiates pod eviction.
• Job Controller: Watches for batch jobs and creates pods to run them to completion.
• EndpointSlice Controller: Populates endpoints linking Services to active Pod IPs.
• ServiceAccount Controller: Creates default accounts and API access tokens for new namespaces.

---

Worker Nodes (Execution Plane)

Worker nodes are physical or virtual servers that actually execute your containerized workloads. Each node runs three critical services:

1. kubelet

The node captain. An agent that registers the node with the API server, watches for PodSpecs assigned to its node, and instructs the container runtime to launch or kill containers. The kubelet also reports container health and node metrics back to the control plane.

2. Container Runtime

The underlying software that runs containers (e.g., containerd, CRI-O). It communicates with the kubelet via the Container Runtime Interface (CRI) to pull container images, set up cgroups and namespaces, and start container processes.

3. kube-proxy

A network proxy that runs on each node, maintaining network rules (typically using iptables or IPVS). It enables network communication to your Pods from network sessions inside or outside of your cluster, implementing the abstraction of Kubernetes Services.

---

The Request Lifecycle: Scheduling a Pod

What actually happens under the hood when you run kubectl apply -f pod.yaml?

1. kubectl issues an HTTP POST request containing the manifest to kube-apiserver.
2. kube-apiserver authenticates and authorizes the user, validates the schema, and commits the unassigned Pod object to etcd.
3. kube-scheduler notices the unscheduled Pod, scores all available worker nodes, selects the best candidate (e.g., Node-2), and sends a binding request back to kube-apiserver.
4. kube-apiserver writes the assigned node to etcd.
5. The kubelet daemon on Node-2 detects that a pod has been scheduled to its node.
6. kubelet invokes the container runtime via CRI to fetch images and spawn containers, and configures the pod network sandbox via CNI.
7. Once running, kubelet updates the Pod status to Running via the API Server.

---

Key Takeaways

• All cluster communication flows through kube-apiserver; components never talk directly to etcd or to each other.
• The control plane relies on etcd for consensus and persistent state.
• Worker nodes execute workloads via kubelet, container runtime, and route traffic via kube-proxy.
• Kubernetes operates through continuous reconciliation: state is declared, recorded in etcd, and actively realized across worker nodes.