Kubernetes Bootcamp

We are sure that many of you have used Kubernetes in some capacity—you may have clusters running in production or you may have kicked the tires using kubeadm, Minikube, or Docker Desktop. Our goal for this book is to go beyond the basics of Kubernetes and, as such, we didn't want to rehash all the basics of Kubernetes. Instead, we added this chapter as a bootcamp for anyone that may be new to Kubernetes or might have only played around with it a bit.

Since this is a bootcamp chapter, we will not go in depth into every topic, but by the end, you should know enough about the basics of Kubernetes to understand the remaining chapters. If you have a strong Kubernetes background, you may still find this chapter useful as a refresher, and we will get into more complex topics starting in Chapter 4, Services, Load Balancing, ExternalDNS, and Global Balancing.

In this chapter, we will cover the components of a running Kubernetes cluster, which include...

Technical requirements

This chapter has no technical requirements.

If you want to execute commands while learning about the resources, you can use the KinD cluster that was deployed in the previous chapter.

An overview of Kubernetes components

In any infrastructure, it is always a good idea to understand how the systems work together to provide services. With so many installer options out there today, many Kubernetes users have not had the need to understand how Kubernetes components integrate.

A few short years ago, if you wanted to run a Kubernetes cluster, you needed to install and configure each component manually. It was a steep learning curve to install a functioning cluster, which often led to frustration, causing many people and companies to say "Kubernetes is just too difficult." The advantage of installing manually was that you truly understood how each component interacted, and if your cluster ran into issues after installation, you knew what to look for.

Nowadays, most people will click a button on a cloud provider and have a fully functioning Kubernetes cluster in minutes. On-premises installations have become just as easy, with options from Google, Red...

Exploring the control plane

As its name suggests, the control plane controls every aspect of a cluster. If your control plane goes down, you can probably imagine that your cluster will encounter issues. Without a control plane, a cluster will not have any scheduling abilities, which means that workloads that are running will remain running unless they are stopped and restarted. Since the control plane is extremely important, it is always suggested that you have at least three master nodes. Many production installations run more than three master nodes, but the number of installed nodes should always be an odd number. Let's look at why the control plane and its components are so vital to a running cluster by examining each one.

The Kubernetes API server

The first component to understand in a cluster is the kube-apiserver component. Since Kubernetes is application programming interface (API)-driven, every request that comes into a cluster goes through the API server. Let...

Understanding the worker node components

Worker nodes, as the name implies, are responsible for running workloads. When we discussed the kube-scheduler component of the control plane, we mentioned that when a new Pod is scheduled, the kube-scheduler component will decide which node to run the Pod on. It does this using information that has been sent to it from the worker nodes. This information is constantly updated to help spread Pods around a cluster to utilize resources efficiently.

Each worker node has two main components, kubelet and kube-proxy:

kubelet

You may hear a worker node referred to as a kubelet. The kubelet is an agent that runs on all worker nodes, and it is responsible for running the actual containers.

kube-proxy

Contrary to the name, kube-proxy is not a proxy server at all. kube-proxy is actually responsible for routing network communication between a Pod and the network.

Container runtime

Each node also needs a container runtime. A container...

Interacting with the API server

As we mentioned earlier, you interact with the API server using either direct API requests or the kubectl utility. We will focus on using kubectl for the majority of our interaction in this book, but we will call out using direct API calls where applicable.

Using the Kubernetes kubectl utility

kubectl is a single executable file that allows you to interact with the Kubernetes API using a command-line interface (CLI). It is available for most major operating systems and architectures, including Linux, Windows, and Mac.

Installation instructions for most operating systems are located on the Kubernetes site at https://kubernetes.io/docs/tasks/tools/install-kubectl/. Since we are using Linux as our operating system for the exercises in the book, we will cover installing kubectl on a Linux machine. Follow these steps:

1. To download the latest version of kubectl, you can run a curl command that will download it, as follows:

   curl...

Introducing Kubernetes resources

This section will contain a lot of information and, since this is a bootcamp, we will not go into deep details on each resource. As you can imagine, each resource could have its own chapter, or multiple chapters, in a book. Since there are many books on Kubernetes that go into detail on the base resources, we will only cover the required details of each to have an understanding of each one. In the following chapters, we will include additional details for resources as we build out our cluster using the book exercises.

Before we go on to understand what Kubernetes resources really are, let's first explain Kubernetes manifests.

Kubernetes manifests

The files that we will use to create Kubernetes resources are referred to as manifests. A manifest can be created using YAML or JSON—most manifests use YAML, and that is the format we will use throughout the book.

The content of a manifest will vary depending on the resource, or...

Summary

In this chapter, you were thrown into a Kubernetes bootcamp that presented a lot of technical material in a short amount of time. Try to remember that this will all become easier as you get into the Kubernetes world in more depth. We realize that this chapter had a lot of information on many resources. Many of the resources will be used in later chapters, and they will be explained in greater detail.

You learned about each Kubernetes component and how they interact to create a cluster. With this knowledge, you have the required skills to look at errors in a cluster and determine which component may be causing an error or issue. We covered the control plane of a cluster where the api-server, kube-scheduler, Etcd, and control managers run. The control plane is how users and services interact with a cluster; using the api-server and the kube-scheduler will decide which worker node to schedule your Pod(s) on. You also learned about Kubernetes nodes that run the kubelet and...

Questions

1. A Kubernetes control plane does not include which of the following components?
   1. api-server
   2. kube-scheduler
   3. Etcd
   4. Ingress controller
2. What is the name of the component that keeps all of the cluster information?
   1. api-server
   2. Master controller
   3. kubelet
   4. Etcd
3. Which component is responsible for selecting the node that will run a workload?
   1. kubelet
   2. api-server
   3. kube-scheduler
   4. Pod-scheduler
4. Which option would you add to a kubectl command to see additional output from a command?
   1. Verbose
   2. -v
   3. –verbose
   4. -log
5. Which service type creates a randomly generated port, allowing incoming traffic to any worker node on the assigned port to access the service?
   1. LoadBalancer
   2. ClusterIP
   3. None—it's the default for...