• Traffic Shifting
    • Before you begin
    • Apply weight-based routing
    • Understanding what happened
    • Cleanup
    • See also

    Traffic Shifting

    This task shows you how to gradually migrate traffic from one version of amicroservice to another. For example, you might migrate traffic from an olderversion to a new version.

    A common use case is to migrate traffic gradually from one version of a microserviceto another. In Istio, you accomplish this goal by configuring a sequence of rulesthat route a percentage of traffic to one service or another. In this task, you will send50% of traffic to reviews:v1 and 50% to reviews:v3. Then, you willcomplete the migration by sending 100% of traffic to reviews:v3.

    Before you begin

    • Setup Istio by following the instructions in theInstallation guide.

    • Deploy the Bookinfo sample application.

    • Review the Traffic Management concepts doc.

    Apply weight-based routing

    If you haven’t already applied destination rules, follow the instructions in Apply Default Destination Rules.

    • To get started, run this command to route all traffic to the v1 version ofeach microservice.

    Zip

    1. $ kubectl apply -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
    • 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 inthe Bookinfo doc.

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

    • 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@

    Wait a few seconds for the new rules to propagate.

    • Confirm the rule was replaced:
    1. $ kubectl get virtualservice reviews -o yaml
    2. apiVersion: networking.istio.io/v1alpha3
    3. kind: VirtualService
    4. metadata:
    5. name: reviews
    6. ...
    7. spec:
    8. hosts:
    9. - reviews
    10. http:
    11. - route:
    12. - destination:
    13. host: reviews
    14. subset: v1
    15. weight: 50
    16. - destination:
    17. host: reviews
    18. subset: v3
    19. weight: 50
    • 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 accessesthe 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 starsmore often.

    • Assuming you decide that the reviews:v3 microservice is stable, you canroute 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@

    Now when you refresh the /productpage you will always see book reviewswith 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 blogarticle Canary Deployments using Istio.

    Cleanup

    • Remove the application routing rules:

    Zip

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

    See also

    Istio as a Proxy for External Services

    Configure Istio ingress gateway to act as a proxy for external services.

    Multi-Mesh Deployments for Isolation and Boundary Protection

    Deploy environments that require isolation into separate meshes and enable inter-mesh communication by mesh federation.

    Secure Control of Egress Traffic in Istio, part 3

    Comparison of alternative solutions to control egress traffic including performance considerations.

    Secure Control of Egress Traffic in Istio, part 2

    Use Istio Egress Traffic Control to prevent attacks involving egress traffic.

    Secure Control of Egress Traffic in Istio, part 1

    Attacks involving egress traffic and requirements for egress traffic control.

    Version Routing in a Multicluster Service Mesh

    Configuring Istio route rules in a multicluster service mesh.