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

The provided YAML manifest introduces a DestinationRule resource named frontend within the blog-app namespace. This resource is associated with the host namedfrontend. Subsequently, we define subsets labeled as v1, targeting pods with the version: v1 label. Consequently, configuring our virtual service to direct traffic to thev1 destination will route requests to pods bearing the version: v1 label.

This same configuration approach can be replicated for theposts, users, and reviews microservices. However, the ratings microservice requires a slightly different configuration due to the deployment of two versions, as follows:
…
spec:
host: ratings
subsets:
name: v1 labels:
version: v1
name: v2 labels:
version: v2

The YAML manifest for the ratings microservice closely resembles that of the other microservices, with one notable distinction: it features a second subset labeled as v2, corresponding to pods bearing the version: v2 label.

Consequently, requests routed to the v1 destination target all pods with the version: v1 label,
while requests routed to the v2 destination are directed to pods labeled version: v2.

To illustrate this in a practical context, we will proceed to define virtual services for each microservice. Our starting point will be defining the virtual service for the frontend microservice, as illustrated in the following manifest:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: frontend
namespace: blog-app
spec:
hosts:
frontend http:
route:
destination: host: frontend subset: v1

The provided YAML manifest outlines a VirtualService resource named frontend within the blog-app namespace. This resource configures the host frontend with an HTTP route destination, directing all traffic to thefrontend host and specifying the v1 subset. Consequently, all requests targeting the frontend host will be routed to the v1 destination that we previously defined.

We will replicate this configuration approach for the posts, reviews, and users microservices, creating corresponding VirtualService resources. In the case of the ratings microservice, the decision is made to route all traffic to thev1 (orange stars) version. Therefore, we apply a similar VirtualService resource for the ratings microservice as well.

Now, let’s copy the manifests to the mdo-environments repository and commit and push the code to the remote repository using the following commands:
$ cd ~/mdo-environments/manifests/blog-app
$ cp ~/modern-devops/ch15/traffic-management/destination-rules.yaml .
$ cp ~/modern-devops/ch15/traffic-management/virtual-services-v1.yaml .
$ git add –all
$ git commit -m “Route to v1”
$ git push

Wait for Argo CD to sync the changes. Now, all requests will route to v1. Therefore, you will only see orange stars in the reviews, as shown in the following screenshot:

Figure 15.7 – Route to v1

Now, let’s try to roll out v2 using a canary rollout approach.