Implementing Kubernetes Features to Simplify the System Landscape

The current microservice landscape contains several supporting services that implement important design patterns required in a large-scale microservice landscape, for example, an edge server, config server, authorization server, and a service for distributed tracing. For a recap, refer to Chapter 1, Introduction to Microservices. In the previous chapter, we replaced the implementation of the design pattern for service discovery, based on Netflix Eureka, with the built-in discovery service in Kubernetes. In this chapter, we will further simplify the microservice landscape by reducing the number of supporting services required to be deployed. Instead, the corresponding design patterns will be handled by built-in capabilities in Kubernetes. The Spring Cloud Config Server will be replaced with Kubernetes ConfigMaps and Secrets. The Spring Cloud Gateway will be replaced by a Kubernetes Ingress object, which can act as an...

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

If you want to view the changes applied to the source code in this chapter, that is, see what it took to replace the Spring Cloud Config Server and Spring Cloud Gateway with corresponding features in Kubernetes, and use cert-manager to provision certificates, you can compare it with the source code for Chapter 16, Deploying Our Microservices to Kubernetes. You can use your favorite diff tool and compare the two folders, $BOOK_HOME/Chapter16 and $BOOK_HOME/Chapter17.

Replacing the Spring Cloud Config Server

As we have seen in the previous chapter, ConfigMaps and Secrets can be used to hold configuration information for our microservices. The Spring Cloud Config Server adds features such as keeping all configurations in one place, optional version control using Git, and the ability to encrypt sensitive information on the disk. But it also consumes a non-negligible amount of memory (as with any Java and Spring-based application) and adds significant overhead during startup.

For example, when running automated integration tests such as the test script we are using in this book, test-em-all.bash, all microservices are started up at the same time, including the configuration server. Since the other microservices must get their configuration from the configuration server, they all have to wait for the configuration server to be up and running before they can start up themselves. This leads to a significant delay when running integration tests. If...

Replacing the Spring Cloud Gateway

In this section, we will further simplify the microservice landscape by replacing the Spring Cloud Gateway using the built-in Ingress object in Kubernetes, reducing the number of supporting services required to be deployed.

As introduced in Chapter 15, Introduction to Kubernetes, an Ingress object can be used in Kubernetes to act as an edge server in the same way as a Spring Cloud Gateway. The Spring Cloud Gateway comes with a richer routing functionality compared to an Ingress object. However, the Ingress is part of the Kubernetes platform, requiring no extra deployments, and can also be extended using cert-manager to automatically provision certificates, as we will see later in this chapter.

We have also used the Spring Cloud Gateway to protect our microservices from unauthenticated requests, by requiring a valid OAuth 2.0/OIDC access token from a trusted OAuth authorization server or OIDC provider. See Chapter 11, Securing Access to APIs...

Automating certificate provisioning

The cert-manager tool (https://cert-manager.io/docs/) is a certificate management controller for Kubernetes.

It can facilitate the automated creation, provisioning, and rotation of certificates. It supports several sources for the certificates; for example:

• An RFC8555 (https://tools.ietf.org/html/rfc8555)-compliant ACME server such as Let’s Encrypt (https://letsencrypt.org)
• HashiCorp Vault PKI Secrets Engine (https://www.vaultproject.io/docs/secrets/pki)
• Self-signed certificates, issued by cert-manager itself

For a full list of available issuers, see https://cert-manager.io/docs/configuration/.

Since self-signed certificates don’t require communication with any external resources, they are a good candidate for use during development. We will use them within the scope of this book.

Using cert-manager in production typically requires the use of an issuer, such as Let’s Encrypt...

Testing with Kubernetes ConfigMaps, Secrets, Ingress, and cert-manager

With the preceding changes described, we are ready to test the system landscape with the Spring Cloud Config Server and the Spring Cloud Gateway replaced by Kubernetes ConfigMaps, Secrets, an Ingress object, and cert-manager. As before, when we used the Spring Cloud Gateway as the edge server, the external API will be protected by HTTPS. With this deployment, it will be the Ingress controller that uses the certificate provisioned by cert-manager to protect the external API with HTTPS. This is illustrated in the following diagram:

Figure 17.3: Protecting external access using HTTPS

The Ingress controller is exposed on the default HTTPS port, 443, on the Minikube instance. On the host, where we run the Minikube instance as a Docker container, we communicate with the Minikube instance via localhost. When the Minikube instance was created, port forwarding was configured from port 8443 on localhost to the...

Verifying that the microservices work without Kubernetes

In this chapter and the previous one, we have seen how features in the Kubernetes platform, such as ConfigMaps, Secrets, Services, and Ingress objects, can simplify the effort of developing a landscape of cooperating microservices. But it is important to ensure that the source code of the microservices doesn’t become dependent on the platform from a functional perspective. Avoiding such a lock-in makes it possible to change to another platform in the future, if required, with minimal effort. Changing the platform should not require changes in the source code, but only in the configuration of the microservices.

Testing the microservices using Docker Compose and running the test-em-all.bash verification script will ensure that they work from a functional perspective without Kubernetes. When running microservices without Kubernetes, we will lack the non-functional features that Kubernetes provides us with, for example...

Join our book community on Discord

https://packt.link/EarlyAccess

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
• Verifying the deployments...

Technical requirements

For instructions on how to install 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/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 it with the source code for Chapter 15, Introduction to Kubernetes. You can use your favorite diff tool and compare the two folders, $BOOK_HOME/Chapter15 and $BOOK_HOME/Chapter16.