You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 differentlisten
ports, the sameserver_name
, and differentproxy_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:
destinations
just works on HTTP routes, even though it wasn't originally intended for use with them. @rainest says "no"destinations
on HTTP routes.destinations
on their routes.The text was updated successfully, but these errors were encountered: