Knative support

[Niksko]

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.

[edude03]

Just chiming in, I'd also like this or something similar

[salaboy]

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 wonder if @dprotaso has tried this out at some point. Because I think that having some of this integration will be a great PoC.

[aryan9600]

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.
Progressive delivery does seem possible to implement in theory, as Flagger would just need to modify the Knative Service .spec.traffic.weights of the revisions to drive the canary analysis forward

[cgrotz]

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/

[dprotaso]

👋 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)

[evankanderson]

With tag-based header routing, you should be able to use tags along with Knative's built-in weighted traffic distribution without needing to directly interface with Istio, Contour, etc.

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).

[ZhiminXiang]

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.

[aryan9600]

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 :)

[evankanderson]

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: ***@***.***>

[evankanderson]

(FYI, we added Prometheus monitoring annotations for the net-kourier plugin in the 1.9 release: knative-extensions/net-kourier#978)

This means that all of: Istio, Contour and Kourier should export HTTP metrics by default which can be used to control rollouts via Flagger.

[jpfaria]

Any news on this topic? It would be very important to have knative support.

[salaboy]

@jpfaria I think we need to upvote this to gain relevance