The following are the technical requirements to proceed with this chapter:

• A basic understanding of the Linux OS and how to handle basic operations in Linux
• One or more Linux machines

The code and snippets used in the chapter are tested on the Fedora workstation. All the code, commands, and other snippets for this chapter can be found in the GitHub repository at https://github.com/PacktPublishing/The-Kubernetes-Bible-Second-Edition/tree/main/Chapter02.

Kubernetes derives its name from Greek origins, specifically from the word “kubernētēs,” which translates to helmsman or pilot. This nautical term signifies someone skilled in steering and navigating a ship. The choice of this name resonates with the platform’s fundamental role in guiding and orchestrating the deployment and management of containerized applications, much like a helmsman steering a ship through the complexities of the digital landscape.

In addition to its formal name, Kubernetes is commonly referred to as “K8s” within the community. This nickname cleverly arises from the technique of abbreviating the word by counting the eight letters between the “K” and the “s.” This shorthand not only streamlines communication but also adds a touch of informality to discussions within the Kubernetes ecosystem.

To run Kubernetes, you will require Linux machines, which are called nodes in Kubernetes. A node could be a physical machine or a virtual machine on a cloud provider, such as an EC2 instance. There are two types of node in Kubernetes:

• Control plane nodes (also known as master nodes)
• Compute nodes (also known as worker nodes)

The master and worker nodes

In various contexts, you might encounter the terms “master nodes” and “worker nodes,” which were previously used to describe the conventional hierarchical distribution of roles in a distributed system. In this setup, the “master” node oversaw and assigned tasks to the “worker” nodes. However, these terms may carry historical and cultural connotations that could be perceived as insensitive or inappropriate. In response to this concern, the Kubernetes community has chosen...

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...

In the following sections, let us explore the different control plane components and their responsibilities.

kube-apiserver

Kubernetes’ most important component is a Representational State Transfer (REST) API called kube-apiserver, which exposes all the Kubernetes features. You will be interacting with Kubernetes by calling this REST API through the kubectl command-line tool, direct API calls, or the Kubernetes dashboard (Web UI) utilities.

The role of kube-apiserver

kube-apiserver is a part of the control plane in Kubernetes. It’s written in Go, and its source code is open and available on GitHub under the Apache 2.0 license. To interact with Kubernetes, the process is straightforward. Whenever you want to instruct Kubernetes, you send an HTTP request to kube-apiserver. Whether it’s creating, deleting, or updating a container, you always make these calls to the appropriate kube-apiserver endpoint using the right HTTP...

We will dedicate this part of the chapter to explaining the anatomy of a compute node by explaining the three components running on it:

• Container engine and container runtime
• kubelet
• The kube-proxy component

  kubelet, kube-proxy, and container runtime are essential components for both control plane (master) nodes and worker nodes. We’ll cover them in this section to highlight their functionalities in both contexts.

Container engine and container runtime

A container engine is a software platform designed to oversee the creation, execution, and lifecycle of containers. It offers a more abstract layer compared to a container runtime, streamlining container management and enhancing accessibility for developers. Well-known container engines are Podman, Docker Engine, and CRI-O. In contrast, container runtime is a foundational software component responsible for the creation, execution, and administration...

kubectl is the official command-line tool used to manage the Kubernetes platform. This is an HTTP client that is fully optimized to interact with Kubernetes and allows you to issue commands to your Kubernetes cluster.

As you’ve observed earlier, Kubernetes is a clustering solution. Its distributed nature allows it to run on multiple machines. By splitting the different components across different machines, you’ll be able to make your Kubernetes cluster highly available. Next, we will have a brief discussion on the different Kubernetes setups.

The single-node cluster

Installing all Kubernetes components on the same machine is the worst possible idea if you want to deploy Kubernetes in production. However, it is perfectly fine for testing your development. The single-node way consists of grouping all of the different Kubernetes components on the same host or a virtual machine:

Figure 2.9: All of the components are working on the same machine

Typically, this arrangement is seen as a solid beginning for getting into Kubernetes through local testing. There’s a tool called minikube that makes it easy to set up single-node...

This was quite a big chapter, but at least you now have a list of all the Kubernetes components. Everything we will do later will be related to these components: they are the core of Kubernetes. This chapter was full of technical details too, but it was still relatively theoretical. Don’t worry if things are still not very clear to you. You will gain a better understanding through practice.

The good news is that you are now completely ready to install your first Kubernetes cluster locally, and things are going to be a lot more practical from now on. That is the next step, and that’s what we will do in the next chapter. After the next chapter, you’ll have a Kubernetes cluster running locally on your workstation, and you will be ready to run your first pods using Kubernetes!

To learn more about the topics that were covered in this chapter, take a look at the following resources:

• Kubernetes components: https://kubernetes.io/docs/concepts/overview/components/
• Cloud controller manager: https://kubernetes.io/docs/concepts/architecture/cloud-controller/
• Installing Kubernetes utilities (kubectl, kind, kubeadm, and minikube): https://kubernetes.io/docs/tasks/tools/
• Kubernetes legacy package repository changes on September 13, 2023: https://kubernetes.io/blog/2023/08/31/legacy-package-repository-deprecation/
• pkgs.k8s.io: Introducing Kubernetes Community-Owned Package Repositories: https://kubernetes.io/blog/2023/08/15/pkgs-k8s-io-introduction/
• Operating etcd clusters for Kubernetes: https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/
• kubectl completion: https://kubernetes.io/docs/reference/kubectl/generated/kubectl_completion/
• Runtime class: https://kubernetes.io/docs...