Kubernetes Control Plane

Kubernetes Control Plane is the collective set of processes that maintain the record of cluster state, make scheduling and orchestration decisions, and expose the API through which the cluster is observed and modified. The control plane does not run application workloads itself; instead, it governs the cluster, deciding what should run, where it should run, and reacting when reality diverges from the declared intent.

Responsibilities of the Control Plane

The control plane is responsible for four broad categories of work: exposing a consistent API surface, persisting cluster state durably, deciding Pod placement, and continuously reconciling the actual state of the cluster with the desired state recorded by users. Each of these responsibilities is handled by a distinct component, allowing the control plane to be reasoned about, scaled, and upgraded piece by piece rather than as a monolith.

kube-apiserver

The API server is the only control plane component that communicates directly with etcd, and it is the sole entry point for all read and write operations on cluster state.

Request Processing Pipeline

Every request to the API server passes through a defined pipeline:

1. Authentication: Determines the identity of the requester, using mechanisms such as client certificates, bearer tokens, or an external identity provider.
2. Authorization: Determines whether the authenticated identity is permitted to perform the requested action, most commonly evaluated through Role-Based Access Control (RBAC).
3. Admission Control: Runs a chain of admission controllers that may validate or mutate the request, enforcing policies such as resource quotas, default values, or security constraints.
4. Validation and Persistence: The resulting object is validated against its schema and, if valid, written to etcd.

API Aggregation and Extensibility

The API server supports aggregation, allowing additional API groups, including those defined by Custom Resource Definitions or external extension API servers, to be served alongside the built-in API, all through the same authenticated, audited entry point.

etcd

etcd underlies the durability guarantees of the entire cluster. Because it is the single source of truth, its availability and consistency directly determine the availability and consistency of the cluster as a whole.

Consistency Model

etcd implements the Raft consensus algorithm, under which a leader is elected among the members of the etcd cluster and all writes are committed only once acknowledged by a majority (quorum) of members. This guarantees linearizable reads and writes even in the presence of individual node failures, as long as quorum is maintained.

Operational Considerations

Because etcd performance is sensitive to disk latency and network round-trip time between members, it is commonly deployed on dedicated, low-latency storage, and regular snapshotting is used to enable recovery in the event of catastrophic data loss.

kube-scheduler

The scheduler is responsible solely for deciding which node a Pod should run on; it does not itself start the Pod, that responsibility belongs to the kubelet on the chosen node.

Filtering and Scoring

Scheduling proceeds in two phases. The filtering phase eliminates nodes that cannot satisfy a Pod's requirements, such as insufficient available resources or unmet node selector constraints. The scoring phase ranks the remaining feasible nodes according to configurable priorities, such as spreading Pods evenly across nodes or packing them to minimize fragmentation, and the highest-scoring node is selected.

Extensibility

The scheduler exposes a plugin-based framework with well-defined extension points, allowing custom scheduling logic to be introduced without modifying the scheduler's core code, and multiple scheduler instances can run concurrently in a cluster, each responsible for a distinct subset of Pods.

kube-controller-manager

This process runs many independent control loops within a single binary, primarily for deployment simplicity. Each loop watches a specific type of resource and drives it toward its desired state.

Representative Controllers

• Node Controller: Monitors node heartbeats and marks nodes as unreachable or evicts their Pods after a configured grace period.
• Replication and ReplicaSet Controllers: Ensure the number of running Pod replicas matches the number specified in a workload's specification.
• Job Controller: Tracks Pods created by Jobs to completion, retrying failures according to policy.
• Namespace Controller: Handles cleanup of resources when a namespace is deleted.

Leader Election

In highly available deployments, multiple instances of the controller manager run simultaneously, but only one is active at any time, determined through a leader election protocol built on top of coordination primitives stored in etcd, ensuring that controller logic is never executed redundantly or in conflict with itself.

cloud-controller-manager

This component isolates all cloud-provider-specific logic away from the core control plane binaries, exposing well-defined interfaces for node lifecycle management, route configuration, and load balancer provisioning. Its separation allows the core Kubernetes control plane to remain provider-agnostic while still integrating deeply with cloud infrastructure where available.

Interactions Among Control Plane Components

# Illustrative sequence when a node fails
kubectl get nodes                 # node shows NotReady after missed heartbeats
# node-controller (in kube-controller-manager) marks node condition
# after grace period, node-controller evicts pods bound to the node
# scheduler observes newly unscheduled pods and re-binds them
# kubelet on the new node starts the replacement containers

No control plane component communicates with another directly; all coordination happens indirectly, through reads and writes against the API server, which in turn are backed by etcd. This indirection is what allows control plane components to be restarted, upgraded, or scaled independently without requiring coordinated downtime.