How to setup OT operator installed Redis to work in istio mesh?

[enenum]

Are there any instructions/help on setting up redis cluster installed with OT operator to play nicely in an istio mesh?

I have pomerium configured to use redis - each installed in their own namespace - everything works fine when neither namespace has istio-injection enabled. Everything continues to work nicely when pomerium namespace has istio-injection enabled.

Trouble is when I attempt to have istio-injection enabled in the redis namespace and STRICT mTLS enabled. The istio sidecar for the redis-cluster-x pods continuously put out the log messge:

[2022-05-25T19:28:09.718Z] "- - -" 0 NR filter_chain_not_found - "-" 0 0 0 - "-" "-" "-" "-" "-" - - 10.42.2.74:9121 10.42.0.8:40790 - -

I have seen some posts for redis saying that POD_IP env var needs to be set, and even added to an /opt/bitnami/redis/etc/replica.conf file.

When I look in the opstree charts - there is no way to add env to the redis cluster - at least none seem provided for in the kubernetesConfig portion that controls the cluster pods, so it is not clear where such measures would go. Are there other ways to solve this?

[enenum]

For the benefit of any who may encounter this, the filter chain not found above is from a prometheus client trying to connect and not providing a cert (it was the promethues from istio utilities - not in mesh, and not doing any TLS) It is inconsequential to the redis cluster not working.

However the issue of the redis cluster not working is still there.

Another point is that the redis image already has taken care of setting up pod's ip announcement and uses the command line set it up. So again, +1 for ops tree, but the cluster still collapses when STRICT mTLS is applied via peerauth.

So, upon further reading, the purpose of the ip announcement mentioned above is so all the redis cluster members can talk amongst themselves, which they do on port 16379 by default (10000 + the public port - and there is some configurability there). In the mTLS situation, the port must mentioned in a service. It should be the headless service. But the headless service does not offer it. It is created and maintained by the operator, and if it is edited by hand, the operator will restore its version.

As a workaround, setting up another headless service exposing just that port allows the redis cluster to work.

Perhaps the operator should be adding the gossip port to the headless service, or providing users a way to enable it in redis cluster helm chart.