To run containerized applications, a Kubernetes cluster requires worker nodes. At least one worker node is mandatory for every cluster. These nodes are responsible for hosting the Pods that make up the application workload. The control plane manages the worker nodes and Pods in the cluster. Typically, in production environments, multiple computers are used to run the control plane, while multiple nodes are used to run a cluster, providing high availability and fault-tolerance.
Control Plane Components
A Kubernetes cluster consists of several components that work together to manage containerized applications. The control plane components make global decisions and respond to cluster events, and can be run on any machine in the cluster.
The API server, kube-apiserver, exposes the Kubernetes API and scales horizontally by deploying more instances.
The etcd is a key-value store that serves as the cluster's backing store for all data, and requires a backup plan to ensure data reliability.
The kube-scheduler watches for newly created Pods and selects a node for them to run on based on factors like resource requirements and deadlines.
The kube-controller-manager is a vital component of the Kubernetes control plane that runs various controller processes. Although each controller is technically a separate process, they are compiled into a single binary and run together to simplify the system.
There are different types of controllers in Kubernetes, including the Node controller which detects and handles node failures, the Job controller that creates and manages Pods for completing one-time tasks, the EndpointSlice controller responsible for populating EndpointSlice objects to establish connections between Services and Pods, and the ServiceAccount controller that creates default ServiceAccounts for new namespaces.
The cloud-controller-manager is a component of the Kubernetes control plane that integrates cloud-specific control logic. It allows you to connect your cluster with your cloud provider's API and segregates components that interact with the cloud platform from those that only interact with the cluster.
The cloud-controller-manager runs only the controllers that are specific to your cloud provider. If you're running Kubernetes on your own premises or in a learning environment on your PC, your cluster won't have a cloud controller manager.
Like the kube-controller-manager, the cloud-controller-manager consolidates multiple logically independent control loops into a single binary that you can run as a single process. You can horizontally scale it by running multiple copies to enhance performance or tolerate failures.
The following controllers may have dependencies on the cloud provider:
Node controller: It checks the cloud provider to determine if a node has been deleted in the cloud after it stops responding.
Route controller: It sets up routes in the underlying cloud infrastructure.
Service controller: It creates, updates, and deletes cloud provider load balancers.
Node Components
The Node Components in a Kubernetes cluster are responsible for maintaining the running pods and providing the necessary runtime environment.
The kubelet is an agent that runs on each node and ensures that the containers specified in the PodSpecs are healthy and running.
The kube-proxy acts as a network proxy, maintaining network rules on the nodes for communication between pods and external network sessions.
The container runtime is responsible for running the containers and Kubernetes supports various container runtimes like containerd, CRI-O, and other implementations of the Kubernetes CRI.