Migrating Traffic to v2 and Removing Test Rules

![](https://lh5.googleusercontent.com/WLvX01Oja8R_cMb_AD91jIiF0bHW0nSJTRJ6Vt3Xz75MLzivZ5-ghHEZkdTJryhNXyTCUemF4OwxYn_96ntimOwyjABuZjaH3O2RsJyYQbqWoQgvSQktQd98t3T3Qe3KZSd20Cam) Once the v2 version has been thoroughly tested, we can use Istio to proceed with a canary test using the rule shown previously, or we can simply migrate all of the traffic from v1 to v2, optionally in a gradual fashion by using a sequence of rules with weights less than 100 (for example: 10, 20, 30, ... 100). This traffic control is independent of the number of pods implementing each version. If, for example, we had auto scaling in place, and high traffic volumes, we would likely see a corresponding scale up of v2 and scale down of v1 pods happening independently at the same time. For more about version routing with autoscaling, check out ["Canary Deployments using Istio"](https://istio.io/blog/canary-deployments-using-istio.html). In our case, we’ll send all of the traffic to v2 with one command: ``` cat \<\<EOF | istioctl replace -f - apiVersion: config.istio.io/v1alpha2 kind: RouteRule metadata: name: reviews-default spec: destination: name: reviews route: - labels: version: v2 weight: 100 EOF ``` We should also remove the special rule we created for the tester so that it doesn’t override any future rollouts we decide to do: ``` istioctl delete routerule reviews-test-v2

After thoroughly testing the v2 version of the reviews service, Istio can be used to proceed with a canary test using previously defined rules, or to fully migrate all traffic from v1 to v2. This migration can be done gradually by using a sequence of Istio rules with increasing weights (e.g., 10, 20, 30, ..., 100). The traffic control is independent of the number of pods implementing each version; autoscaling could lead to v2 pods scaling up and v1 pods scaling down concurrently. The document then provides a command to send all traffic to v2 by replacing the existing 'reviews-default' route rule with one that routes 100% of the traffic to the v2 version. Finally, it emphasizes the importance of removing the special rule created earlier for the tester user, to prevent it from interfering with future rollouts or routing configurations. This ensures that the routing behavior is as expected for all users and avoids unintended side effects during subsequent deployments or testing phases.