✦ For everyone, free.

Practical knowledge for real and everyday life

Home

3.1 Kubernetes Control Plane Composition

Kubernetes Control Plane Composition manages cluster operations through core components, ensuring scalability and efficient resource orchestration.

Kubernetes Control Plane Composition is the specific enumeration of which processes make up the control plane and how they are packaged, describing the distinction between components bundled together into a single binary for operational convenience and components that run as entirely separate processes despite being equally essential to the control plane's function.


Bundled vs. Separate Processes

The Controller Manager as a Bundled Composition

The controller manager is composed of many individual controllers, such as the node controller, the replication controller, and the endpoints controller, bundled together and run as a single operating system process for operational simplicity, even though each controller within it performs a logically distinct reconciliation task.

The API Server and etcd as Separate Processes

In contrast to this bundling, the API server and etcd are composed as entirely separate processes, each with its own lifecycle, configuration, and failure characteristics, reflecting their distinct roles as the request-handling front end and the durable data store respectively.

Control Plane = API Server etcd Scheduler Controller Manager

Why Composition Choices Differ

Operational Simplicity for Similar, Numerous Controllers

Bundling many small, similarly structured controllers into the controller manager reduces the operational burden of managing dozens of individually deployed processes, since each individual controller's resource footprint and failure mode are broadly similar to the others bundled alongside it.

Isolation for Components with Distinct Failure Characteristics

The API server and etcd are kept as separate processes precisely because their failure characteristics and resource demands differ significantly; etcd's disk and consensus-latency sensitivity, for instance, is architecturally distinct enough from the API server's request-handling load that combining them would make capacity planning and failure isolation more difficult.


The Cloud Controller Manager as a Separable Composition

Optional Depending on Environment

The cloud controller manager is composed as an optional, separately deployed component, present only in environments integrated with a specific cloud provider, distinguishing it from the other control plane components that are present in every cluster regardless of underlying infrastructure.

Provider-Specific Logic Kept Out of the Core

Its separation reflects a deliberate compositional choice to keep cloud-provider-specific logic, such as provisioning load balancers, out of the core controller manager, so that the core control plane composition remains identical across differing infrastructure environments.


Composition as Distinct from Architecture

What Runs, Not How It Behaves

Composition specifically concerns which processes exist and how logic is packaged among them; it is distinct from the internal architecture of any single component, such as the API server's own request-processing pipeline, which concerns how that one process behaves internally rather than what other processes exist alongside it.


Control Plane Composition Diagram

API Server etcd Scheduler Controller Mgr (bundled controllers)