Kubernetes architecture — control plane, worker nodes, etcd and the API server

Kubernetes is not a container runner — it is a distributed system for declaring the desired state of a cluster and continuously reconciling the actual state toward that declaration. This distinction is foundational: when you create a Deployment, you are not instructing Kubernetes to run containers; you are writing a desired state into etcd, the cluster's distributed key-value store, and a set of independent control loops — controllers — each observe a small slice of that state and take the minimum action required to converge the actual cluster toward it. Understanding this reconciliation architecture is what separates engineers who fight Kubernetes from those who work with it, because every behaviour that initially seems mysterious — why does a deleted Pod reappear, why does a Service endpoint update take seconds, why does a rolling update pause midway — is a direct consequence of a specific controller performing a reconciliation step on a specific piece of state.

The control plane is the set of components that manage cluster-wide state: the API server, which is the single authoritative gateway for all cluster state reads and writes; etcd, which stores that state durably and notifies watchers of changes; the scheduler, which assigns unscheduled Pods to worker nodes; and the controller manager, which runs dozens of control loops that reconcile object states. Worker nodes run the kubelet, which receives Pod specs from the API server and instructs the container runtime to create, start, and monitor containers; the container runtime itself (typically containerd); and kube-proxy, which programs the node's iptables or eBPF rules to implement Service routing. Every cluster operation — applying a manifest, deleting a resource, scaling a Deployment — flows through this architecture in a deterministic sequence that is fully observable via the API.

Analogy🏏Cricket

🏏 Think of it like cricket: The Pod-ReplicaSet-Deployment hierarchy maps precisely onto the three levels of IPL franchise team management. A Pod is a single player on the field at a given moment — the smallest unit of participation, carrying its own identity and fulfilling a specific role in the current game. A ReplicaSet is the franchise's match-day playing XI contract — it specifies that exactly eleven players matching a specific profile must always be on the field; if one is injured and leaves, the team management immediately sends a substitute of the same profile to restore the count. A Deployment is the franchise's season-long team strategy — it manages how the playing XI evolves between matches: when a new batting approach is adopted, the Deployment replaces the old XI with the new one in a controlled rolling substitution rather than swapping all eleven players simultaneously and disrupting team cohesion. Just as the franchise director does not manage individual players directly — the playing XI contract (ReplicaSet) handles the count and the season strategy (Deployment) handles the transitions — you never manage Pods directly in production; the Deployment manages the transition and the ReplicaSet maintains the count. This reveals why the three-level hierarchy exists rather than one omnibus 'workload' object: each level solves one specific problem, and composing three focused abstractions produces better separation of concerns than one object that conflates scheduling, scaling, and update management.