Control plane

The Kubernetes control Plane comprises:

  • The API Server (kube-apiserver) exposes a REST API for interacting with the cluster control plane, both for kubelets and external clients. This is the sole component which directly communicates with etcd.
  • The Controller Manager (kube-controller-manager) runs control loops, communicating with the API Server, determining changes that need to be made to make the cluster's actual state reach the goal state.
  • The Scheduler (kube-scheduler) binds Pods to Nodes, communicating with the API Server.

Control plane nodes

The control plane components run on control plane nodes. All services run on every node, though only one node will be elected the current leader.

Control plane nodes must run Linux.

External/managed control planes

It's possible to outsource the operation of the control plane to a cloud provider. Some providers:

User workloads

It's inadvisable to run user workloads on the control plane nodes, and by default the nodes are tainted to prevent this.


The control plane must be able to reach quorum to make a decision about how to handle the loss of this node. To avoid split brain in the event of a network partition there must always be an odd number of control plane nodes.

Path of API requests

API requests first have their sessions validated, are verified against Kubernetes RBAC resources, then passed through Admission controllers for mutation and validation before having their state changes persisted to Configuration.

flowchart LR Client subgraph Security Authentication Authorisation Authentication-->Authorisation end subgraph AdmissionControllers MutatingAdmissionController ValidatingAdmissionController MutatingAdmissionController-->ValidatingAdmissionController end etcd Client-->Authentication Authorisation-->MutatingAdmissionController ValidatingAdmissionController-->etcd