From 629b74a8b2559f33d8e8f861e83efe6892fa4cb3 Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Wed, 26 Sep 2018 15:07:23 -0400 Subject: [PATCH] Add canary rollout to concepts doc (#2697) * Add canary rollout to concepts doc * tweak --- .../docs/concepts/traffic-management/index.md | 26 +++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/content/docs/concepts/traffic-management/index.md b/content/docs/concepts/traffic-management/index.md index 01f42c17b1..4a9178c719 100644 --- a/content/docs/concepts/traffic-management/index.md +++ b/content/docs/concepts/traffic-management/index.md @@ -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