This task shows you how to gradually migrate traffic from one version of a microservice to another. For example, you might migrate traffic from an older version to a new version.
A common use case is to migrate traffic gradually from one version of a microservice
to another. In Istio, you accomplish this goal by configuring a sequence of rules
that route a percentage of traffic to one service or another. In this task, you will send
%50 of traffic to
reviews:v1 and %50 to
reviews:v3. Then, you will
complete the migration by sending %100 of traffic to
Before you begin
Setup Istio by following the instructions in the Installation guide.
Deploy the Bookinfo sample application.
Review the Traffic Management concepts doc.
Apply weight-based routing
To get started, run this command to route all traffic to the
v1version of each microservice.
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
Open the Bookinfo site in your browser. The URL is
$GATEWAY_URLis 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:v1and this version of the service does not access the star ratings service.
Transfer 50% of the traffic from
reviews:v3with the following command:
$ 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:
$ kubectl get virtualservice reviews -o yaml apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews ... spec: hosts: - reviews http: - route: - destination: host: reviews subset: v1 weight: 50 - destination: host: reviews subset: v3 weight: 50
/productpagein your browser and you now see red colored star ratings approximately 50% of the time. This is because the
reviewsaccesses the star ratings service, but the
v1version does not.
With the current Envoy sidecar implementation, you may need to refresh the
/productpagemany times –perhaps 15 or more–to see the proper distribution. You can modify the rules to route 90% of the traffic to
v3to see red stars more often.
Assuming you decide that the
reviews:v3microservice is stable, you can route 100% of the traffic to
reviews:v3by applying this virtual service:
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-v3.yaml@
Now when you refresh the
/productpageyou 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.
Remove the application routing rules:
$ kubectl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
If you are not planning to explore any follow-on tasks, refer to the Bookinfo cleanup instructions to shutdown the application.
Describes how to deploy a custom ingress gateway using cert-manager manually.
How to use Istio for traffic management without deploying sidecar proxies.
Introduction, motivation and design principles for the Istio v1alpha3 routing API.
Describes how to configure Istio ingress with a network load balancer on AWS.
An introduction to safer, lower-risk deployments and release to production.
Describes a simple scenario based on Istio's Bookinfo example.