Is your feature request related to a problem? Please describe.
Since kubernetes has internal cluster DNS, cluster addresses can be used instead IP addresses for announcements for redis and sentinel
Describe the solution you'd like
For example in sentinel config, instead of sentinel monitor mymaster IP_ADDRESS 6379 2 it can be configured to use sentinel monitor mymaster MASTER_POD_NAME.NAMESPACE.svc.CLUSTER_DOMAIN 6379 2
I Assume this can be achieved using getent hosts HELM_RELEASE_NAME.redis-ha-server-0.HELM_RELEASE_NAME-redis-ha.NAMESPACE.svc.CLUSTER_DOMAIN | awk '{print $2}' for defining the announce_ip function in the scripts.
Describe alternatives you've considered
As alternative the DNS of the service, not tne pod can be used
Additional context
If cluster DNS is used, we can remove the announce services which are created alongside the headless service and despite of that, keep the high-availablity because pods DNS names are also kept the same when respawning pods. IPs are changing, pod pod names are not.
This way the same functionality can be kept to work as it is now but less resources can be used (lower the deployment footprint removing announce services)
Is your feature request related to a problem? Please describe. Since kubernetes has internal cluster DNS, cluster addresses can be used instead IP addresses for announcements for redis and sentinel Describe the solution you'd like For example in sentinel config, instead of
sentinel monitor mymaster IP_ADDRESS 6379 2
it can be configured to usesentinel monitor mymaster MASTER_POD_NAME.NAMESPACE.svc.CLUSTER_DOMAIN 6379 2
I Assume this can be achieved usinggetent hosts HELM_RELEASE_NAME.redis-ha-server-0.HELM_RELEASE_NAME-redis-ha.NAMESPACE.svc.CLUSTER_DOMAIN | awk '{print $2}'
for defining the announce_ip function in the scripts. Describe alternatives you've considered As alternative the DNS of the service, not tne pod can be usedAdditional context If cluster DNS is used, we can remove the announce services which are created alongside the headless service and despite of that, keep the high-availablity because pods DNS names are also kept the same when respawning pods. IPs are changing, pod pod names are not. This way the same functionality can be kept to work as it is now but less resources can be used (lower the deployment footprint removing announce services)
@DandyDeveloper what do you think?