Enable automated canary deployments using Services

[dicarlo2]

Currently, using the /spec/release key in a Service allows for simple blue/green deployments, but for automated canaries (e.g. using spinnaker) we'd like to have 3 groups:

1. new version
2. with an equal traffic split to a) on the old version
3. the remainder on the old version.

E.g., initially we might do 1/ 5%, 2/ 5% and 3/ 90% and then slowly increase 1/ and 2/. We could compare the metrics from 1/ against 2/ to determine release health. This seems like a pretty standard rollout procedure, so I think it makes sense to incorporate it directly into the higher level Service object.

[mattmoor]

This is covered well by Route, but not Service (today).

Let's consider this as part of the "Service v1" conversation.

[mattmoor]

The surface available at HEAD supports this in Service, which now simply inlines ConfigurationSpec and RouteSpec. The knative/docs repo at HEAD reflects this, and this will all be in the 0.6 release.

[polothy]

Sorry, having trouble following your comment. Is there a link to the doc/sample you mentioned?

[jonnylangefeld]

I’m also interested in this functionality and don’t think this Use case is covered today. All tutorials/docs only show how you can manually change the traffic splitting, but there’s no built in automation that slowly changes traffic routing from 10% to 20% to 30% all the way to 100% to migrate traffic.

[markusthoemmes]

@jonnylangefeld check out https://knative.dev/docs/developer/serving/rolling-out-latest-revision/! It‘s experimental‘ish so feedback will be very appreciated!

[jonnylangefeld]

Thanks @markusthoemmes for the pointer! Looks promising. Is the traffic shifting only time based? What if the new revision throws errors? Would the time based traffic shifting continue?

[markusthoemmes]

Yes, right now the amount of traffic shifted is only time based as it's main motivation at the time was to smooth over weird autoscaling ripple effects if a traffic shift is done very harshly.
Reacting to actual failures in the new revision and similar signals was out of scope for this specific piece. IIRC the line of thought at the time was, that such a rollout strategy would require higher-level abstraction and much more control over which signals the rollout would actually use.

[jonnylangefeld]

Okay I see! Thanks for the summary.
I will take a look at flagger which takes metrics into account and works on custom resources. So technically it should be able to manipulate the traffic percentages on the Service.serving.knative.dev/v1 resource.

[markusthoemmes]

Interesting! Please let us know how the experiment went, this sounds like a great integration use-case!