2.2 Kubernetes Control Plane Architecture

Kubernetes Control Plane Architecture is the specific internal arrangement of the components that make up the control plane, describing how the API server, cluster data store, scheduler, and controller manager are laid out relative to one another and how that layout is typically replicated across machines to achieve fault tolerance.

Component Layout

The API Server at the Center

Architecturally, the API server sits at the center of the control plane: every other control plane component, including the scheduler and the various controllers bundled into the controller manager, communicates exclusively through it, never directly with one another or with the data store.

etcd as a Separate, Adjacent Tier

The cluster data store, typically etcd, is architected as a component separate from the API server, reachable only by the API server itself; no other control plane or node component is architected to communicate with the data store directly.

Physical Deployment Layout

Co-located or Distributed Across Dedicated Machines

Control plane components can be architected to run co-located on a small number of dedicated machines, common in smaller clusters, or distributed across a larger number of machines with components spread out for greater fault isolation, common in larger production clusters.

Separation from Worker Capacity

Regardless of physical layout, control plane machines are typically architected to be tainted against running ordinary application workloads, keeping worker capacity architecturally distinct from the machines responsible for cluster decision-making.

Replication Architecture

Stateless Components Behind a Load Balancer

The API server is architected as an effectively stateless component with respect to its own replicas, allowing multiple instances to run behind a load balancer, with any instance capable of serving any request since all of them read from and write to the same underlying data store.

etcd's Distinct Replication Model

Unlike the API server, etcd is architected around a consensus-based replication model requiring an odd number of members to establish a quorum, a structurally different approach reflecting its role as the single source of truth rather than a stateless request handler.

Leader Election for Singleton Components

The scheduler and controller manager are architected so that only one active instance performs work at a time, using leader election among their replicas to avoid conflicting concurrent reconciliation, even though multiple standby replicas may be running simultaneously for failover.

Internal Communication Pattern

Watch-Based, Not Polling-Based

Rather than components repeatedly polling the API server for changes, the control plane is architected around a watch mechanism, in which the API server pushes change notifications to interested components as they occur, reducing load and latency compared to a polling-based architecture.

Control Plane Architecture Diagram