Skip to content
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

Address de facto shared ports for Kong handling of Gateway Listeners #2606

Open
4 tasks
rainest opened this issue Jun 23, 2022 · 1 comment
Open
4 tasks

Comments

@rainest
Copy link
Contributor

rainest commented Jun 23, 2022

Problem Statement

This is one possible way to lift the "one KIC one Gateway" constraint.

#2555 implements the Gateway spec as written: Gateway Listener hostname compatibility is only checked within a port, since you can (in abstract) open listens on ports 443 and 8443 and add HTTPS routing configuration for example.com on both that points to different backends. For a more practical example, you'd set up multiple NGINX server blocks with different listen ports, the same server_name, and different proxy_pass upstreams.

Kong's HTTP subsystems doesn't work this way. There is no equivalent of server differentiation by listen port. Its HTTP listens use a single list of ports and serve all routes of that type on all listened ports. To properly implement the Gateway spec, we need to not do this, and allow HTTP(S) routes on a subset of ports only.

Kong stream subsystem does work this way. The route.destinations field can differentiate routes by port (and optionally IP) because there's no application-layer means to distinguish them otherwise.

There is possibly some overlap with requests to separate configuration by Kong instance (e.g. internally FTI-1630), but that's more aligned with separate Gateway instances (and whether we can collapse or not a la #2559), whereas this applies within single Gateways with multiple Listeners. For this, the main objectives are:

  • Check if destinations just works on HTTP routes, even though it wasn't originally intended for use with them. @rainest says "no"
  • If not, add Kong gateway support for destinations on HTTP routes.
  • Ensure that KIC HTTPRoute and TLSRoute set destinations on their routes.
  • Test that you can properly route the example scenario above.
@rainest rainest added this to the Gateway API - Milestone 3 milestone Jun 23, 2022
@rainest rainest added bug Something isn't working size/large labels Jun 23, 2022
@mflendrich mflendrich removed this from the Gateway API - Next milestone Oct 11, 2022
@mtparet
Copy link

mtparet commented Jun 21, 2024

Is there a plan to correctly support gateway resource ? This is kind of broken if the spec is not respected by Kong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants