-
Notifications
You must be signed in to change notification settings - Fork 671
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 many Gateway Listeners #5160
support many Gateway Listeners #5160
Conversation
@@ -212,7 +202,6 @@ func desiredContainers(contour *model.Contour, contourImage, envoyImage string) | |||
SuccessThreshold: int32(1), | |||
TimeoutSeconds: int32(1), | |||
}, | |||
Ports: ports, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In testing this, I realized that every time a new Gateway Listener with a new port is added, it triggers a rollout of Envoy because the container ports change. Here, I've stopped setting container ports on the Envoy workload entirely, since it's not required in order to expose the port anyway and mostly serves as documentation, so that Listener changes don't trigger Envoy rollouts. Definitely interested in folks' thoughts here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@izturn @wilsonwu @Jean-Daniel I'd be interested in any input you have here. Let me know if you need more context!
1974a5b
to
853c44e
Compare
91c7df5
to
d6d35fa
Compare
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #5160 +/- ##
=======================================
Coverage ? 78.25%
=======================================
Files ? 138
Lines ? 18585
Branches ? 0
=======================================
Hits ? 14544
Misses ? 3762
Partials ? 279
|
Still need to look at the upgrade path here; since the ports used internally are changing, the Envoy service needs to be updated as part of the upgrade and I'm guessing there will be some expected downtime. Also need to check whether upgrading the provisioner does the right thing upgrading existing Gateways, or not. |
7863641
to
9d4f56c
Compare
The Contour project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack |
172f84c
to
33ffdbe
Compare
This is now passing the upstream dynamic listener ports conformance PR with no modifications thanks to @sunjayBhatia's work to upgrade to v0.6.2. |
The Contour project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack |
33ffdbe
to
d68c47d
Compare
d68c47d
to
8608387
Compare
I've been doing some upgrade testing to test out the different listener port mapping schemes, but because of #5375, I think that actually there's currently some downtime for any provisioner-driven upgrade. I'll see if I can get at least a spike of a fix for #5375 implemented, which then should allow for a better comparison between the port mapping schemes. |
8608387
to
8e9f81b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤩
still digesting, some comments so far!
Signed-off-by: Steve Kriss <[email protected]>
Signed-off-by: Steve Kriss <[email protected]>
Signed-off-by: Steve Kriss <[email protected]>
Signed-off-by: Steve Kriss <[email protected]>
Signed-off-by: Steve Kriss <[email protected]>
Signed-off-by: Steve Kriss <[email protected]>
Signed-off-by: Steve Kriss <[email protected]>
Signed-off-by: Steve Kriss <[email protected]>
Signed-off-by: Steve Kriss <[email protected]>
Signed-off-by: Steve Kriss <[email protected]>
Signed-off-by: Steve Kriss <[email protected]>
Signed-off-by: Steve Kriss <[email protected]>
Signed-off-by: Steve Kriss <[email protected]>
8aa1bf0
to
632a6a1
Compare
Signed-off-by: Steve Kriss <[email protected]>
@skriss this is looking great! Sorry I was never able to give feedback earlier, but I can test now. I'm assuming you are still using the same image tag, so I'll try testing with your steveheptio/contour:many-listeners image. |
@Rycieos thanks! Let me push the latest image, I'm not sure which version that tag currently refers to. Will update here in a sec. |
OK, latest versions have been pushed:
|
I was not; I need TLSRoutes, but not TCP. |
}, | ||
}, | ||
TLS: &gatewayapi_v1beta1.GatewayTLSConfig{ | ||
Mode: ref.To(gatewayapi_v1beta1.TLSModePassthrough), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i assume this is because we don't have a secret that makes sense in terminate mode since TLS is specified on the HTTPProxy?
now i remember discussing this a bit before but seeing it just now threw me for a second, could be a little counterintuitive for users, still on the fence
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, this test case can be switched to use the custom protocol, in which case the whole TLS
block can be removed (this is pretty much the point of supporting the custom protocol, so users don't have to specify tls mode: passthrough which as you say is counterintuitive)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I guess I have a test case below that uses the custom protocol, so this is more just documentation that this is a valid alternate way of configuring things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The basic problem is that if you specify a protocol of HTTPS, then the Gateway API webhook requires TLS mode to be specified, and if you set it to terminate, then it further requires a secret to be specified. So this is all just to work around the webhook logic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple small comments, but overall looks great! nice test coverage and looks like the gateway conformance is passing 👍🏽
Unfortunately, I am unable to test this; due to this limitation on
I need to But since this is a different message than I got last time, I guess you fixed that problem. Sorry I can't report better results. |
OK, sounds like we have some more work to do to fully support your use case (though this PR is a big step in the right direction). There's some conflicting information upstream about the exact combos of listener protocol and route type that should be supported:
So will need to track down exactly what should be supported. I think thus far we had implemented on the basis of https://gateway-api.sigs.k8s.io/guides/tls/, which indicates TLSRoute is for Passthrough mode. From my perspective, it seems like TLS termination should be compatible with both TLSRoute (if you need to make a routing decision on the basis of SNI) and TCPRoute (if there's no routing decision to be made, all traffic arriving on the listener port will be proxied to the service(s) in the TCPRoute). Since you say you need TLSRoute - does that imply you need to make a routing decision based on SNI? If not, then TLS Termination + TCPRoute should be sufficient. If you could open a new issue to track this work, that'd be great. Thanks! |
That is correct. Routing by SNI is an extremely useful feature, and as far as I can tell, only Traefik supports that part of the Gateway API currently. Or at least is the only provider that supports
I opened #5461 |
Signed-off-by: Steve Kriss <[email protected]>
Adds support for programming an arbitrary number
of Gateway listeners in Envoy and the Envoy service.
Closes #4960.