Traffic Shifting

This task shows you how to shift traffic from one version of a microservice to another.

A common use case is to migrate traffic gradually from an older version of a microservice to a new one. In Istio, you accomplish this goal by configuring a sequence of routing rules that redirect a percentage of traffic from one destination to another.

In this task, you will use send 50% of traffic to reviews:v1 and 50% to reviews:v3. Then, you will complete the migration by sending 100% of traffic to reviews:v3.

Istio includes beta support for the Kubernetes Gateway API and intends to make it the default API for traffic management in the future. The following instructions allow you to choose to use either the Gateway API or the Istio configuration API when configuring traffic management in the mesh. Follow instructions under either the Gateway API or Istio classic tab, according to your preference.

Note that this document uses the Gateway API to configure internal mesh (east-west) traffic, i.e., not just ingress (north-south) traffic. Configuring internal mesh traffic is an experimental feature of the Gateway API, currently under development and pending upstream agreement. Make sure to install the experimental CRDs before using the Gateway API:

  1. $ kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=v0.6.2" | kubectl apply -f -

Before you begin

Apply weight-based routing

If you haven’t already, follow the instructions in define the service versions.

  1. To get started, run this command to route all traffic to the v1 version:

Zip

  1. $ kubectl apply -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@

Zip

  1. $ kubectl apply -f @samples/bookinfo/gateway-api/route-reviews-v1.yaml@
  1. Open the Bookinfo site in your browser. The URL is http://$GATEWAY_URL/productpage, where $GATEWAY_URL is the External IP address of the ingress, as explained in the Bookinfo doc.

    Notice that the reviews part of the page displays with no rating stars, no matter how many times you refresh. This is because you configured Istio to route all traffic for the reviews service to the version reviews:v1 and this version of the service does not access the star ratings service.

  2. Transfer 50% of the traffic from reviews:v1 to reviews:v3 with the following command:

Zip

  1. $ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml@

Zip

  1. $ kubectl apply -f @samples/bookinfo/gateway-api/route-reviews-50-v3.yaml@
  1. Wait a few seconds for the new rules to propagate and then confirm the rule was replaced:
  1. $ kubectl get virtualservice reviews -o yaml
  2. apiVersion: networking.istio.io/v1beta1
  3. kind: VirtualService
  4. ...
  5. spec:
  6. hosts:
  7. - reviews
  8. http:
  9. - route:
  10. - destination:
  11. host: reviews
  12. subset: v1
  13. weight: 50
  14. - destination:
  15. host: reviews
  16. subset: v3
  17. weight: 50
  1. $ kubectl get httproute reviews -o yaml
  2. apiVersion: gateway.networking.k8s.io/v1beta1
  3. kind: HTTPRoute
  4. ...
  5. spec:
  6. parentRefs:
  7. - group: gateway.networking.k8s.io
  8. kind: Service
  9. name: reviews
  10. port: 9080
  11. rules:
  12. - backendRefs:
  13. - group: ""
  14. kind: Service
  15. name: reviews-v1
  16. port: 9080
  17. weight: 50
  18. - group: ""
  19. kind: Service
  20. name: reviews-v3
  21. port: 9080
  22. weight: 50
  23. matches:
  24. - path:
  25. type: PathPrefix
  26. value: /
  27. status:
  28. parents:
  29. - conditions:
  30. - lastTransitionTime: "2022-11-10T18:13:43Z"
  31. message: Route was valid
  32. observedGeneration: 14
  33. reason: Accepted
  34. status: "True"
  35. type: Accepted
  36. ...
  1. Refresh the /productpage in your browser and you now see red colored star ratings approximately 50% of the time. This is because the v3 version of reviews accesses the star ratings service, but the v1 version does not.

    With the current Envoy sidecar implementation, you may need to refresh the /productpage many times –perhaps 15 or more–to see the proper distribution. You can modify the rules to route 90% of the traffic to v3 to see red stars more often.

  2. Assuming you decide that the reviews:v3 microservice is stable, you can route 100% of the traffic to reviews:v3 by applying this virtual service:

Zip

  1. $ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-v3.yaml@

Zip

  1. $ kubectl apply -f @samples/bookinfo/gateway-api/route-reviews-v3.yaml@
  1. Refresh the /productpage several times. Now you will always see book reviews with red colored star ratings for each review.

Understanding what happened

In this task you migrated traffic from an old to new version of the reviews service using Istio’s weighted routing feature. Note that this is very different than doing version migration using the deployment features of container orchestration platforms, which use instance scaling to manage the traffic.

With Istio, you can allow the two versions of the reviews service to scale up and down independently, without affecting the traffic distribution between them.

For more information about version routing with autoscaling, check out the blog article Canary Deployments using Istio.

Cleanup

  1. Remove the application routing rules:

Zip

  1. $ kubectl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
  1. $ kubectl delete httproute reviews
  1. If you are not planning to explore any follow-on tasks, refer to the Bookinfo cleanup instructions to shutdown the application.