Components of Kubernetes

In this topic, we will look at the components that make up a Kubernetes cluster and how they work together. You will learn about their individual functions and how each component communicates with the rest of the cluster. Knowing what parts a cluster is composed of and how these parts interact is essential for deploying applications in a containerized environment.

Control-plane components

The first set of components in a Kubernetes cluster is the control plane.

Control plane components manage the cluster's state and decide how to allocate resources. They ensure the cluster maintains its desired state and handle communication within the cluster. Let's start with the API server.

The kube-apiserver processes messages coming from Kubernetes clients. Kubernetes uses a hub-and-spoke API pattern. This means a central system (the API server) acts as the control and coordination point for all communication. It is the primary way of interacting with the cluster. The messages it receives can be requests to create, change, or delete resources. It can also send messages to components, such as kubelet to fetch logs.

Cluster state and configuration data are stored in the etcd data store. etcd is a distributed key-value store that holds the data the cluster needs to function correctly, including network and pod configurations, network policies, and more. It serves as the single source of truth for the entire cluster.

The kube-controller-manager ensures the cluster always maintains its desired state. It does this by running various controllers, such as replication, endpoints, namespaces, and others. For example, when you create a Job (a one-off task), the Job controller provisions Pods to run those Jobs and ensures they run to completion.

Related to the controller manager is the cloud-controller-manager. This lets you link your cluster to your cloud provider's APIs. It also runs various controllers, such as a Service controller that creates, updates, and deletes load balancers in your cloud environment. For simple workloads that run entirely locally, you don't need this component.

The kube-scheduler assigns Pods to nodes in the cluster after considering various factors. For instance, the resource requirements and hardware/software/policy constraints for the Pod. It looks for feasible nodes in a process called filtering, and then scores them. Then, it picks the highest-scoring one and schedules a pod onto it. Finally, it notifies the API server about this decision. Other factors the kube-scheduler considers when making decisions include affinity and anti-affinity specifications, data locality, inter-workload interference, and others.

Node components

Node components include the kubelet, kube-proxy, and the container runtime. These run on every node, managing the Pods that run application containers. A node can be a physical or virtual worker machine. It has access to a set of resources, such as CPU, memory, and storage.

The kubelet is a service that runs on every node in the cluster. It manages the containers running on the node's pods and the state of the pod itself. It ensures that both the node and the pods that run on it work as intended. It receives Pod manifests (PodSpecs) and ensures that the described containers are running. It continuously monitors container health through liveness and readiness probes, automatically restarting or replacing failed ones. It also handles Node registrations.

The kube-proxy also runs on each node in the cluster and manages network connectivity between Pods and Services. It achieves this by managing network rules and connections on the node's network stack, routing traffic to the correct destination. You can replace this component with network plugins that provide its functionality.

The container runtime manages the entire lifecycle of a container on the node. It pulls images and executes containers on a host system. Kubernetes supports any container runtime that implements the Kubernetes Container Runtime Interface (CRI), such as containerd and CRI-O. The container runtime communicates with the kubelet, receiving instructions about which containers to start, stop, restart, or delete, as well as sending status information.

Add-on components

Beyond what's included in the core feature set, add-on components extend Kubernetes by providing additional features such as networking and logging. For example, instead of using the kube-proxy for networking, an add-on, such as Cilium, brings additional capabilities.

One of the most important add-on components is a cluster DNS, which is required for service discovery. It serves DNS records for Pods, allowing them to communicate with each other. CoreDNS is a flexible option used as the in-cluster DNS server. Here is a brief overview of other add-on components:

• Networking add-ons provide cluster networking capabilities. They allow your Kubernetes cluster to work with diverse networking topologies and technologies.

• For a graphical interface, the dashboard (retired) provides a web interface for Kubernetes. You can also use the Headlamp UI for this purpose.

• The kube-state-metrics agent connects to the API server and exposes information about the state of Kubernetes objects.

• To run virtual machines on Kubernetes, you can use the KubeVirt add-on.

• cert-manager brings certificate management capabilities to your Kubernetes cluster.

You can also develop your own add-ons to meet your specific needs.

kubectl

While not strictly a core or add-on component of a Kubernetes cluster, the kubectl tool is the primary interface for communicating with the Kubernetes API. It allows you to deploy, inspect, and update resources from the command line. You can install it as follows on Linux:

$ curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

$ sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

$ kubectl version --client -o yaml

$ curl.exe -LO "https://dl.k8s.io/release/v1.35.0/bin/windows/amd64/kubectl.exe" # replace v1.35.0 with your preferred version

$ kubectl version --client -o yaml

kubectl is a high-level interface for managing the cluster, providing commands such as:

• kubectl get nodes — lists nodes in the cluster;

• kubectl apply -f service.yaml — creates or updates a resource from a file;

• kubectl get pod my_pod — gets detailed information about a Pod.

• kubectl cluster-info — views the address and status of the control plane and core services, such as the cluster DNS.

We will use these and more commands throughout the course.

In some cases, you might want to interact with the API directly. For this purpose, you can use tools like curl or client SDKs for languages such as Python or Go. This method provides a lot of flexibility and freedom for interacting with the cluster. However, it requires significant knowledge of the API and its resources.

Conclusion

A Kubernetes cluster consists of several components that work together, categorized as control plane and Node components. Additionally, Kubernetes includes add-on components that bring features not included in the core feature set, such as cluster DNS. To communicate with the cluster, you use the command-line tool, kubectl. Understanding these components and how they communicate is crucial to managing a Kubernetes cluster efficiently.