Deploying Our Microservices to Kubernetes

In this chapter, we will deploy the microservices in this book to Kubernetes. To bundle and configure the microservices for Deployments in different runtime environments, Helm, a package manager for Kubernetes, will be used. Before doing that, we need to review how Service discovery is used. Since Kubernetes comes with built-in support for Service discovery, it seems unnecessary to deploy Netflix Eureka for that purpose. Finally, we will also try out some Spring Boot features that facilitate the Deployment of microservices in Kubernetes.

The following topics will be covered in this chapter:

• Replacing Netflix Eureka with Kubernetes Service objects and kube-proxy for Service discovery
• Introducing how Kubernetes will be used
• Using Spring Boot’s support for graceful shutdown and probes for liveness and readiness
• Using Helm to package, configure, and deploy the microservices in different environments
...

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

If you want to view the changes applied to the source code in this chapter, that is, see what it took to deploy the microservices on Kubernetes, you can compare this source code with that in Chapter 15, Introduction to Kubernetes. You can use your favorite diff tool and compare the two folders, $BOOK_HOME/Chapter15 and $BOOK_HOME/Chapter16.

Replacing Netflix Eureka with Kubernetes Services

As shown in the previous chapter, Chapter 15, Introduction to Kubernetes, Kubernetes comes with a built-in discovery service based on Kubernetes Service objects and the kube-proxy runtime component. This makes it unnecessary to deploy a separate discovery Service such as Netflix Eureka, which we used in the previous chapters.

An advantage of using the Kubernetes discovery Service is that it doesn’t require a client library such as Spring Cloud LoadBalancer, which we have used together with Netflix Eureka. This makes the Kubernetes discovery Service easy to use, independent of which language or framework a microservice is based on.

A drawback of using the Kubernetes discovery Service is that it only works in a Kubernetes environment. However, since the discovery Service is based on kube-proxy, which accepts requests to the DNS name or IP address of a Service object, it should be fairly simple to replace it with a similar...

Introducing how Kubernetes will be used

Later on in the chapter, we will see in detail how various Kubernetes objects are used to deploy the microservices and the resource managers they depend on, like databases and queue managers. Before delving into all the details, let’s get an overview of the Kubernetes objects that will be used:

• For each microservice, database, and queue manager that will be deployed in Kubernetes, one Deployment object and one Service object will be created. For all components, except for the edge server named gateway, the Service object will be of type ClusterIP. For the gateway, the Service object will be of type NodePort, accepting external HTTPS requests on port 30433.
• The config server will use a ConfigMap, containing the configuration files in the config-repo.
• To hold credentials for the config server and its clients, two Secrets will be created: one for the config server and one for its clients.

Now that we’...

Using Spring Boot’s support for graceful shutdown and probes for liveness and readiness

Back in Spring Boot v2.3, a couple of useful features were added to support Deployments to Kubernetes:

• Graceful shutdown:

Whenever a microservice instance needs to be stopped, for example, in a rolling upgrade scenario, there is a risk that active requests are affected when the instance is stopped. To minimize this risk, Spring Boot has added support for graceful shutdown. When applying graceful shutdown, a microservice stops accepting new requests and waits for a configurable time for active requests to complete before it shuts down the application. Requests that take a longer time to complete than the shutdown wait period will be aborted. These requests will be seen as exceptional cases that a shutdown procedure can’t wait for before it stops the application.

Graceful shutdown has been enabled with a waiting period of 10 seconds for all microservices by adding...

Introducing Helm

As described above, deploying a microservice to Kubernetes requires writing manifest files that declare the desired state of a Deployment object and a Service object. If we also need to add some configuration for the microservices, manifests for ConfigMaps and Secrets must be added. The approach of declaring a desired state and handing over the responsibility to Kubernetes to ensure that the actual state is always as close as possible to the desired state is very useful.

However, writing and maintaining these manifest files can become a significant maintenance overhead. The files will contain a lot of boilerplate code, meaning duplicated manifests that will look the same for all microservices. It is also cumbersome to handle environment-specific settings without duplicating the whole set of manifest files, even though only a fraction of the content needs to be updated.

In the case of a few microservices that will only be deployed to a few environments, like...

Join our book community on Discord

https://packt.link/EarlyAccess

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 for macOS
• Chapter 22 for Windows

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 run containers appear as 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 an unhealthy...

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 the service mesh.
• Deployment...