support for service.spec.trafficDistribution

[nejec]

Is your feature request related to a problem? Please describe.

I would like to use experimental feature of kubernetes 1.31 trafficDistribution, which uses routing the traffic to the nearest cluster node (e.g. in the same availability zone).

Describe the solution you'd like

To avoid cross availability zone traffic cost kubernetes offer several methods how to send traffic to service endpoint in the same availability zone (or node):

• service.kubernetes.io/topology-mode: Auto with Topology Aware Routing, which has a drawback that it does not handle failover if the cluster node in the same zone goes down.
• service.spec.trafficDistribution: PreferClose
• Istio VirtualServer

Good explanation of the problem is available here.

Describe alternatives you've considered

For the time being using service.kubernetes.io/topology-mode: Auto can be used, however it has some drawbacks and it will be phased out in favour of trafficDistribution.

Using Istio for this specific cause adds another moving part, which is actually not needed since kubernetes already support the feature, however it is not implemented in the operator.

Additional context

I have looked into the code and since i am not a Golang programmer, i cannot make really good code for this. I can prepare something (but it will be mostly AI generated), however i don't expect for my code would be appropriate for such big project. But i can try ;)

[Zerpet]

I'm not very keen in adding support for an experimental feature, because the operator doesn't know the Kubernetes version of the API server, and using the feature in earlier Kubernetes versions would accept the RabbitmqCluster spec and fail during reconcile. That is not a great UX.

I believe that this traffic distribution feature can be used with the override feature for the service: https://www.rabbitmq.com/kubernetes/operator/using-operator#override

[nejec]

@Zerpet Yes, you are correct. The UX is a bit tricky to handle for these kind of changes, since it would be really great if operator could support wide spectrum of kubernetes version. But i totally understand your point.

At the moment, override does not work since it seems TrafficDistribution definition is behind a feature gate. There probably is a possible way around that, but i am unaware of it.