2.1 Kubernetes Cluster Architecture Overview
Kubernetes Cluster Architecture Overview explains the structure and key components of a Kubernetes cluster, including control plane, nodes, and networking.
Kubernetes Cluster Architecture Overview is the high-level orientation to how a Kubernetes cluster is organized, framing the relationship between the control plane, worker nodes, and the communication pathways connecting them as the essential structure that every more detailed architectural topic builds upon.
The Two-Tier Shape of a Cluster
Control Plane and Worker Nodes as the Two Tiers
Every Kubernetes cluster is organized around two tiers: a control plane responsible for making decisions about the cluster as a whole, and a set of worker nodes responsible for actually running the containerized workloads those decisions concern.
Why This Separation Exists
This separation exists so that decision-making logic can be centralized, replicated for availability, and reasoned about independently of the specific machines running application workloads, allowing the number and characteristics of worker nodes to change freely without disrupting the cluster's decision-making capability.
How the Tiers Communicate
The API Server as the Central Hub
All communication between the control plane and worker nodes flows through the API server; nodes report their status to it, and it in turn communicates scheduling and workload assignments outward, meaning no direct peer-to-peer channel exists between arbitrary control plane and node components.
One-Way Assumptions Are Avoided
Because every component communicates through the same central API server, the architecture avoids assumptions about which direction communication must flow, allowing components to be added, replaced, or scaled independently as long as they continue speaking through that shared interface.
Where State Lives
A Single Durable Store
Beneath the API server sits a single durable data store holding the authoritative record of the cluster's state; every other component, whether part of the control plane or running on a worker node, ultimately derives its view of the cluster from this one source rather than maintaining independent, conflicting records.
Why This Overview Matters Before Going Deeper
A Map Before the Details
Understanding this two-tier shape, and the fact that all interaction passes through a shared API and a shared store, provides the necessary map for making sense of the more detailed roles played by individual components such as the scheduler, the kubelet, or the container runtime, each of which occupies a specific position within this overall structure.