Managing traffic with Istio – Implementing Traffic Management, Security, and Observability with Istio-1

Istio offers robust traffic management capabilities that form a core part of its functionality. When leveraging Istio for microservice management within your Kubernetes environment, you gain precise control over how these services communicate with each other. This empowers you to define the traffic path within your service mesh meticulously.

Some of the traffic managementfeatures at your disposal are as follows:
• Request routing
• Fault injection
• Traffic shifting
• TCP traffic shifting
• Request timeouts
• Circuit breaking
• Mirroring

The previous section employed an ingress gateway to enable traffic entry into our mesh and used a virtual service to distribute traffic to the services. With virtual services, the traffic distribution happens in a round-robin fashion by default. However, we can change that using destination rules. These rules provide us with an intricate level of control over the behavior of our mesh, allowing for a more granular management of traffic within the Istio ecosystem.

Before we delve into that, we need to update our Blog App so that it includes a new version of the ratings service deployed as ratings-v2, which will return black stars instead of orange stars. I’ve already updated the manifest for that in the repository. Therefore, we just need to copy that to the mdo-environments repository, commit it, and push it remotely using the following commands:
$ cd ~/mdo-environments/manifests/blog-app/
$ cp ~/modern-devops/ch15/traffic-management/blog-app.yaml .
$ git add –all
$ git commit -m “Added ratings-v2 service”
$ git push

Wait for the application to sync. After this, we need to do a few things:

1. Go to the Blog App home page > Sign In > Not a User? Create an account and create a new account.
2. Click on the Actions tab > Add a Post, add a new post with a title and content of your choice, and click Submit.
3. Use the Add a Review text field to add a review, provide a rating, and click Submit.
4. Click on Posts again and access the post that we had created.

Now, keep refreshing the page. We will see that we get orange stars half the time and black stars for the rest. Traffic is splitting equally acrossv1 and v2 (that is, the orange and black stars):

Figure 15.6 – Round robin routing

This occurs due to the absence of destination rules, which leaves Istio unaware of the distinctions between v1 and v2. Let’s define destination rules for our microservices to rectify this, clearly informing Istio of these versions. In our case, we have one version for each microservice, except for the ratings microservice, so we’ll define the following destination rules accordingly.

Let’s start by defining the destination rule of the frontend microservice:
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: frontend
namespace: blog-app
spec:
host: frontend
subsets:
name: v1 labels:
version: v1