The control plane of a Kubernetes cluster contains components used to make decisions about the cluster, such as scheduling tasks. In addition, the control plane detects and responds to cluster events, such as the start-up of a new pod.
The components of a control plane can be executed from any server in a Kubernetes cluster, but for simplicity, the various components are typically placed on a single server.
Schematically, a control plane, along with the rest of a Kubernetes cluster, looks like this:
Kubernetes components
Kube-apiserver
The API server provides the Kubernetes API and is the "frontend" of a Kubernetes control plane. The kube-apiserver scales horizontally. This means that you can run multiple instances of the kube-apiserver, and traffic is balanced between those instances.
Etcd
Etcd is a key-value store. Kubernetes typically uses it to read small data that needs to be available very quickly, such as the status of a node. For example, we use Etcd for our Kubernetes platform to place a lock on a node if necessary.
Kube-scheduler
The Kube-scheduler checks for newly created pods that have not been assigned to a node and then assigns a node to execute them from. This takes into account resource requirements, hardware/software/policy limitations, etc.
Kube-controller-manager
The component that executes controlling processes. Each controller process is a standalone process, but for simplification, all components are packaged together in a single executable program and executed. The Kube-controller-manager consists of:
- Node controller: Detects and responds to node failures.
- Job controller: Controls one-time tasks and creates one or more pods to perform those tasks.
- Endpoints controller: Combines services and pods.
- Service Account & Token controllers: Creates default accounts and API access tokens for new namespaces.
Cloud-controller-manager
A control plane component that embeds cloud-specific control logic. Simply put, the cloud control manager ensures that your Kubernetes cluster can connect to your cloud provider's API, and separates components that communicate with that cloud platform from components that only communicate with your cluster. An on-premise Kubernetes cluster does not use a Cloud-controller-manager; it only concerns the communication with the API of your cloud provider.
More than one Cloud-controller-manager can be executed at the same time to improve performance and fault tolerance.
Some Kubernetes controllers may contain cloud provider dependencies where the Cloud-controller-manager comes in handy:
- The node controller: To determine when a node is no longer responding or has been removed from the cloud provider.
- Route controller: For setting up network routes in the underlying cloud infrastructure.
- Service controller: For creating, updating, and deleting load balancers at the cloud provider.