Kubernetes Architecture

Understanding the components of a Kubernetes cluster is essential before working with it. Kubernetes uses a control plane / data plane split: the control plane makes decisions, and the data plane (worker nodes) executes them.

The Control Plane

The control plane is the brain of the cluster. It runs a set of components that manage the desired state of workloads.

kube-apiserver is the central gateway for all cluster operations. Every kubectl command, every internal component, and every webhook communicates through the API server via a RESTful HTTP API. It validates requests, persists objects to etcd, and triggers reconciliation loops.

etcd is a distributed key-value store that holds the entire cluster state — every resource, every secret, every status update. etcd uses the Raft consensus algorithm to remain consistent even if some instances fail. Backing up etcd is critical for disaster recovery.

kube-scheduler watches for newly created pods that have no node assigned and selects the best node for them based on resource requests, affinity rules, taints, and tolerations.

kube-controller-manager runs a collection of controllers in a single process. The Deployment controller ensures the right number of pod replicas exist. The Node controller notices when nodes go offline. The ReplicaSet controller maintains pod counts. Each controller runs a reconcile loop: observe, compare to desired state, act.

cloud-controller-manager integrates the cluster with cloud provider APIs to provision load balancers, storage volumes, and node instances.

Worker Nodes

Each worker node runs the workloads scheduled by the control plane.

# Inspect nodes and their roles
kubectl get nodes -o wide

# Describe a specific node
kubectl describe node my-node

kubelet is an agent running on every node. It receives pod specifications from the API server and talks to the container runtime (typically containerd) to start, stop, and monitor containers. It also reports node and pod status back to the API server.

kube-proxy maintains network rules on each node that implement the Service abstraction — forwarding traffic destined for a Service's ClusterIP to one of the healthy pod endpoints.

Container runtime (containerd, CRI-O, or formerly Docker) is the low-level software that actually runs containers. Kubernetes communicates with it via the Container Runtime Interface (CRI).

How a Pod Gets Scheduled