The Redis Operator on Kubernetes doesn’t just deploy Redis; it actively manages its lifecycle, making it behave more like a cloud-native service than a traditional database.
Let’s see it in action. We’ll start by creating a simple Redis cluster. First, ensure you have the Redis Enterprise Operator installed in your cluster. If not, follow the operator’s official documentation to deploy it.
apiVersion: redis.redis.com/v1beta1
kind: RedisCluster
metadata:
name: my-redis-cluster
spec:
mode: cluster
redisClusterSize: 3
kubernetesConfig:
image: "redis/redis-stack-server:latest"
resources:
requests:
memory: "128Mi"
cpu: "100m"
limits:
memory: "256Mi"
cpu: "200m"
storage:
volumeClaimTemplate:
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
Apply this manifest:
kubectl apply -f redis-cluster.yaml
Kubernetes will now provision three Redis pods. The operator watches for this RedisCluster object and orchestrates the creation of the necessary StatefulSets, Services, and PersistentVolumeClaims. It then configures them into a functional Redis cluster, handling initial bootstrapping and node discovery.
The core problem the Redis Operator solves is the complexity of managing distributed stateful applications like Redis on Kubernetes. Manually setting up replication, sharding, failover, and scaling for Redis is a significant operational burden. The operator abstracts this complexity. Internally, it uses Kubernetes Custom Resource Definitions (CRDs) to define RedisCluster objects. When you create or update a RedisCluster resource, the operator’s controller logic kicks in. It translates the desired state defined in the CRD into concrete Kubernetes resources (Pods, StatefulSets, Services, etc.) and continuously reconciles the actual state with the desired state.
For example, if a Redis pod fails, the operator detects the failure via Kubernetes’s native health checks and StatefulSet capabilities. It then initiates a failover process, promoting a replica to master if necessary, and ensures a new pod is created to maintain the desired cluster size and resilience. This automated recovery is a key benefit.
The redisClusterSize field in the spec directly dictates the number of master nodes in your cluster. Increasing this value triggers the operator to add new nodes, potentially rebalancing shards to distribute data more evenly. Decreasing it prompts the operator to safely remove nodes, again with rebalancing considerations.
The kubernetesConfig section allows fine-grained control over the underlying Kubernetes deployment. You can specify the Redis image, resource requests and limits for each Redis pod, and even configure custom Redis arguments via the redisConfig field within kubernetesConfig (though not shown in this basic example). This is where you’d tune performance or enable specific Redis features.
The storage section defines how persistent data will be stored. volumeClaimTemplate ensures each Redis node gets its own persistent volume, crucial for data durability. The storage request of 1Gi means Kubernetes will attempt to provision a 1Gi persistent volume for each Redis node.
A subtle but powerful aspect is how the operator manages the Redis configuration itself. Beyond just deploying the pods, it can dynamically update the redis.conf files within the running containers based on changes to the RedisCluster CRD. This allows for rolling updates of configurations without manual intervention, ensuring that changes are applied consistently across the cluster and minimizing downtime. For instance, if you wanted to change a setting like maxmemory for all nodes, you’d update it in the CRD, and the operator would handle applying that change to each Redis instance, potentially restarting pods if the configuration change requires it, but doing so in a staggered, safe manner.
Once your Redis cluster is up and running, the next hurdle is often securing it. You’ll want to explore how to configure authentication, TLS encryption, and network policies to protect your Redis data.