Utilizing Service Meshes

In the previous chapter, we looked at monitoring and observability. One of the obstacles to a comprehensive monitoring story is that it requires a lot of changes to the code that are orthogonal to the business logic.

In this chapter, we will learn how service meshes allow you to externalize many of those cross-cutting concerns from the application code. The service mesh is a true paradigm shift in the way you design, evolve, and operate distributed systems on Kubernetes. I like to think of it as aspect-oriented programming for cloud-native distributed systems. We will also take a deeper look into the Istio service mesh. The topics we will cover are:

• What is a service mesh?
• Choosing a service mesh
• Understanding Istio architecture
• Incorporating Istio into your Kubernetes cluster
• Working with Istio

Let’s jump right in.

What is a service mesh?

Service mesh is an architectural pattern for large-scale cloud-native applications that are composed of many microservices. When your application is structured as a collection of microservices, there is a lot going on in the boundary between microservices inside your Kubernetes cluster. This is different from traditional monolithic applications where most of the work is done by a single OS process.

Here are some concerns that are relevant to each microservice or interaction between microservices:

• Advanced load balancing
• Service discovery
• Support for canary deployments
• Caching
• Tracing a request across multiple microservices
• Authentication between services
• Throttling the number of requests a service handles at a given time
• Automatically retrying failed requests
• Failing over to an alternative component when a component fails consistently
• Collecting metrics

All these concerns are completely...

Choosing a service mesh

The service mesh concept is relatively new, but there are already many choices out there. We will be using Istio later in the chapter. However, you may prefer a different service mesh for your use case. Here is a concise review of the current cohort of service meshes.

Envoy

Envoy (https://www.envoyproxy.io) is yet another CNCF graduated project. It is a very versatile and high-performance L7 proxy. It provides many service mesh capabilities; however, it is considered pretty low-level and difficult to configure. It is also not Kubernetes-specific. Some of the Kubernetes service meshes use Envoy as the underlying data plane and provide a Kubernetes-native control plane to configure and interact with it. If you want to use Envoy directly on Kubernetes, then the recommendation is to use other open source projects like Ambassador and Gloo as an ingress controller and/or API gateway.

Linkerd 2

Linkerd 2 (https://linkerd.io) is a Kubernetes-specific...

Understanding the Istio architecture

In this section, we will get to know Istio a little better.

First, let’s meet the main components of Istio and understand what they do and how they relate.

Istio is a large framework that provides a lot of capabilities, and it has multiple parts that interact with each other and with Kubernetes components (mostly indirectly and unobtrusively). It is divided into a control plane and a data plane. The data plane is a set of proxies (one per pod). Their control plane is a set of components that are responsible for configuring the proxies and collecting telemetry data.

The following diagram illustrates the different parts of Istio, how they are related to each other, and what information is exchanged between them.

Figure 14.5: Istio architecture

As you can see, there are two primary components: the Envoy proxy, which is the sidecar container attached to every service instance (every pod), and istiod, which is responsible...

Incorporating Istio into your Kubernetes cluster

In this section, we will install Istio in a fresh cluster and explore all the service goodness it provides.

Preparing a minikube cluster for Istio

We will use a minikube cluster for checking out Istio. Before installing Istio, we should make sure our cluster has enough capacity to handle Istio as well as its demo application, BookInfo. We will start minikube with 16 GB of memory and four CPUs, which should be adequate. Make sure the Docker VM you’re using (e.g., Rancher Desktop) has sufficient CPU and memory:

$ minikube start --memory=16384 --cpus=4

Minikube can provide a load balancer for Istio. Let’s run this command in a separate terminal as it will block (do not stop the tunnel until you are done):

$ minikube tunnel
  Tunnel successfully started
  NOTE: Please do not close this terminal as this process must stay alive for the tunnel to be accessible ...

Minikube sometimes doesn’t clean...

Working with Istio

In this section, we will work with Istio resources and policies and utilize them to improve the operation of the BookInfo application.

Let’s start with traffic management.

Traffic management

Istio traffic management is about routing traffic to your services according to the destination rules you define. Istio keeps a service registry for all your services and their endpoints. Basic traffic management allows traffic between each pair of services and does simple round-robin load balancing between each service instance. But Istio can do much more. The traffic management API of Istio consists of five resources:

• Virtual services
• Destination rules
• Gateways
• Service entries
• Sidecars

Let’s start by applying the default destination rules for BookInfo:

$ kb apply -f https://raw.githubusercontent.com/istio/istio/release-1.15/samples/bookinfo/networking/destination-rule-all.yaml
destinationrule.networking...

Summary

In this chapter, we did a very comprehensive study of service meshes on Kubernetes. Service meshes are here to stay. They are simply the right way to operate a complex distributed system. Separating all operational concerns from the proxies and having the service mesh control them is a paradigm shift. Kubernetes, of course, is designed primarily for complex distributed systems, so the value of the service mesh becomes clear right away. It is also great to see that there are many options for service meshes on Kubernetes. While most service meshes are not specific to Kubernetes, it is one of the most important deployment platforms. In addition, we did a thorough review of Istio – arguably the service mesh with the most momentum – and took it through its paces. We demonstrated many of the benefits of service meshes and how they integrate with various other systems. You should be able to evaluate how useful a service mesh could be for your system and whether you...