-
Notifications
You must be signed in to change notification settings - Fork 729
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
Knative support #903
Comments
Just chiming in, I'd also like this or something similar |
I am also interested in moving this forward.. I wonder what the limitations are right now, is the only blocker related to watching Knative resources to trigger flagger features? @edude03 @Niksko |
I would say one of the major blockers is that Knative does not support header based traffic routing (ref: knative/serving#4736), which would mean Flagger won't be able to support the A/B deployment strategy for Knative. |
I think the Knative (and for that Cloud Run) approach for a/b testing would be to use tags. https://knative.dev/development/serving/traffic-management/ |
👋 Hi I'm the Serving lead on the Knative project @cgrotz is correct you can use tags when manipulating the traffic block and that'll give you a unique URL per revision. @aryan9600 if you have further questions let me know - I'm in the knative/cncf slack with the same handle as my GitHub (@dprotaso) |
With tag-based header routing, you should be able to use Alternatively, you could use Knative tags for the backend and create your own front-end Istio, Linkerd, etc and rewrite the Host header so that you're steering traffic to specific revisions, which might be more appropriate for the canary-selection logic (for example). |
A useful feature of Flagger is metric-based rollout/rollback https://docs.flagger.app/usage/metrics. While currently in Knative, the gradual rollout is time based https://knative.dev/docs/serving/rolling-out-latest-revision/#procedure It would be great that the metric-based rollout/rollback feature of Flagger could support Knative. |
Hey folks, support for Knative is on the roadmap: https://github.com/fluxcd/flagger#integrations. We're planning to start work on this soon, but are pre-occupied by a few other higher priority items. Thanks :) |
Feel free to reach out if you have questions; in particular, Knative has
two modes for stamping out Revisions, depending on whether the
Service/Configuration's `spec.template.metadata.name` is set:
* If unset, Knative will automatically create a name which can be difficult
to predict in advance/keep consistent across clusters
* If set, Knative will only create a new Revision when the `name` changes,
since Revisions are immutable.
…On Fri, Aug 26, 2022, 3:24 AM Sanskar Jaiswal ***@***.***> wrote:
Hey folks, support for Knative is on the roadmap:
https://github.com/fluxcd/flagger#integrations. We're planning to start
work on this soon, but are pre-occupied by a few other higher priority
items. Thanks :)
—
Reply to this email directly, view it on GitHub
<#903 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB4XEN5Y6BYBD6SPU7JBJW3V3BWJZANCNFSM44UGO4QQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
(FYI, we added Prometheus monitoring annotations for the This means that all of: Istio, Contour and Kourier should export HTTP metrics by default which can be used to control rollouts via Flagger. |
Any news on this topic? It would be very important to have knative support. |
@jpfaria I think we need to upvote this to gain relevance |
Describe the feature
Knative currently supports weighted routing, but doesn't have any of the features of Flagger around automating the rollout of new versions. However it feels like the primitives are there. This issues has been discussed in the past (#92), but I wondered if it was time to bring it up again, with both Flagger and Knative having matured since then.
The slightly incongruous portion of this integration would be the fact that Knative has native support for 'versions'. However this seems like it means that Flagger has less to do, since the logic to maintain multiple versions of an application is handled for us in Knative.
Proposed solution
Allow for Flagger to watch Knative primitives for updates, and to create and update objects that implement a routing change accordingly.
Any alternatives you've considered?
Writing a custom controller just for Knative wouldn't be that hard. However the custom controller would likely re-implement much of the functionality and logic of Flagger, around coordinating canaries, A/B tests, rollback, metric monitoring etc. Likewise with implementing this functionality in Knative itself.
The text was updated successfully, but these errors were encountered: