Performing the blue/green deployment

It is time to gradually move more and more users to the new versions using blue/green deployment. To perform the deployment, run the following steps:

  1. Ensure that the load test tool, Siege, is still running.

    It was started in the preceding Verifying that all traffic initially goes to the v1 version of the microservices section.

  2. To allow 20% of users to be routed to the new v2 version of the review microservice, we can patch the virtual service and change weights with the following command: 

   kubectl patch virtualservice review --type=json -p='[
     {"op": "add", "path": "/spec/http/1/route/0/weight", "value":  
     80},
     {"op": "add", "path": "/spec/http/1/route/1/weight", "value":  
     20}
   ]'

  1. To observe the change in the routing rule, go to the Kiali web UI (https://kiali.minikube.me) and select the Graph view.

  2. Click on the Display menu and change the edge labels to Requests Distribution.

  3. Wait for a minute before the metrics are updated in Kiali so that we can observe the change. Expect the graph in Kiali to show something like the following:

    Figure 18.27: 80% goes to v1 services and 20% goes to v2 services

Depending on how long you have waited, the graph might look a bit different! In the screenshot, we can see that Istio now routes traffic to both the v1 and v2 versions of the review microservice.

Of the 33% of the traffic that is sent to the review microservice from the product-composite microservice, 6.4% is routed to the new v2 Pod, and 26.9% to the old v1 Pod. This means that 6.4/33 = 19% of the requests are routed to the v2 Pod, and 26.9/33 = 81% to the v1 Pod. This is in line with the 20/80 distribution we have requested.

Please feel free to try out the preceding kubectl patch command to affect the routing rules for the other core microservices, product and recommendation.

To simplifying changing the weight distribution for all three core microservices, the./kubernetes/routing-tests/split-traffic-between-old-and-new-services.bash script can be used. For example, to route all traffic to the v2 version of all microservices, run the following script, feeding it with the weight distribution 0 100: 

./kubernetes/routing-tests/split-traffic-between-old-and-new-services.bash 0 100

You have to give Kiali a minute or two to collect metrics before it can visualize the changes in routing, but remember that the change in the actual routing is immediate!

Expect that requests are routed only to the v2 versions of the microservices in the graph after a while:

Figure 18.28: All traffic goes to v2 services

Depending on how long you have waited, the graph might look a bit different!

If something goes terribly wrong following the upgrade to v2, the following command can be executed to revert all traffic back to the v1 version of all microservices: 

./kubernetes/routing-tests/split-traffic-between-old-and-new-services.bash 100 0

After a short while, the graph in Kiali should look like the screenshot in the previous Verifying that all traffic initially goes to the v1 version of the microservices section, showing all requests going to the v1 version of all microservices again.

This concludes the introduction to the service mesh concept and Istio as an implementation of it.

Before we wrap up the chapter, let's recap how we can run tests in Docker Compose to ensure that the source code of our microservices does not rely 0on either the deployment in Kubernetes or the presence of Istio.

Running tests with Docker Compose

As mentioned a few times now, it is important to ensure that the source code of the microservices doesn't become dependent on a platform such as Kubernetes or Istio from a functional perspective.

To verify that the microservices work as expected without the presence of Kubernetes and Istio, run the tests as described in Chapter 17 (refer to the Testing with Docker Compose section). Since the default values of the test script, test-em-all.bash, have been changed, as described previously in the Running commands to create the service mesh section, the following parameters must be set when using Docker Compose: USE_K8S=false HOST=localhost PORT=8443 HEALTH_URL=https://localhost:8443. For example, to run the tests using the default Docker Compose file, docker-compose.yml, run the following command: 

USE_K8S=false HOST=localhost PORT=8443 HEALTH_URL=https://localhost:8443 ./test-em-all.bash start stop

The test script should, as before, begin by starting all containers; it should then run the tests, and, finally, stop all containers. For details of the expected output, see Chapter 17 (refer to the Verifying that the microservices work without Kubernetes section).

After successfully executing the tests using Docker Compose, we have verified that the microservices are dependent on neither Kubernetes nor Istio from a functional perspective. These tests conclude the chapter on using Istio as a service mesh.