mirror of https://github.com/istio/istio.io.git
Edit file for readability, style, grammar. (#1764)
This commit is contained in:
Will Witman
Martin Taillefer
parent
803ec1da0a
commit
d5a724dfd6
|
|
@ -9,11 +9,9 @@ aliases:
|
|||
|
||||
> This task uses the new [v1alpha3 traffic management API](/blog/2018/v1alpha3-routing/). The old API has been deprecated and will be removed in the next Istio release. If you need to use the old version, follow the docs [here](https://archive.istio.io/v0.7/docs/tasks/traffic-management/).
|
||||
|
||||
This task shows you how to gradually migrate traffic from an old to new version of a service.
|
||||
With Istio, we can migrate the traffic in a gradual fashion by using a sequence of rules
|
||||
with weights less than 100 to migrate traffic in steps, for example 10, 20, 30, ... 100%.
|
||||
For simplicity this task will migrate the traffic from `reviews:v1` to `reviews:v3` in just
|
||||
two steps: 50%, 100%.
|
||||
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.
|
||||
|
||||
## Before you begin
|
||||
|
||||
|
|
@ -22,26 +20,42 @@ two steps: 50%, 100%.
|
|||
|
||||
* Deploy the [Bookinfo](/docs/examples/bookinfo/) sample application.
|
||||
|
||||
## Weight-based version routing
|
||||
* Review the [Traffic Management](/docs/concepts/traffic-management) concepts doc.
|
||||
|
||||
1. Set the default version for all microservices to v1.
|
||||
## About this task
|
||||
|
||||
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 `reviews:v3`.
|
||||
|
||||
## Apply weight-based routing
|
||||
|
||||
1. To get started, run this command to route all traffic to the `v1` version of
|
||||
each microservice.
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl create -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
|
||||
{{< /text >}}
|
||||
|
||||
1. Confirm v1 is the active version of the `reviews` service by opening http://$GATEWAY_URL/productpage in your browser.
|
||||
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](/docs/examples/bookinfo/#determining-the-ingress-ip-and-port) doc.
|
||||
|
||||
You should see the Bookinfo application productpage displayed.
|
||||
Notice that the `productpage` is displayed with no rating stars since `reviews:v1` does not access the ratings service.
|
||||
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.
|
||||
|
||||
1. First, transfer 50% of the traffic from `reviews:v1` to `reviews:v3` with the following command:
|
||||
1. Transfer 50% of the traffic from `reviews:v1` to `reviews:v3` with the following command:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl replace -f @samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml@
|
||||
{{< /text >}}
|
||||
|
||||
Confirm the rule was replaced:
|
||||
Wait a few seconds for the new rules to propagate.
|
||||
|
||||
1. Confirm the rule was replaced:
|
||||
|
||||
{{< text bash yaml >}}
|
||||
$ istioctl get virtualservice reviews -o yaml
|
||||
|
|
@ -65,37 +79,41 @@ two steps: 50%, 100%.
|
|||
weight: 50
|
||||
{{< /text >}}
|
||||
|
||||
1. Refresh the `productpage` in your browser and you should now see *red* colored star ratings approximately 50% of the time.
|
||||
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` very many times
|
||||
> to see the proper distribution. It may require 15 refreshes or more before you see any change. You can modify the rules to route 90% of the traffic to v3 to see red stars more often.
|
||||
> 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.
|
||||
|
||||
1. When version v3 of the `reviews` microservice is considered stable, we can route 100% of the traffic to `reviews:v3`:
|
||||
1. 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:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl replace -f @samples/bookinfo/networking/virtual-service-reviews-v3.yaml@
|
||||
{{< /text >}}
|
||||
|
||||
You can now log into the `productpage` as any user and you should always see book reviews
|
||||
Now when you refresh the `/productpage` you will always see book reviews
|
||||
with *red* colored star ratings for each review.
|
||||
|
||||
## Understanding what happened
|
||||
|
||||
In this task we 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 version migration using deployment features
|
||||
of container orchestration platforms, which use instance scaling to manage the traffic.
|
||||
With Istio, we can allow the two versions of the `reviews` service to scale up and down independently,
|
||||
without affecting the traffic distribution between them.
|
||||
For more about version routing with autoscaling, check out [Canary Deployments using Istio](/blog/2017/0.1-canary/).
|
||||
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](/blog/2017/0.1-canary/).
|
||||
|
||||
## Cleanup
|
||||
|
||||
* Remove the application routing rules.
|
||||
1. Remove the application routing rules:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
|
||||
{{< /text >}}
|
||||
|
||||
* If you are not planning to explore any follow-on tasks, refer to the
|
||||
1. If you are not planning to explore any follow-on tasks, refer to the
|
||||
[Bookinfo cleanup](/docs/examples/bookinfo/#cleanup) instructions
|
||||
to shutdown the application.
|
||||
|
|
|
|||
Loading…
Reference in New Issue