Kubernetes components

Kubernetes follows a client-server architecture. In Kubernetes, multiple master nodes control multiple worker nodes. Each master and worker has a set of components required for the cluster to work correctly. A master node generally has kube-apiserver, etcd storage, kube-controller-manager, cloud-controller-manager, and kube-scheduler. The worker nodes have kubelet, kube-proxy, a Container Runtime Interface (CRI) component, a Container Storage Interface (CSI) component, and so on. The following is an architecture diagram of a Kubernetes cluster showing some of the core components:

Figure 1.2 – Kubernetes architecture with core components

Figure 1.2 presents a simplified diagram of a Kubernetes cluster’s control plane, highlighting its essential components, such as the API server, scheduler, etcd, and Controller Manager. The diagram also demonstrates the interaction between the control plane and a worker node, which includes critical components such as the kubelet, Kube-proxy, and several Pods running workloads. This interaction showcases how the control plane manages and orchestrates containerized applications across the cluster while ensuring smooth communication with worker nodes.

You can see that the API server is the most important component of the cluster, making connections with the rest of the components. The communications with the API server are usually inbound, meaning that the component creates the request to the API server. The Kube API server authenticates and validates the request.

Now, we will be explaining those components in more detail:

• Cluster: A Kubernetes cluster is composed of multiple machines (or VMs) known as nodes. There are two types of nodes: master nodes and worker nodes. The main control plane, such as kube-apiserver, runs on the master nodes. The agent running on each worker node is called kubelet, working as a minion on behalf of kube-apiserver. A typical workflow in Kubernetes starts with a user (for example, DevOps) who communicates with kube-apiserver in the master node, and kube-apiserver delegates the deployment job to the worker nodes. This workflow is illustrated in the following diagram:

Figure 1.3 – Kubernetes user request workflow

Figure 1.3 shows how a user sends a deployment request to the master node (kube-apiserver), which delegates the deployment execution to kubelet in some of the worker nodes:

• kube-apiserver: The Kubernetes API server (kube-apiserver) is a control-plane component that validates and configures data for objects such as Pods, services, and controllers. It interacts with objects using REST requests.
• etcd: etcd is a highly available key-value store used to store data such as configuration, state, secrets, metadata, and some other sensitive data. The watch functionality of etcd provides Kubernetes with the ability to listen for updates to configuration and make changes accordingly. However, while etcd can be made secure, it is not secure by default. Ensuring that etcd is secure requires specific configurations and best practices due to the sensitive information it holds. We will cover how to secure etcd in Chapter 6, Securing Cluster Components.
• kube-scheduler is a default scheduler for Kubernetes. It looks for newly created pods and assigns pods to the nodes. The scheduler first filters a set of nodes on which the pod can run. Filtering includes creating a list of possible nodes based on available resources and policies set by the user. Once this list is created, the scheduler ranks the nodes to find the most optimal node for the pod.
• Cloud-controller-manager: This feature is still in beta state. It is a core component (control plane component) that enables Kubernetes to interact with cloud provider resources and services, such as load balancers, storage volumes, and networking. Some of the responsibilities of this component include ensuring that nodes (either VMs or instances) are properly managed in the cloud provider. It is also responsible for configuring networking routes between nodes to ensure pods can communicate across the cluster.
• Kubelet: This is the node agent for Kubernetes. It manages the life cycle of objects within the Kubernetes cluster and ensures that the objects are in a healthy state on the node. Its primary function is to ensure that containers are running as specified in the Pod definitions (manifest files) by interacting with the Kubernetes API server to receive the needed information, then managing the lifecycle of containers using container runtime environments, such as Docker or containerd.
• Kube-proxy: This crucial component runs on each node to manage network connectivity and load balancing for Pods. It ensures that network traffic is correctly routed within the cluster, enabling communication between services and Pods by managing iptables or IPVS rules on nodes to direct traffic to the correct endpoints, ensuring seamless connectivity.
• kube-controller-manager: The Kubernetes controller manager is a combination of the core controllers that watch for state updates and make changes to the cluster accordingly. Controllers that currently ship with Kubernetes include the following:

Controllers	Description
Replication controller	This maintains the correct number of Pods on the system for every replication controller object.
Node controller	This monitors changes to the nodes.
Endpoints controller	This populates the endpoint object, which is responsible for joining the service object and Pod object. We will cover services and Pods in more detail in the next section.
Service accounts token controller	This creates default accounts and API tokens for new namespaces.
Cloud controller manager	This enables Kubernetes to interact with cloud provider resources and services.

Table 1.1 – Controllers available within Kubernetes

In this section, you looked at the core components of Kubernetes. These components will be present in all Kubernetes clusters. Kubernetes also has some configurable interfaces that allow clusters to be modified to suit organizational needs. You will review these next.