mirror of https://github.com/istio/istio.io.git
Add canary rollout to concepts doc (#2697)
* Add canary rollout to concepts doc * tweak
This commit is contained in:
parent
2cbd271fc2
commit
629b74a8b2
|
@ -292,6 +292,32 @@ increased network latency, or an overloaded upstream service. Aborts are
|
|||
crash failures that mimic failures in upstream services. Aborts usually
|
||||
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
|
||||
|
||||
Istio provides a simple configuration model to
|
||||
|
|
Loading…
Reference in New Issue