Currently the Operator does not utilise Server Hinting, consequently it's not possible for users to maximize Kubernetes advanced scheduling features such as affinity, tolerations and topologyPodConstraints as the Infinispan hashing algorithm does not take a pod's availability-zone or node into consideration.

We should enhance the Operator to utilise server-hinting all the time or by a configurable CR option. Benchmarking will need to be performed to determine the impact of the current overhead associated with server hinting ISPN-12505.

A use-case where server-hinting becomes increasingly important are Keycloak "stretch" deployments in Multi-AZ Kubernetes clusters, as it's crucial that Primary/Backup owners are spread across availability-zones in order to satisfy HA requirements.