Role in the deployment¶

Redis backs DE caching and session state. It is deployed as three replicas with Sentinel for failover, plus a Redis HAProxy that gives clients one address to connect to instead of tracking which replica is currently primary. All of it runs in the same namespace as the DE services.

The DE reads its Redis configuration from the Redis section of the deployment group variables: host, port, HA service name, password, and database number.

Values¶

Create a values file that overrides the persistent volume and sets the credentials. Keep it in your private inventory — it contains two secrets.

## replicas for each component
replicas: 3

persistentVolume:
  enabled: true
  ## storage class for redis-ha data
  ## use your cluster's replicated class; see the storage document
  storageClass: <STORAGE_CLASS>

## Sentinel
sentinel:
  auth: true
  authkey: <GENERATED_SECRET>
  password: <GENERATED_SECRET>

## Redis
auth: true
authkey: <GENERATED_SECRET>
redisPassword: <GENERATED_SECRET>

Deploy Redis and Sentinel¶

helm repo add dandydev https://dandydeveloper.github.io/charts
helm repo update

helm upgrade --install redis-ha dandydev/redis-ha \
  --namespace <NAMESPACE> --values values.yaml

Deploy Redis HAProxy¶

The HAProxy in front of Redis reads the configuration and secrets loaded by cluster resources, so load those first, then:

kubectl apply -f resources/deployments/redis-haproxy.yml -n <NAMESPACE>

Verify¶

kubectl -n <NAMESPACE> get pods -l app=redis-ha
kubectl -n <NAMESPACE> exec -it redis-ha-server-0 -c redis -- \
    redis-cli -a "$REDIS_PASSWORD" info replication

Expect one master and two slave roles. Three replicas all reporting master means Sentinel is not forming a quorum — check that the Sentinel auth key matches across replicas.

Related¶

• Storage
• Cluster resources