Redis on Kubernetes: Helm Charts, Operators and the Bitnami Change

You can run Redis on Kubernetes four ways: a StatefulSet you write yourself, a Helm chart, an open-source operator, or a commercial operator such as Redis Enterprise for Kubernetes. All of them end up as StatefulSets with a PersistentVolumeClaim per pod; what differs is who handles failover, resharding and upgrades. The most common route, Bitnami's charts and images, stopped being free for pinned production versions in August 2025, so many teams are choosing again.

Below: the options as of 11 October 2026, Sentinel versus Cluster, storage, the Bitnami change and the failures we see most. For the internals, see Redis architecture and Redis Cluster.

A hand-written StatefulSet is reasonable for one primary with replicas and Sentinel, if you will test failover yourself. For Redis Cluster, use an operator: adding shards, rebalancing slots and replacing failed pods by hand is where self-built setups break. Every option generates roughly this:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
spec:
  serviceName: redis-headless   # gives each pod a stable DNS name
  replicas: 3
  selector:
    matchLabels: {app: redis}
  template:
    metadata:
      labels: {app: redis}
    spec:
      containers:
      - name: redis
        image: redis:8.2          # pin a version, never latest
        args: ["--appendonly", "yes", "--maxmemory", "3gb"]
        resources:
          requests: {cpu: "1", memory: 4Gi}
          limits: {memory: 4Gi}
        volumeMounts:
        - {name: data, mountPath: /data}
      # replication, Sentinel, probes and anti-affinity omitted
  volumeClaimTemplates:
  - metadata: {name: data}
    spec:
      accessModes: ["ReadWriteOnce"]
      resources: {requests: {storage: 20Gi}}

The topology choice is the same as on virtual machines. Sentinel gives one primary with replicas and automatic failover; Cluster shards the keyspace over several primaries. Redis high availability compares the two. Kubernetes adds an addressing problem, because a rescheduled pod gets a new IP.

• Sentinel. Redis's documentation calls for at least three Sentinels on machines that fail independently, so spread them across nodes and zones. Since Redis 6.2, sentinel resolve-hostnames yes and sentinel announce-hostnames yes let Sentinel use the stable names a headless Service gives each pod, such as redis-0.redis-headless.prod.svc.cluster.local, instead of IPs. Both are off by default, and some clients expect IP addresses.
• Cluster. Nodes answer MOVED and ASK redirects with the address of the node that owns the slot, by default the pod IP. Clients inside the pod network can follow it; clients outside cannot. Since Redis 7.0, cluster-announce-hostname with cluster-preferred-endpoint-type hostname puts a DNS name in redirects instead. Each node keeps its ID and its view of the cluster in nodes.conf: keep that file on the PVC, or a restarted pod rejoins as a stranger. A full restart in which every pod gets a new IP leaves every nodes.conf pointing at old addresses, a case your chart or operator has to handle.

Use volumeClaimTemplates so each pod gets its own PersistentVolumeClaim; when redis-1 is rescheduled it reattaches the same volume. Persistence then works as on any host, with RDB snapshots, the append-only file or both, as covered in Redis persistence.

• Zonal volumes pin pods. Block volumes such as EBS or Persistent Disk live in one zone, so a pod bound to one can only run in that zone. Place replicas across zones deliberately.
• Disk for rewrites. A snapshot or AOF rewrite writes a new file before the old one is removed, so size the volume for a second copy of the data.
• Persistence off is not safe for primaries. If a primary runs without persistence and the kubelet restarts its container before Sentinel fails over, it comes back empty and its replicas copy the empty dataset. Redis's replication documentation warns against auto-restarting primaries with persistence off; on Kubernetes, enable persistence on any pod that can become primary.

Bitnami, now part of Broadcom, changed its free catalog from 28 August 2025. It stopped updating most Docker Hub images and OCI Helm charts, moved the existing Debian-based images, including every versioned tag, to docker.io/bitnamilegacy, and kept a small set of hardened images free in docker.io/bitnami, available only on the latest tag and intended for development. Deletion of the old public catalog was postponed to 29 September 2025, with brownouts in between. Pinned versions, long-term branches and support moved to the paid Bitnami Secure Images subscription. The chart and container source stays on GitHub under Apache 2.0.

What that means for Redis, checked on 11 October 2026:

• bitnami/redis, bitnami/redis-sentinel and bitnami/redis-exporter are in the free subset, and the bitnamicharts/redis chart is still released (28.3.1 on 30 September 2026). It now references bitnami/redis:latest, so you cannot pin a Redis version for free, and a pod scheduled on a new node can pull a newer Redis than its neighbours.
• There is no free redis-cluster image, and the bitnamicharts/redis-cluster chart stopped at 13.0.4 in August 2025. A Bitnami Redis Cluster deployment today is running a frozen release.
• bitnamilegacy/redis and bitnamilegacy/redis-cluster still serve the old tags, ending at 8.2.1, with no further updates.

What to do:

1. Find what you run: kubectl get pods -A -o jsonpath='{..image}' | tr ' ' '\n' | grep bitnami | sort -u.
2. Short term, point the chart at bitnamilegacy to keep pulling, knowing those images receive no security fixes. Current Bitnami charts refuse substituted images unless you set global.security.allowInsecureImages=true.
3. Then pick a long-term route: build the images from the Apache-licensed source and own the patching; move to the official redis or valkey/valkey images with an operator or your own chart; or subscribe to Bitnami Secure Images. Bitnami images use their own environment variables and startup scripts, so leaving them is a migration, not an image swap.

Our post on Bitnami image security and enterprise alternatives covers the security-review side of the same decision.

• Anti-affinity. Use pod anti-affinity on kubernetes.io/hostname, and topology spread constraints on topology.kubernetes.io/zone, so a primary and its replicas, or a majority of Sentinels, never share a node.
• PodDisruptionBudgets. Without one, a node drain during a cluster upgrade can evict two Redis pods, or two of three Sentinels, at once:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: redis
spec:
  maxUnavailable: 1
  selector:
    matchLabels: {app: redis}

• Memory limits versus maxmemory. When a container passes its memory limit the kernel kills it, and Redis gets no chance to evict. Set requests equal to limits for memory, and maxmemory well below the limit: replication and client output buffers sit outside the dataset, and Redis's administration guide says a write-heavy instance can use up to twice its normal memory while saving an RDB or rewriting the AOF. Redis memory covers sizing.
• Eviction. The default maxmemory-policy noeviction makes writes fail once maxmemory is reached. That is right for queues and state; a cache wants allkeys-lru or allkeys-lfu. See Redis eviction policies.
• Probes during loading. While Redis loads a large RDB or AOF it answers PING with a LOADING error. A liveness probe with a short threshold kills it mid-load, and it starts again from the beginning. Use a startup probe sized for your load time.
• Backups. A volume snapshot of a running Redis PVC is crash-consistent at best. Trigger BGSAVE, copy dump.rdb to object storage outside the cluster, and test the restore; the Redis backup and disaster recovery guide walks through it.

Most Redis-on-Kubernetes incidents we see start with an image that stopped updating, a memory limit equal to maxmemory, or an untested failover. AceMQ's Redis support engineers review charts, operators and limits before they fail and take the call when they do. For replacing Bitnami images and charts, see OSSeva's Bitnami drop-in images. Redis managed services runs Redis on your Kubernetes clusters for you, and Valkey support covers the fork.

• Bitnami: Upcoming changes to the Bitnami catalog (dates, legacy repository, Secure Images)
• Bitnami: Helm charts source repository
• Docker Hub: Bitnami free community-tier images
• OT-Container-Kit: redis-operator
• Spotahome: redis-operator (archived)
• Redis: Redis Enterprise for Kubernetes
• Valkey: valkey-operator
• Valkey: Helm charts
• Redis: High availability with Redis Sentinel (hostname support)
• Redis: redis.conf for Redis 8.2 (cluster announce settings, maxmemory)
• Redis: Replication (persistence off and auto restart)
• Redis: Administration (memory during saves)
• Kubernetes: StatefulSets
• Kubernetes: Specifying a Disruption Budget