Redis-operator

What is redis-operator image?

The redis-operator image runs a Kubernetes Operator responsible for managing Redis or Redis-compatible clusters through declarative Kubernetes resources. It automates provisioning, failover, high availability, persistence, upgrades, monitoring, and configuration synchronization. Operators typically support multiple Redis modes—including standalone, master-replica, and Redis Sentinel—as well as cluster mode for sharded deployments. They monitor Redis health, replace failed nodes, configure replication, and expose metrics for observability systems. In modern Kubernetes environments, the redis-operator image is useful for teams wanting to run Redis natively within the cluster without manually managing stateful deployments, ensuring consistent, automated lifecycle management for one of the most widely used caching and key-value systems.

How to use this image

The redis-operator image is deployed as a Kubernetes controller rather than executed directly. It watches CRDs to manage Redis clusters as first-class Kubernetes resources.

Install via Helm (Spotahome example):

helm repo add spotahome https://spotahome.github.io/redis-operator
helm install redis-operator spotahome/redis-operator \
  --namespace redis-operator --create-namespace

Create a Redis failover cluster:

apiVersion:databases.spotahome.com/v1
kind:RedisFailover
metadata:
name:redis-ha
spec:
redis:
replicas:3
sentinel:
replicas:3

After applying this manifest, the operator provisions StatefulSets, Sentinel instances, persistent volumes, services, and automated failover logic. Redis clients connect via Services exposed by the operator. Logs from the operator are written to stdout and can be collected via Kubernetes logging systems.

Image variants

Published under repositories such as spotahome/redis-operator and ot-container-kit/redis-operator, the image is typically available as:

• ‍redis-operator:latest – Tracks the latest stable operator; useful for testing.‍
• redis-operator:<version> – Version-specific tags aligned with operator releases; recommended for production.
• Architecture variants (e.g., -arm64) – Offered by some distributions for multi-arch Kubernetes clusters.

Some operators ship additional sidecar images (like exporters or init containers) to support metrics, backups, or initialization workflows. Production deployments should pin explicit versions and test upgrades due to CRD changes.