Let's look at another scenario where we will route traffic to v2 of the reviews microservice to a named user and test the microservice. This is accomplished by making changes to the virtual service, which does not require recycling the pods or services. Let's take a look:

1. First, we will make changes to the existing reviews of the virtual service to add identity-based routing. Let's review the changes to the existing reviews virtual service:

# Script : 04-identity-based-traffic-routing.yaml

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1

Notice that a rule has been added to match the http headers. If the user is jason, it routes the traffic to v2 of reviews; otherwise, it directs all other traffic to v1, which is the default.

2. Modify the virtual service:

$ kubectl -n istio-lab apply -f 04-identity-based-traffic-routing.yaml
virtualservice.networking.istio.io/reviews configured

It may take a few seconds for the changes to propagate to the proxy sidecar.

3. Go back to the browser and click Sign in (top-right corner of the screen), type in jason, and click Sign in.

You will notice that the review page starts to show black stars, which comes from v2 of the reviews microservice. Refresh the page a few times. You will notice that only black stars show every time. Click Sign out and notice that the black stars disappear and that the traffic is routed to v1 of the reviews microservice.

We can use regex expressions to form complex matching expressions:

  http:
  - match
    - headers:
        end-user:
          regex: (Iniesta|Don Andres)
    route:
    - destination: 
      host: reviews 
      subset: v2

For example, in the preceding YAML snippet, if the user is Iniesta or Don Andres, the request will be directed to the reviews:v2 microservice. This is an example of selectively directing a few users to a new version of the same microservice while retaining the original version in actual use. For example, you have created a new UI for the same service and want to get feedback from a few select users; you can accomplish the same through a set of configuration changes without having to change anything in any of the microservices.

This type of routing is sometimes referred to as dark launches or friends and family testing, as only a few select people or internal departments are chosen to test the new releases without impacting the main business before the new releases get field-tested.

The preceding code shows that the service mesh is providing an infrastructure layer for the application, which can be configured independently of the original application. Earlier, in traditional legacy applications, this capability required coding to be done at the application level to process the headers and route the traffic.

The virtual service can be configured in such a manner so that Chrome browser traffic is routed to reviews:v3, whereas all other browsers, traffic is shifted to reviews:v2.

4. Review the following script:

# Script : 05-chrome-browser-traffic-routing.yaml

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - match:
    - headers:
        user-agent:
          regex: ".*Chrome.*"
    route:
    - destination:
        host: reviews
        subset: v3
  - route:
    - destination:
        host: reviews
        subset: v2

5. Apply the preceding rule:

$ kubectl -n istio-lab apply -f 05-chrome-browser-traffic-routing.yaml
virtualservice.networking.istio.io/reviews configured

Refresh the productpage web page. Notice that if you are using the Chrome browser, v3 of the reviews service will show red stars, while all other browsers (such as Firefox) will show black stars through v2 of reviews. 

When needed, you can easily form complex conditional matching expressions for routing traffic, like so:

http:
  - match:
    - headers:
        user-agent:
          regex: ".*Chrome.*"
        end-user:
          regex: (Iniesta|Don Andres)
    - headers:
        end-user:
          exact: Xavi
    route:
    - destination:
        host: reviews
        subset: v3
  - route:
    - destination:
        host: reviews
        subset: v1

In the matching expression in the preceding code, if Iniesta or Don Andres logs in from Chrome or user Xavi logs in from any browser, traffic will be directed to version v3 of the reviews microservice. For all other login instances, traffic will be routed to reviews:v1.

Now that we've learned about identity-based routing, we will move on to traffic shifting concepts to show canary deployments and blue/green deployments.