-
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
Support for Gateway APIs #1089
Labels
kind/feature
Feature request
Comments
Yes this is on the roadmap cfd2ff9#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5 I should update the name, as now is called Gateway API. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the feature
Many ingress solutions now provide the gateway api or seem likely to in the future. Current providers (from the docs) include Istio, Contour, Traefik, Kong, Emissary, Consul, and GKE ingress.
The Gateway API supports a
weight
field on BackendRef. If Flagger supported the Gateway APIs, it could potentially just work™️ with a large set of ingress providers going forward.This would allow the same flagger configuration for a service to continue working even if the ingress provider changes over time (because the APIs flagger is configuring will remain the same across providers).
Proposed solution
Support the Gateway API as a "mesh provider", using the weight on BackendRef's to provide canary deployments.
Any alternatives you've considered?
Although many projects now support the Gateway API, I am personally not up to speed on the overall state of that community and whether we should expect Gateway API support to continue to be developed and reach a stable v1 API. But I think the same concern applies to any of the currently-supported mesh providers as well.
The text was updated successfully, but these errors were encountered: