What would you like to be added:
In Kubernetes v1.30, a new TrafficDistribution field was added to Services. This field effectively supports one value (or empty/unspecified), and the definition of that value (PreferClose) is sufficiently broad that I'd expect many implementations to be able to support it:
Indicates a preference for routing traffic to endpoints that are topologically proximate to the client. The interpretation of "topologically proximate" may vary across implementations and could encompass endpoints within the same node, rack, zone, or even region. Setting this value gives implementations permission to make different tradeoffs, e.g. optimizing for proximity rather than equal distribution of load. Users should not set this value if such tradeoffs are not acceptable.
The default EndpointSlice + kube-proxy implementation of that is quite simple - route traffic within the same zone if there are any healthy local endpoints. There's certainly room in the spec to implement something more advanced, but hopefully the vast majority of Gateway API implementations are able to honor the intent of this field.
Why this is needed:
The most common backend for Gateway API is a Service, and this specific field represents both a common feature request, and a concept that overlaps significantly with Gateway API. We should provide some guidance on how we expect that to be done.
What would you like to be added: In Kubernetes v1.30, a new TrafficDistribution field was added to Services. This field effectively supports one value (or empty/unspecified), and the definition of that value (PreferClose) is sufficiently broad that I'd expect many implementations to be able to support it:
The default EndpointSlice + kube-proxy implementation of that is quite simple - route traffic within the same zone if there are any healthy local endpoints. There's certainly room in the spec to implement something more advanced, but hopefully the vast majority of Gateway API implementations are able to honor the intent of this field.
Why this is needed: The most common backend for Gateway API is a Service, and this specific field represents both a common feature request, and a concept that overlaps significantly with Gateway API. We should provide some guidance on how we expect that to be done.
/cc @gauravkghildiyal