Running Redis Clusters on Kubernetes: Technical Notes and Architecture Survey

Running stateful applications like Redis on Kubernetes presents unique challenges. This article is a survey of mainstream approaches, serving as a reference before production deployment.

Core Challenges

Redis is inherently stateful, while Kubernetes is designed primarily for stateless workloads. Bridging this gap requires consideration of:

• Data persistence strategies
• Network topology design
• Scaling strategies
• Failover handling
• Performance optimization

Architecture Options

Option 1: Redis Sentinel

Traditional approach using Sentinel for high availability:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
spec:
  serviceName: redis
  replicas: 3
  template:
    spec:
      containers:
      - name: redis
        image: redis:7-alpine
        command: ["redis-server", "--sentinel"]

Pros: Battle-tested, well-documented Cons: Manual failover configuration, limited scaling

Option 2: Redis Cluster

Native clustering for horizontal scaling:

apiVersion: redis.redis.opstreelabs.in/v1beta1
kind: RedisCluster
metadata:
  name: redis-cluster
spec:
  clusterSize: 6
  persistenceEnabled: true

Pros: Automatic sharding, built-in failover Cons: Cross-slot operations not supported, complex setup

Option 3: Operator-Based

Use a Redis operator for automated management. Mature community implementations include redis-operator (opstree) among others.

Pros: Simplified operations, high automation Cons: Additional abstraction layer

Production Configuration Reference

Resource Requests

resources:
  requests:
    memory: "2Gi"
    cpu: "1000m"
  limits:
    memory: "4Gi"
    cpu: "2000m"

Redis requires consistent CPU for performance; avoid oversubscription.

AOF Persistence

args:
  - redis-server
  - --appendonly yes
  - --appendfsync everysec

Trade some performance for durability. For pure cache usage, persistence can be disabled.

Monitoring

Key metrics to monitor:

1. Memory Usage: used_memory_rss vs maxmemory
2. Evictions: evicted_keys — indicates memory pressure
3. Slow Commands: slowlog — performance bottlenecks
4. Connection Count: connected_clients — connection pool health
5. Replication Lag: For master-slave setups

Note

This article is a technical survey and study note. Some configurations are compiled from community best practices. A local Redis instance has been deployed for development testing; production-grade cluster deployment requires further practical validation.