In this topic, you will look at the components that comprise a Kubernetes cluster and how they work together to form a cluster architecture. You will learn about their individual functions and how each component communicates with the remainder 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 of a Kubernetes cluster is the control plane. Components inside the control plane manage the state of the cluster and decide how to allocate resources. They monitor the state of the cluster and ensure that the desired state is maintained.
It is the responsibility of the Kubernetes API server to process messages that come from Kubernetes clients. The API server is the primary way of interacting with the cluster and the messages it receives can be requests to create, change, or delete resources. In short, it changes the desired state of the system based on the user's requests.
It is possible to interact with the API directly by using tools like curl or programmatically by using various libraries available in languages such as Python, Java, or Go. This method allows you to flexibly interact with the cluster, giving you more freedom. But it requires a significant amount of knowledge of the API and its resources.
The kubectl command-line tool and the Kubernetes dashboard are some common ways to interact with a Kubernetes cluster. Both give you a high-level interface for managing the cluster.
The API server stores the cluster state in the etcd data store, which serves as the Kubernetes control plane's single source of truth. The etcd is a distributed key-value store that holds the configuration and state date of the cluster. In short, it stores the necessary data required for the correct functioning of the cluster, including the network and pod configurations, network policies, and much more. It replicates all this data across all the nodes in the cluster, ensuring highly available and redundant storage.
The Kubernetes Controller Manager ensures that the cluster's desired state is always maintained. It monitors the etcd for any changes that, if found, are then applied to the cluster, bringing it back to the desired state. It does this by managing several controllers such as the Deployment, StatefulSet, and the ReplicaSet controller, each one with its own responsibilities.
The Kubernetes Scheduler assigns pods to nodes in the cluster after considering the resource requirements and constraints of pods. It also monitors the etcd to retrieve information about nodes and pods. Based on that information, it makes scheduling decisions.
Node components
Kubernetes runs on a distributed infrastructure while node components manage individual nodes within the distributed cluster. Inside these nodes, there are kubelet, kube-proxy, and container runtime.
A node can be a physical or a virtual machine. It is these machines that run the containers that make up an application. A node has access to a set of resources such as CPU, memory, and storage in order to run containers. And when the need arises, the control plane can create more nodes as needed.
Nodes and the console plane communicate through the API server. For example, when the nodes create a new pod or its characteristics change, it sends a request to the API server with the updated status. Then, the API server updates the etcd so that all other components are aware of the change.
Inside the nodes run the pods. Pods are the smallest deployable units in Kubernetes. In this way, they form the foundation of the Kubernetes cluster. This means that other Kubernetes components are built on top of pods. Kubernetes uses pods to run everything from individual control plane components to containers that run the user's applications.
Each pod has its own IP address, which it uses to communicate with other pods in the same cluster, regardless of the node they are running on. The pod's IP address can be addressed directly by other pods in the same namespace using that IP address.
The kubelet is a service that runs on every node in the cluster. It is responsible for managing the containers running on the node's pods and the state of the pod itself. It is the task of the kublet to make sure that both the node and the pods that run on a node work as intended. Not only that, but it is the kublet that handles the communication with the API server to receive a pod's definitions and ensures that containers run as expected.
The kube-proxy is a component of Kubernetes that runs on each node in the cluster and handles network proxying. Its primary purpose is to manage the network connectivity between pods and services. The kube-proxy accomplishes this by managing network rules and connections on the node's network stack, allowing traffic to be routed to the correct destination.
The container runtime manages the containers on the node. They can start or stop containers, monitor their resources, and maintain the continued health of a container. To do this, Kubernetes supports several container runtimes, including Docker, containers, and CRI-O.
In terms of communication, the container runtime interacts with the kubelet running on the same node. The kubelet sends instructions to the container runtime on what containers to start, stop, or restart. The container runtime reports back to the kubelet on the status of the containers.
The container runtime also communicates with the container image registry to download images for the containers it needs to start. When a container starts, the container runtime retrieves the image from the registry and launches a new container based on the image.
Kubernetes storage
Kubernetes itself doesn't provide persistent storage. This can be bothersome when you want to store data beyond the lifetime of a pod. To still allow the option of persistent data, Kubernetes has a storage subsystem that allows integration with external storage solutions. This includes both local and network-attached storage.
Usually, external storage systems provide the storage layer in Kubernetes. These external storage systems are connected to the cluster by the storage-layer subsystem.
Add-on components
Kubernetes allows you to install add-on components on top of a Kubernetes cluster. These add-ons can enable features that aren't included in the core feature set. For example, networking, monitoring, and logging.
Conclusion
A Kubernetes cluster architecture is composed of several components that work together. This includes the control plane components, such as the Kubernetes API Server, etcd, Kubernetes Controller Manager, and Kubernetes Scheduler, as well as the node components, like Node, kubelet, kube-proxy, and container runtime.
All these components are built on top of pods, which are the smallest deployable units in Kubernetes. That makes pods the foundation of the cluster. Understanding these components and how they communicate is crucial to manage a Kubernetes cluster efficiently.