Running Redis on Kubernetes with the Redis Operator

1. Why Redis on Kubernetes is a different category of operational task

A stateless web server can be scaled, restarted, or moved to another node on Kubernetes almost arbitrarily, without losing data or any particular instance being uniquely important. Redis, by contrast, holds its entire dataset in the memory of one specific instance, recognizes exactly one primary for writes, and must coordinate a switch to a replica when that primary fails, without two instances ever believing simultaneously that they are the primary.

A plain Kubernetes Deployment with several replicas is not enough for this, because it has no concept of roles such as primary and replica, and pods get a new, random identity by default on every restart. This gap between the generic Kubernetes model and the specific requirements of Redis is exactly what an operator fills, running as a dedicated control instance in the cluster that carries the Redis-specific logic Kubernetes itself does not provide.

2. What a Kubernetes operator actually does: reconciliation instead of click-ops

An operator is essentially a controller that watches a custom resource definition and continuously reconciles the cluster's actual state with the desired state described in that resource. This principle is called a reconciliation loop: the operator compares, at short intervals, what the custom resource's specification says with what is actually running in the cluster, and corrects any drift automatically, for example by recreating a missing pod or replacing a failed replica.

For Redis specifically, this means the operator watches Sentinel instances, reads their failover decisions, and adjusts the associated Kubernetes resources such as services and StatefulSets accordingly whenever a new primary has been elected. The operator does not require the operator team to write a custom script that regularly polls Redis status; instead, they describe the desired end state, for example three Redis instances under Sentinel supervision, and leave the operational execution to the operator.

3. Mapping Sentinel-based failover declaratively as a custom resource

Redis Sentinel has for years handled monitoring a primary-replica topology and automatically triggering a re-election when the primary fails. On classic virtual machines, Sentinel is typically configured by hand and wired up with systemd units. An operator such as the Spotahome Redis Operator encapsulates exactly this Sentinel knowledge in a dedicated resource of type RedisFailover and translates a single YAML specification into Sentinel configuration, Redis instances, and the necessary wiring between the two.

This does not eliminate Sentinel's inherent complexity, but it shifts that complexity from the manual operations layer into a repeatable, version-controlled specification. If the desired number of replicas changes, for instance, adjusting the replicas field on the custom resource is enough, and the operator takes care of adding or removing the matching pods along with updating the Sentinel configuration, including the quorum calculation used for failover decisions.

apiVersion: databases.spotahome.com/v1
kind: RedisFailover
metadata:
  name: shop-redis-cache
  namespace: magento
spec:
  sentinel:
    replicas: 3
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
  redis:
    replicas: 3
    resources:
      requests:
        cpu: 200m
        memory: 512Mi
      limits:
        memory: 768Mi
    storage:
      persistentVolumeClaim:
        metadata:
          name: redis-data
        spec:
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 5Gi

4. StatefulSet specifics: stable pod identity and persistent volumes

Internally, the operator creates a StatefulSet for the Redis instances rather than a Deployment, because only a StatefulSet guarantees a stable, predictable pod identity following the pattern name-0, name-1, name-2. This ordinal numbering persists across restarts, which matters for Sentinel since it distinguishes instances by their DNS names rather than by the randomly assigned pod names a Deployment would produce.

Equally important is that every pod in a StatefulSet gets its own persistent volume claim, which gets rebound to that exact pod after a restart on the same node or after rescheduling. For Redis, this means a replica finds its most recently persisted data from the RDB snapshot or the AOF log again after a restart, instead of starting with an empty dataset and having to reload the entire dataset via replication from the primary.

5. Practical example: a RedisFailover custom resource in detail

In the example above, the shop-redis-cache resource defines three Redis instances and three Sentinel instances, a common production minimum that still keeps a quorum for failover decisions even if a single Kubernetes node fails. The operator translates this specification into a StatefulSet for Redis, a Deployment for Sentinel, the necessary services for internal communication, and ConfigMaps holding the generated redis.conf and sentinel.conf.

In practice, status is observed via kubectl get redisfailover and the status fields written by the operator, which among other things show which instance currently counts as the primary. For a Magento shop using Redis as a full page cache or session backend, the same custom resource can be reused across environments with adjusted resources values, for example scaled down for staging and more generously sized for production.

6. Storage classes and PVC behavior on pod restarts and rescheduling

The choice of StorageClass largely determines how robust the setup actually is. With a StorageClass backed by ReadWriteOnce and node-local storage, a persistent volume stays bound to exactly one Kubernetes node, meaning a pod cannot simply restart on another node with its existing data after a node failure; it either has to wait for the original node to come back or gets rebuilt without its persisted data.

Network-backed storage solutions such as EBS CSI drivers on AWS or Ceph-based solutions solve this problem by making the volume available independently of the node, though at the cost of additional latency compared to local NVMe storage, which becomes noticeable especially with AOF using appendfsync everysec. For cache workloads where an occasional cold start is tolerable, simple local storage with deliberately accepted data loss on failure is often sufficient.

7. Networking and service discovery: headless services and Sentinel endpoints

So that Sentinel and Redis clients can address individual pods directly rather than only going through a load-balancing service, the operator creates a headless service without its own ClusterIP for the StatefulSet. Through this headless service, every pod gets a stable DNS name following the pattern shop-redis-cache-0.shop-redis-cache.magento.svc.cluster.local, which Sentinel uses to monitor and address a specific instance.

For Redis clients outside the cluster, for instance from the Magento application itself, a Sentinel-aware client that resolves the current primary via the Sentinel endpoints is usually appropriate, rather than using a fixed IP address. Without this Sentinel integration, a client would keep trying to write against the old instance, now demoted to a replica, after a failover, which produces write errors until the application reconnects.

8. Limits of self-hosting: split-brain risk and operator maturity

An operator removes a great deal of manual work but does not eliminate the fundamental challenges of distributed systems. During a network partition event inside the Kubernetes cluster, for instance when part of the nodes lose connectivity to the rest, split-brain situations can still occur where two parts of the cluster hold different beliefs about which instance is the current primary. Sentinel's quorum mechanism reduces this risk but does not remove it entirely.

In addition, community operators such as the Spotahome Redis Operator are maintained with limited resources, and updates tracking Kubernetes itself, for example changed API versions for StatefulSets, sometimes lag behind. Anyone running Redis on Kubernetes implicitly takes on the responsibility of watching the operator itself, following its changelogs, and testing ahead of time in a staging environment before larger Kubernetes version jumps.

9. When a managed service is the better choice over self-hosting

For teams with in-house Kubernetes expertise and a desire to manage infrastructure consistently as code, a Redis operator is a sensible, well-integrated solution, especially when numerous other workloads already run on the same cluster. For many Magento operators, however, the ongoing effort of owning Sentinel failover, storage decisions, and operator updates outweighs the monthly amount saved compared to a managed service.

A managed offering such as AWS ElastiCache, Azure Cache for Redis, or a specialized provider like Redis Cloud takes over failover, patching, and backups entirely, letting the team focus on the Magento application rather than the finer points of StatefulSets and Sentinel quorum. As a rule of thumb, teams already running a mature Kubernetes platform with a dedicated platform team benefit from the operator approach, while smaller teams typically reach a more stable result faster with a managed service.

10. Summary

11. FAQ: Redis Operator on Kubernetes: The Essentials at a Glance