-
Notifications
You must be signed in to change notification settings - Fork 30
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
Handle more than about 64 TLS Knative Routes #317
Comments
Wearing my Gateway API maintainer hat, it's absolutely intended that implementations may merge Gateways together into a single data plane config, but we don't mandate it. So the sort of sharding you're describing is definitely possible. The exact details of how it will work may vary with the underlying data path implementation though. |
Interestingly enough we've seen Routes take longer to become 'Ready=True` as the number of increases. The root cause seems to be the underlying ingress implementation ie. see contour HTTProxy's timings: projectcontour/contour#4058 I don't think we've done similar tests with TLS routes where gateways & listeners increase |
This issue is stale because it has been open for 90 days with no |
This issue or pull request is stale because it has been open for 90 days with no activity. This bot triages issues and PRs according to the following rules:
You can:
/lifecycle stale |
This issue is stale because it has been open for 90 days with no |
/remove-lifecycle stale |
This issue is stale because it has been open for 90 days with no |
/remove-lifecycle stale |
I've created a GEP issue to help address this - kubernetes-sigs/gateway-api#1713 Note the Gateway API folks have a limit on the # of listeners per Gateway and it's 64 |
(update from @dprotaso) See this comment for the current limit: #317 (comment)
We add a Listener (and a certificate reference) per Knative Route (KIngress). Each one is around 300 bytes, which means that we can probably fit around 3000 Routes into one Gateway before we exceed etcd storage limits.
According to some of the gateway maintainers, we should be able to split these across multilpe Gateways that all share the same IP address (so that users can still get that nice wildcard DNS mapping).
This issue tracks packing Listeners into multiple Gateways, it's extracted from[ this PR comment
The text was updated successfully, but these errors were encountered: