-
Notifications
You must be signed in to change notification settings - Fork 680
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
Gateway Port <> envoy-service-http(s)-address serve flags #3616
Comments
Another thought would be to move to use Gateway for Contour by default and have them select root HTTPProxies. Then we can deprecate the flags noted above and use the ports from the Gateway exclusively. |
So, we would always have a Contour Gateway, that could also refer to HTTPProxy resources? Having a Gateway able to refer to HTTPProxy resources as a type of Route is actually a great idea regardless, but this one does sound interesting. |
Yeah the thought would be to move Contour to use a Gateway to configure the listeners regardless of if you're using HTTPRoute, TLSRoute, etc. We'd have to add support for Ingress/HTTPProxy, but would give you a single place to define the listener parameters and removes gateway-api from being a "special" implementation. |
Once we have Contour managing the Envoy Service at least, this would be a nice option, but I think we'll have to keep the old way around for a while (that is do a proper deprecation cycle), since people may not want to install Alpha CRDs in their clusters. |
The Contour project currently lacks enough contributors to adequately respond to all Issues. This bot triages Issues according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack |
I think this can be closed now, see https://projectcontour.io/docs/1.27/config/gateway-api/#gateway-listeners |
Contour defines the ports which Envoy listens on via a set of
contour serve
flags:These are defined in a Gateway.Listeners now. Need to find a pattern to not use the contour serve flags but allow the Gateway.Listener ports to take precedence in the event someone is utilizing GatewayAPI.
The text was updated successfully, but these errors were encountered: