Summary
HUG currently ignores the Gateway spec.addresses field: listeners bind on 0.0.0.0 (optionally overridden by the single global --ipv4-bind-address), and status.addresses reports a node IP.
Could you support per-Gateway spec.addresses?
Motivation / use case
We want a single HUG instance to serve multiple Gateways that reuse the same listener port (e.g. several :80 / :443), demultiplexed by destination VIP rather than only by Host/SNI.
This is essential for;
- "multi-tenancy" where LBs are splitted for distinct population of users / use-cases.
- a future support of L4 routes (
TCPRoute), where there is no Host/SNI to demux on: two hostname-less catch-all :80 TCP Gateways on one HUG are currently indistinguishable, and HUG marks both listeners Programmed=False (Invalid).
If HUG bound each Gateway's spec.addresses (VIP-A:80, VIP-B:80), one HUG could serve both distinctly (via their respective IPs).
Current behavior
spec.addresses on a Gateway is ignored; HUG binds 0.0.0.0 and self-assigns a node IP in status.addresses.
- The only bind override is the single, global
--ipv4-bind-address flag.
- When
spec.addresses is set but unsupported, nothing is reported in status.addresses (which stays silent).
Proposed behavior
- When a Gateway sets
spec.addresses (type IPAddress), translate each into a bind <addr>:<port> for that Gateway's listeners.
- If a requested address is invalid / unavailable / unsupported, highlight it in the corresponding
status.addresses entry.
Prerequisites associated to the datapath
For a per-Gateway bind to actually receive traffic, the VIP must reach the pod netns as the destination, via a destination-preserving LB (DSR) or an address attached to the pod. Users must handle that side; this request here is specifically about HUG translating spec.addresses into bind.
Spec reference
GatewaySpec.addresses is an "Extended" (implementation-specific) feature: https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1/gateway_types.go.
Summary
HUG currently ignores the Gateway
spec.addressesfield: listeners bind on0.0.0.0(optionally overridden by the single global--ipv4-bind-address), andstatus.addressesreports a node IP.Could you support per-Gateway
spec.addresses?Motivation / use case
We want a single HUG instance to serve multiple Gateways that reuse the same listener port (e.g. several
:80/:443), demultiplexed by destination VIP rather than only by Host/SNI.This is essential for;
TCPRoute), where there is no Host/SNI to demux on: two hostname-less catch-all:80TCP Gateways on one HUG are currently indistinguishable, and HUG marks both listenersProgrammed=False (Invalid).If HUG bound each Gateway's
spec.addresses(VIP-A:80,VIP-B:80), one HUG could serve both distinctly (via their respective IPs).Current behavior
spec.addresseson a Gateway is ignored; HUG binds0.0.0.0and self-assigns a node IP instatus.addresses.--ipv4-bind-addressflag.spec.addressesis set but unsupported, nothing is reported instatus.addresses(which stays silent).Proposed behavior
spec.addresses(typeIPAddress), translate each into abind <addr>:<port>for that Gateway's listeners.status.addressesentry.Prerequisites associated to the datapath
For a per-Gateway bind to actually receive traffic, the VIP must reach the pod netns as the destination, via a destination-preserving LB (DSR) or an address attached to the pod. Users must handle that side; this request here is specifically about HUG translating
spec.addressesintobind.Spec reference
GatewaySpec.addressesis an "Extended" (implementation-specific) feature: https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1/gateway_types.go.