Introduction to Kubernetes

In this chapter, we will start to learn about Kubernetes, the most popular and widely used container orchestrator at the time of writing this book. Since the subjects on container orchestrators in general and Kubernetes itself are too big to be covered in one chapter, I will focus on introducing the areas that I have found to be the most important in my use of Kubernetes over the last few years.

The following topics will be covered in this chapter:

• Introducing Kubernetes concepts
• Introducing Kubernetes API objects
• Introducing Kubernetes runtime components
• Creating a local Kubernetes cluster
• Trying out a sample Deployment and getting used to the kubectl Kubernetes CLI tool
• Managing a local Kubernetes cluster

Technical requirements

For instructions on how to install the tools used in this book and how to access the source code for this book, see:

• Chapter 21, Installation Instructions for macOS
• Chapter 22, Installation Instructions for Microsoft Windows with WSL 2 and Ubuntu

The code examples in this chapter all come from the source code in $BOOK_HOME/Chapter15. The source code for the sample Deployment on Kubernetes that will be performed in this chapter can be found in the folder $BOOK_HOME/Chapter15/kubernetes/first-attempts.

Introducing Kubernetes concepts

At a high level, as a container orchestrator, Kubernetes makes a cluster of (physical or virtual) servers that runs containers appear to be one big logical server running containers.

As an operator, we declare a desired state to the Kubernetes cluster by creating objects using the Kubernetes API. Kubernetes continuously compares the desired state with the current state. If it detects differences, it takes action to ensure that the current state is the same as the desired state.

One of the main purposes of a Kubernetes cluster is to deploy and run containers, but also to support zero-downtime rolling upgrades using techniques such as green/blue and canary Deployments. Kubernetes can schedule containers, that is, Pods that contain one or more co-located containers, to the available nodes in the cluster. To be able to monitor the health of running containers, Kubernetes assumes that containers implement a liveness probe. If a liveness probe reports...

Introducing Kubernetes API objects

Kubernetes defines an API that is used to manage different types of objects or resources, as they are also known. Some of the most commonly used types, or kinds, as referred to in the API, are as follows:

• Node: A node represents a server, virtual or physical, in the cluster.
• Pod: A Pod represents the smallest possible deployable component in Kubernetes, consisting of one or more co-located containers. The containers share the same IP address and port range. This means that containers in the same Pod instance can talk to each other over localhost, but need to be aware of potential port collisions. Typically, a Pod consists of one container, but there are use cases for extending the functionality of the main container by running the second container in a Pod. In Chapter 18, Using a Service Mesh to Improve Observability and Management, a second container will be used in the Pods, running a sidecar that makes the main container join...

Introducing Kubernetes runtime components

A Kubernetes cluster contains two types of nodes: master nodes and worker nodes. Master nodes manage the cluster, while the main purpose of worker nodes is to run the actual workload, for example, the containers we deploy in the cluster. Kubernetes is built up of a number of runtime components. The most important components are as follows:

• There are components that run on master nodes, constituting the control plane:
  • The API server, the entry point to the control plane. This exposes a RESTful API, which, for example, the Kubernetes CLI tool known as kubectl uses.
  • etcd, a highly available and distributed key-value store, used as a database for all cluster data.
  • A controller manager, which contains a number of controllers that continuously evaluate the desired state versus the current state for the objects defined in the etcd database. Whenever the desired or current state changes, a controller that&...

Creating a Kubernetes cluster using Minikube

Now, we are ready to create a Kubernetes cluster! We will use Minikube to create a local single-node cluster. Minikube can be deployed in a VM, a container, or on bare metal using different drivers. We will use one of the preferred drivers, the Docker driver, where the Minikube instance runs in a container managed by Docker Desktop on macOS and Windows with Windows Subsystem for Linux, v2 (WSL 2).

For information on the available drivers in Minikube, see https://minikube.sigs.k8s.io/docs/drivers/.

Docker and its containers are already running in a separate WSL 2 instance; see the Installing Docker Desktop for Windows section in Chapter 22, Installation Instructions for Microsoft Windows with WSL 2 and Ubuntu.

One drawback of running Minikube as a container on Docker is that ports exposed by Minikube are only accessible on the host that runs Docker. To make the ports available to Docker clients, for example, macOS...

Trying out a sample Deployment

Let’s see how we can do the following:

• Deploy a simple web server based on NGINX in our Kubernetes cluster
• Apply some changes to the Deployment:
  • Change the current state by deleting the Pod and verify that the ReplicaSet creates a new one
  • Change the desired state by scaling the web server to three Pods and verify that the ReplicaSet fills the gap by starting up two new Pods
• Route external traffic to the web server using a Service with a node port

First, create a namespace, first-attempts, and update the kubectl context to use this namespace by default:

kubectl create namespace first-attempts
kubectl config set-context $(kubectl config current-context) --namespace=first-attempts

We can now create a Deployment of NGINX in the namespace using the kubernetes/first-attempts/nginx-deployment.yaml file. This file looks as follows:

apiVersion: apps/v1
kind: Deployment
metadata...

Managing a local Kubernetes cluster

A running Kubernetes cluster consumes a lot of resources, mostly memory. So, when we are done working with a Kubernetes cluster in Minikube, we must be able to hibernate it in order to release the resources allocated to it. We also need to know how to resume the cluster when we want to continue working with it. Eventually, we must also be able to permanently remove the cluster when we don’t want to keep it on disk anymore.

Minikube comes with a stop command that can be used to hibernate a Kubernetes cluster. The start command we used to initially create the Kubernetes cluster can also be used to resume the cluster from its hibernated state. To permanently remove a cluster, we can use the delete command from Minikube.

Hibernating and resuming a Kubernetes cluster

Run the following command to hibernate (that is, stop) the Kubernetes cluster:

minikube stop

Run the following command to resume (that is, start) the Kubernetes...

Join our book community on Discord

https://packt.link/EarlyAccess

In this chapter, we will learn how to use distributed tracing to better understand how our microservices cooperate, for example, in fulfilling a request sent to the external API. Being able to utilize distributed tracing is essential for being able to manage a system landscape of cooperating microservices. As already described in Chapter 8, Introduction to Spring Cloud, Micrometer Tracing will be used to collect trace information, and Zipkin will be used for the storage and visualization of said trace information.In this chapter, we will learn about the following topics:

• Introducing distributed tracing with Micrometer Tracing and Zipkin.
• How to add distributed tracing to the source code.
• How to programmatically add information to the traces.
• How to perform distributed tracing, visualizing both successful and unsuccessful API requests. We will see how both synchronous and asynchronous processing can be visualized.

...

Technical requirements

For instructions on how to install the tools used in this book and how to access the source code for this book, see:

• Chapter 21 for macOS
• Chapter 22 for Windows

The code examples in this chapter all come from the source code in $BOOK_HOME/Chapter14.If you want to view the changes applied to the source code in this chapter, that is, see what it took to add distributed tracing using Micrometer Tracing and Zipkin, you can compare it with the source code for Chapter 13, Improving Resilience Using Resilience4j. You can use your favorite diff tool and compare the two folders, $BOOK_HOME/Chapter13 and $BOOK_HOME/Chapter14.