Recently I’ve tried to install stable/redis Helm chart version 8.0.1. I used production-ready values taken from the repo and slightly modified for needs. I used enabled by default clusterisation, but with only one slave node instead of two.

The release deployed sucessfully, but the slave node kept having problem with liveness probe that eventually led to a CrashLoopBackoff. The logs showed that my slave node is “Unable to connect to MASTER”, although I could easily connect to the master from the redis-client node with redis-cli:

$ kubectl run --namespace default redis-client --rm --tty -i --restart='Never' \
  --env REDIS_PASSWORD=my-redis-password \
 --image docker.io/bitnami/redis:5.0.5 -- bash

# redis-cli -h redis-master -a my-redis-password
redis-master:6379>

It turned out that a networkPolicy section in values-production.yaml was a culprit. networkPolicy.enable is set to true, but networkPolicy.allowExternal: true is commented evaluating to false by default. That makes redis nodes only accessible from the pods with a label {{ template "redis.fullname" . }}-client: "true".

So make master accessible to slave you either:

• set networkPolicy.enable: false to turn off NetworkPolicy, or
• set networkPolicy.allowExternal: true (i.e. by commenting it out in the values-production.yaml)

That’s it. No more failed liveness probes or CrashLoopBackoff. It works.

P.S. I think that production values example in stable should probably be consistent. For example, stable/postgresql production values file contains:

networkPolicy:
  enabled: false
  allowExternal: true

while stable/redis production values file:

networkPolicy:
  enabled: true
  #allowExternal: true