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.
Hosted control plane
It's possible to outsource the operation of the control plane to a cloud provider. Some providers:
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 RBAC, then passed through Admission controllers for mutation and validation before having their state changes persisted to Configuration.