-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable automated canary deployments using Services #2721
Comments
This is covered well by Route, but not Service (today). Let's consider this as part of the "Service v1" conversation. |
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. |
Sorry, having trouble following your comment. Is there a link to the doc/sample you mentioned? |
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. |
@jonnylangefeld check out https://knative.dev/docs/developer/serving/rolling-out-latest-revision/! It‘s experimental‘ish so feedback will be very appreciated! |
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? |
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. |
Okay I see! Thanks for the summary. |
Interesting! Please let us know how the experiment went, this sounds like a great integration use-case! |
I did take a look at flagger and while it's pretty cool, it unfortunately doesn't work with |
Sounds like it'd theoretically be possible to teach Flagger to talk Knative API as well though 🤔. Looking at the top of https://docs.flagger.app/ it looks like we'd have to teach it to talk Knative Service/Knative Route API for it to be able to do the switcheroo. Since it already seems to implement the API of various other projects, it'd be interesting to go ask if they'd be game for a Knative implementation as well. |
fluxcd/flagger#903 actually considers this. |
Integrating with Flagger to deploy Knative functions would definitely be something interesting as it would be one tool for both functions and container-based services. Also, to add to the conversation, I have not tried Gloo, but it seems like it could also be a way to perform Canary deployments and it has a 1st class integration with Knative. |
Gloo's CLI installs a Knative version that's two years old - I'm not sure what kind of testing they perform but I'm guessing the integration has rotted. I'd open an issue on the gloo github to bump Knative if you're interesting in working with it long term. Is there anything actionable for us to do in Knative serving? From reading the thread this stood out:
It seems like we should potentially document/clarify/fix the semantics of the rollout duration when the next revision fails. But I'm tempted to make separate issue and close this out. So far it seems this issue was opened just to track the flagger integration. But I'd rather folks comment upstream to signal you want Knative support. |
Going to close this out as we have the following related issues |
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: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.
The text was updated successfully, but these errors were encountered: