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
|
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
|
||||||
|
|
Loading…
Reference in New Issue