Add canary rollout to concepts doc (#2697)

* Add canary rollout to concepts doc

* tweak
This commit is contained in:
Frank Budinsky 2018-09-26 15:07:23 -04:00 committed by GitHub
parent 2cbd271fc2
commit 629b74a8b2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 26 additions and 0 deletions

View File

@ -292,6 +292,32 @@ increased network latency, or an overloaded upstream service. Aborts are
crash failures that mimic failures in upstream services. Aborts usually crash failures that mimic failures in upstream services. Aborts usually
manifest in the form of HTTP error codes or TCP connection failures. manifest in the form of HTTP error codes or TCP connection failures.
## Canary rollout
The idea behind canary rollout is to introduce a new version of a service by first testing
it using a small percentage of user traffic and then, if all goes well, gradually increase
the percentage until all the traffic is moved to the new version. If anything
goes wrong along the way, the rollout is aborted and the traffic is returned to the old version.
Although container orchestration platforms like Docker, Mesos/Marathon, or Kubernetes provide features
that support canary rollout, they are limited by the fact that they use instance scaling to manage
the traffic distribution. For example, to send 10% of traffic to a canary version requires 9 instances of
the old version to be running for every 1 instance of the canary.
This becomes particularly difficult in production deployments where autoscaling is needed.
When traffic load increases, the autoscaler needs to scale instances of both versions concurrently,
making sure to keep the instance ratio the same.
Another problem with the instance deployment approach is that it only
supports a simple (random percentage) canary rollout. It's not possible to limit the
visibility of the canary to requests based on some specific criteria.
With Istio, traffic routing and instance deployment are two completely independent functions.
The number of instances implementing services are free to scale up and down based on traffic load,
completely orthogonal to the control of version traffic routing. This makes managing a canary
version in the presence of autoscaling a much simpler problem.
See [Canary Deployments using Istio](/blog/2017/0.1-canary/) for more about
the interoperability of canary deployment and autoscaling when using Istio.
## Rule configuration ## Rule configuration
Istio provides a simple configuration model to Istio provides a simple configuration model to