
Traffic shifting and canary rollouts – Implementing Traffic Management, Security, and Observability with Istio
Consider a scenario where you’ve developed a new version of your microservice and are eager to introduce it to your user base. However, you’re understandably cautious about the potential impact on the entire service. In such cases, you may opt for a deployment strategy known as canary rollouts, also known as a Blue/Green deployment.
The essence of a canary rollout lies in its incremental approach. Instead of an abrupt transition, you methodically shift traffic from the previous version (referred to asBlue) to the new version (Green). This gradual migration allows you to thoroughly test the functionality and reliability of the new release with a limited subset of users before implementing it across the entire user base. This approach minimizes the risks associated with deploying new features or updates and ensures a more controlled and secure release process. The following figure illustrates this process beautifully:

Figure 15.8 – Canary rollouts
Here’s how a canary rollout strategy works:
- Initial release: The existing version (referred to as the baseline or current version) continues to serve the majority of users.
- Early access: A small group of users or systems, typically selected as a representative sample, is identified as the canary group. They receive the new version.
- Monitoring and evaluation: The software’s performance and behavior in the canary group are closely monitored. Metrics, logs, and user feedback are collected to identify issues or anomalies.
- Gradual expansion: If the new version proves stable and performs as expected in the canary group, its exposure is incrementally expanded to a broader user base. This expansion can occur in stages, with a small percentage of users being “promoted” to the new version at each stage.
- Continuous monitoring: Throughout the rollout, continuous monitoring and analysis are critical to identify and address any emerging issues promptly. If problems are detected, the rollout can be halted or reversed to protect the majority of users.
- Full deployment: Once the new version has been successfully validated through the canary rollout stages, it is eventually made available to the entire user base.
So, let’s roll out the ratings-v2 service to 20% of our users. For that, we’ll use the following
VirtualService resource:
…
http:
route:
destination: host: ratings
subset: v1
weight: 80
destination: host: ratings subset: v2
weight: 20
As we can see, we’ve modified the ratings virtual service to introduce a second destination pointing to the v2 subset. A noteworthy addition in this configuration is the introduction of the weight attribute. For the v1 destination, we have assigned a weight of 80, while the v2 destination carries a weight of 20. This means that20% of the traffic will be directed to thev2 version of the ratings microservice, providing a controlled and adjustable distribution of traffic between the two versions.
Let’s copy the manifest and then commit and push the changes to the remote repository using the following commands:
$ cd ~/mdo-environments/manifests/blog-app
$ cp ~/modern-devops/ch15/traffic-management/virtual-services-canary.yaml \
virtual-services.yaml
$ git add –all
$ git commit -m “Canary rollout”
$ git push
Following the completion of the Argo CD sync, if you refresh the page 10 times, you’ll observe that black stars appear twice out of those 10 times. This is a prime example of a canary rollout in action. You can continue monitoring the application and gradually adjust the weights to shift traffic towardv2. Canary rollouts effectively mitigate risks during production rollouts, providing a method to address the fear of the unknown, especially when implementing significant changes.
However, another approach exists to test your code in a production environment that involves using live traffic without exposing your application to end users. This method is known as traffic mirroring. We’ll delve into it in the following discussion.
Leave a Reply