Merge Gateways on to a single EnvoyProxy fleet

[arkodg]

Description:

• Today we map the GatewayAPI Gateway resource on to a unique Envoy Proxy fleet (envoy per gateway #404 has more info) , creating a new Envoy Proxy infrastructure for every Gateway resource created. This design does not efficiently utilize the infra resources in the clusters
• This approach was needed because the Gateway API spec does allow a Listener (Port, Protocol, Hostname) tuple to be same across Gateway resources.

Raising this issue to create a way for Gateway resources to be merged on to the same Envoy Proxy Infrastructure by the user signaling this intent - one suggestion is to define a field in the GatewayClass paramsRef resource (EnvoyProxy) called
mergeGateways. Setting this field would merge all Gateway Listeners but would also ensure that this tuple (Port, Protocol, Hostname) is unique across all Listeners on all Gateways (if not, the newest conflicting listener would be rejected)

[cnvergence]

I can take a look at this one :) @arkodg

[arkodg]

great @cnvergence thanks !
recommend starting off with an API PR, since this is a API change, building consensus might get take time, will help out to ensure this work moves in a positive direction.

Another thing to note, that there is an alternate proposal upstream kubernetes-sigs/gateway-api#1863 which is taking the approach of linking child (Gateway) to parent (Gateway) thereby merging with it, rather than what is being suggested here - parent (GatewayClass) enforces merge semantics and children (Gateway) are merged into 1. I personally prefer what is suggested in this issue, but would like the community to chime in on which approach to take

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.