Kubernetes components

Kubernetes, by its inherent design, functions as a distributed application. When we refer to Kubernetes, it’s not a standalone, large-scale application released in a single build for installation on a dedicated machine. Instead, Kubernetes embodies a compilation of small projects, each crafted in Go (language), collectively constituting the overarching Kubernetes project.

To establish a fully operational Kubernetes cluster, it’s necessary to individually install and configure each of these components, ensuring seamless communication among them. Once these prerequisites are fulfilled, you can commence running your containers using the Kubernetes orchestrator.

For development or local testing, it is fine to install all of the Kubernetes components on the same machine. However, in production, to meet requirements like high availability, load balancing, distributed computing, scaling, and so on, these components should be spread across different hosts. By spreading the different components across multiple machines, you gain two benefits:

• You make your cluster highly available and fault-tolerant.
• You make your cluster a lot more scalable. Components have their own life cycle; they can be scaled without impacting others.

In this way, having one of your servers down will not break the entire cluster but just a small part of it, and adding more machines to your servers becomes easy.

Each Kubernetes component has its own clearly defined responsibility. It is important for you to understand each component’s responsibility and how it articulates with the other components to understand the overall working of Kubernetes.

Depending on its role, a component will have to be deployed on a control plane node or a compute node. While some components are responsible for maintaining the state of a whole cluster and operating the cluster itself, others are responsible for running our application containers by interacting with the container runtime directly (e.g., containerd or Docker daemons). Therefore, the components of Kubernetes can be grouped into two families: control plane components and compute node components.

You are not supposed to launch your containers by yourself, and therefore, you do not interact directly with the compute nodes. Instead, you send your instructions to the control plane. Then, it will delegate the actual container creation and maintenance to the compute node on your behalf.

Figure 2.1: A typical Kubernetes workflow

Due to the distributed nature of Kubernetes, the control plane components can be spread across multiple machines. There are two ways to set up the control plane components:

• You can run all the control planes on the same machine or on different machines. To achieve maximum fault tolerance, it’s a good idea to spread the control plane components across different machines. The idea is that Kubernetes components must be able to communicate with each other, and this still can be achieved by installing them on different hosts.
• Things are simpler when it comes to compute nodes (or worker nodes). In these, you start from a standard machine running a supported container runtime, and you install the compute node components next to the container runtime. These components will interface with the local container engine that is installed on said machine and execute containers based on the instructions you send to the control plane components. Adding more computing power to your cluster is easy; you just need to add more worker nodes and have them join the cluster to make room for more containers.

By splitting the control plane and compute node components of different machines, you are making your cluster highly available and scalable. Kubernetes was built with all of the cloud-native concerns in mind; its components are stateless, easy to scale, and built to be distributed across different hosts. The whole idea is to avoid having a single point of failure by grouping all the components on the same host.

Here is a simplified diagram of a full-featured Kubernetes cluster with all the components listed. In this chapter, we’re going to explain all of the components listed in this diagram, their roles, and their responsibilities. Here, all of the control plane components are installed on a single master node machine:

Figure 2.2: A full-featured Kubernetes cluster with one control plane node and three compute nodes

The preceding diagram displays a four-node Kubernetes cluster with all the necessary components.

Bear in mind that Kubernetes is modified and, therefore, can be modified to fit a given environment. When Kubernetes is deployed and used as part of a distribution such as Amazon EKS or Red Hat OpenShift, additional components could be present, or the behavior of the default ones might differ. In this book, for the most part, we will discuss bare or vanilla Kubernetes. The components discussed in this chapter are the default ones and you will find them everywhere as they are the backbone of Kubernetes.

The following diagram shows the basic and core components of a Kubernetes cluster.

Figure 2.3: The components of a Kubernetes cluster (image source: https://kubernetes.io/docs/concepts/overview/components)

You might have noticed that most of these components have a name starting with kube: these are the components that are part of the Kubernetes project. Additionally, you might have noticed that there are two components with a name that does not start with kube. The other two components (etcd and Container Engine) are two external dependencies that are not strictly part of the Kubernetes project, but which Kubernetes needs to work:

• etcd is a third-party data store used by the Kubernetes project. Don’t worry; you won’t have to master it to use Kubernetes.
• The container engine is also a third-party engine.

Rest assured, you will not have to install and configure these components all by yourself. Almost no one bothers with managing the components by themselves, and, in fact, it’s super easy to get a working Kubernetes without having to install the components.

For development purposes, you can use minikube, which is a tool that enables developers to run a single-node Kubernetes cluster locally on their machine. It’s a lightweight and easy-to-use solution for testing and developing Kubernetes applications without the need for a full-scale cluster. minikube is absolutely NOT recommended for production.

For production deployment, cloud offerings like Amazon EKS or Google GKE provide an integrated, scalable Kubernetes cluster. Alternatively, kubeadm, a Kubernetes installation utility, is suitable for platforms without cloud access.

For educational purposes, a renowned tutorial known as Kubernetes the Hard Way by Kelsey Hightower guides users through manual installations, covering PKI management, networking, and computing provisioning on bare Linux machines in Google Cloud. While this tutorial may feel difficult for beginners, it is still recommended to practice, offering a valuable opportunity to comprehend the internals of Kubernetes. Note that establishing and managing a production-grade Kubernetes cluster, as demonstrated in Kubernetes the Hard Way, is intricate and time-consuming. It’s advised against using its results in a production environment. You will observe many references to this tutorial on the internet because it’s very famous.

We will learn about the Kubernetes control plane and compute node components in the next section.

Control plane components

These components are responsible for maintaining the state of the cluster. They should be installed on a control plane node. These are the components that will keep the list of containers executed by your Kubernetes cluster or the number of machines that are part of the cluster. As an administrator, when you interact with Kubernetes, you interact with the control plane components and the following are the major components in the control plane:

• kube-apiserver
• etcd
• kube-scheduler
• kube-controller-manager
• cloud-controller-manager

Compute node components

These components are responsible for interacting with the container runtime in order to launch containers according to the instructions they receive from the control plane components. Compute node components must be installed on a Linux machine running a supported container runtime and you are not supposed to interact with these components directly. It’s possible to have hundreds or thousands of compute nodes in a Kubernetes cluster. The following are the major component parts of the compute nodes:

• kubelet
• kube-proxy
• Container runtime

Add-on components

Add-ons utilize Kubernetes resources such as DaemonSet, Deployment, and others to implement cluster features. As these features operate at the cluster level, resources for add-ons that are namespaced are located within the kube-system namespace. The following are some of the add-on components you will see commonly in your Kubernetes clusters:

• DNS
• Web UI (dashboard)
• Container resource monitoring
• Cluster-level logging
• Network plugins

Control plane in managed Kubernetes clusters

In contrast to self-managed Kubernetes clusters, cloud services like Amazon EKS, Google GKE, and similar offerings handle the installation and configuration of most Kubernetes control plane components. They provide access to a Kubernetes endpoint, or optionally, the kube-apiserver endpoint, without exposing intricate details about the underlying machines or provisioned load balancers. This holds true for components such as kube-scheduler, kube-controller-manager, etcd, and others.

Here is a screenshot of a Kubernetes cluster created on the Amazon EKS service:

Figure 2.4: The UI console showing details of a Kubernetes cluster provisioned on Amazon EKS

We have detailed chapters to learn about EKS, GKE, and AKS later in this book.

We will learn about control plane components that are responsible for maintaining the state of the cluster in the next sections.