Valkey Helm Chart (MSR4)

This repository tracks the Valkey Helm chart for deploying Valkey on Kubernetes in high availability mode, intended for use with MSR4 (Mirantis Secure Registry 4). MSR4 requires Redis-compatible backend configuration consistent with the steps below.

An upstream Git submodule points at the official chart repository so you can merge updates from valkey-io/valkey-helm; this fork focuses on the standalone valkey chart only (no Valkey Operator chart).

---

Prerequisites

• Kubernetes 1.20+
• Helm 3.5+
• For MSR4: a deployment path that consumes Redis/Valkey per MSR documentation

---

Installation

Generate a secret password

Generate a strong, random password for authenticating with Valkey:

PASSWORD=$(LC_ALL=C tr -dc A-Za-z0-9 </dev/urandom | head -c 24)

Create a Kubernetes secret to securely store the password:

kubectl create secret generic msr-valkey-secret \
  --from-literal=REDIS_PASSWORD=${PASSWORD}

MSR4 requires the password field to be called REDIS_PASSWORD.

Deploy Valkey

helm install msr-valkey valkey \
    --repo https://valkey-io.github.io/valkey-helm/ \
    --set replica.enabled=true \
    --set replica.replicas=2 \
    --set auth.existingSecret=msr-valkey-secret \
    --set auth.existingSecretKey=REDIS_PASSWORD \
    --set replica.persistence.enabled=true \
    --set replica.persistence.size=10Gi \
    --set auth.enabled=true \
    --set "auth.aclUsers.default.password=${PASSWORD}" \
    --set "auth.aclUsers.default.permissions=~* &* +@all"

Sizing notes

• replica.replicas — With replication enabled, one pod acts as master and the remainder as replicas. Setting replica.replicas=2 yields three StatefulSet pods total (one master + two replicas).
• replica.persistence.size — Scale according to anticipated data volume.

---

Verify replication

Master

kubectl exec -it msr-valkey-0 -- valkey-cli -a $PASSWORD INFO replication

Example output (truncated for readability):

Defaulted container "msr-valkey" out of: msr-valkey, msr-valkey-init (init)
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
# Replication
role:master
connected_slaves:2
slave0:ip=msr-valkey-1.msr-valkey-headless.default.svc.cluster.local,port=6379,state=online,offset=67326,lag=0,type=replica
slave1:ip=msr-valkey-2.msr-valkey-headless.default.svc.cluster.local,port=6379,state=online,offset=67326,lag=0,type=replica
...

Replicas

kubectl exec -it msr-valkey-1 -- valkey-cli -a $PASSWORD INFO replication

Example:

Defaulted container "msr-valkey" out of: msr-valkey, msr-valkey-init (init)
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
# Replication
role:slave
master_host:msr-valkey-0.msr-valkey-headless.default.svc.cluster.local
master_port:6379
master_link_status:up
...

---

Verify authentication

Confirm connectivity from each pod:

kubectl exec -it msr-valkey-0 -- valkey-cli -a $PASSWORD PING
kubectl exec -it msr-valkey-1 -- valkey-cli -a $PASSWORD PING
kubectl exec -it msr-valkey-2 -- valkey-cli -a $PASSWORD PING

Expected:

PONG

---

Troubleshooting

Lost leadership after deleting the master pod

Deleting msr-valkey-0 can temporarily disrupt replication until pods reconcile:

kubectl delete po msr-valkey-0

Check replication — the new msr-valkey-0 may show master_link_status:down on replicas until the cluster settles.

Recovery: restart the StatefulSet

kubectl rollout restart sts msr-valkey

Confirm pods:

kubectl get po | grep valkey

Re-check replication on master and replicas:

kubectl exec -it msr-valkey-0 -- valkey-cli -a $PASSWORD INFO replication
kubectl exec -it msr-valkey-1 -- valkey-cli -a $PASSWORD INFO replication

You should again see role:master with connected_slaves:2 on the master and master_link_status:up on replicas.

---

License

BSD 3-Clause License