Veröffentlicht am

Redis auf Kubernetes: Cluster und Sentinel

Teilen:
Authors

TL;DR

Redis läuft auf Kubernetes in drei Modi: Standalone für Entwicklung, Sentinel für automatisches Failover, Cluster für horizontale Skalierung. Der Bitnami Helm Chart deckt alle drei ab. Diese Anleitung zeigt dir Installation, Konfiguration und Client-Anbindung für jeden Modus.


Redis auf Kubernetes: Der richtige Modus für dein Setup

Redis ist der de-facto Standard für Caching und Session-Storage in Kubernetes-Umgebungen. Die Frage ist nicht ob, sondern wie du es deployst. Standalone reicht für Dev, aber in Production brauchst du Ausfallsicherheit.

Zuerst die Cluster-Verbindung prüfen:

kubectl cluster-info
kubectl get nodes

Standalone vs. Sentinel vs. Cluster

Bevor du installierst, hier der Vergleich der drei Modi:

ModusReplicasFailoverShardingUse Case
Standalone1KeinsNeinDevelopment, Testing
Sentinel1 Master + N ReplicasAutomatisch (Sentinel)NeinProduction, HA ohne Sharding
ClusterN Masters + N ReplicasAutomatisch (Cluster)JaGroße Datenmengen, horizontale Skalierung

Sentinel ist für die meisten Production-Setups die richtige Wahl. Du bekommst automatisches Failover ohne die Komplexität eines Redis Clusters.

Installation mit Bitnami Helm Chart

Der Bitnami Chart ist der am weitesten verbreitete und unterstützt alle drei Modi.

# Namespace erstellen
kubectl create namespace redis

# Bitnami Helm Repo hinzufügen
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

Variante 1: Redis mit Sentinel (empfohlen)

helm install redis bitnami/redis \
  --namespace redis \
  --set architecture=replication \
  --set sentinel.enabled=true \
  --set sentinel.quorum=2 \
  --set replica.replicaCount=3 \
  --set auth.password=redis-secret-2026 \
  --set master.persistence.size=10Gi \
  --set replica.persistence.size=10Gi \
  --set master.resources.requests.memory=256Mi \
  --set master.resources.limits.memory=512Mi

Warte bis alle Pods bereit sind:

kubectl wait --for=condition=Ready pod -l app.kubernetes.io/name=redis -n redis --timeout=180s
kubectl get pods -n redis

Das Ergebnis: ein Master, zwei Replicas und drei Sentinel-Instanzen. Sentinel überwacht den Master und promotet automatisch eine Replica, falls der Master ausfällt.

Variante 2: Redis Cluster (Sharding)

Für Datenmengen jenseits von 25 GB oder extrem hohen Durchsatz:

helm install redis-cluster bitnami/redis-cluster \
  --namespace redis \
  --set cluster.nodes=6 \
  --set cluster.replicas=1 \
  --set password=redis-secret-2026 \
  --set persistence.size=10Gi \
  --set resources.requests.memory=256Mi

Sechs Nodes: drei Masters mit je einer Replica. Die 16.384 Hash-Slots werden automatisch auf die Masters verteilt.

Passwort-Management

Hardcoded Passwörter in Helm-Values sind nur für Demos akzeptabel. In Production nutze ein Kubernetes Secret:

# Secret erstellen
kubectl create secret generic redis-password \
  --from-literal=redis-password='S3cur3-R3d1s-2026!' \
  --namespace redis

Dann im Helm Release referenzieren:

# redis-values.yaml
auth:
  existingSecret: redis-password
  existingSecretPasswordKey: redis-password
sentinel:
  enabled: true
  quorum: 2
replica:
  replicaCount: 3
master:
  persistence:
    size: 10Gi
    storageClass: standard
  resources:
    requests:
      memory: 256Mi
      cpu: 100m
    limits:
      memory: 512Mi
      cpu: 500m
helm install redis bitnami/redis \
  --namespace redis \
  -f redis-values.yaml

Persistence konfigurieren

Redis-Daten überleben Pod-Neustarts nur mit Persistent Volumes. Der Bitnami Chart erstellt automatisch PVCs. Wichtig sind zwei Redis-Persistence-Mechanismen:

RDB (Snapshots): Periodische Punkt-Snapshots. Standard ist aktiv.

AOF (Append Only File): Jede Schreiboperation wird geloggt. Minimaler Datenverlust bei Crash.

Für maximale Sicherheit aktiviere beides:

# redis-values.yaml (Ergänzung)
master:
  configuration: |
    appendonly yes
    appendfsync everysec
    save 900 1
    save 300 10
    save 60 10000
    maxmemory 400mb
    maxmemory-policy allkeys-lru
EinstellungWertBedeutung
appendonly yesAOF aktivJede Schreiboperation wird geloggt
appendfsync everysecSync jede SekundeKompromiss aus Performance und Sicherheit
save 900 1RDB SnapshotNach 900s wenn mind. 1 Key geändert
maxmemory-policyallkeys-lruÄlteste Keys entfernen bei vollem Speicher

Client-Anbindung

Aus einem Pod im Cluster

# Redis CLI testen (Sentinel-Modus)
kubectl run redis-test -ti --rm \
  --image=bitnami/redis:latest \
  --namespace=redis \
  -- redis-cli -h redis -p 26379 \
    -a 'redis-secret-2026' \
    SENTINEL get-master-addr-by-name mymaster

Der Sentinel gibt die aktuelle Master-Adresse zurück. Deine Applikation sollte immer über Sentinel verbinden, nie direkt zum Master.

Python-Beispiel mit Sentinel-Support

from redis.sentinel import Sentinel

sentinel = Sentinel(
    [('redis.redis.svc.cluster.local', 26379)],
    socket_timeout=0.5,
    password='redis-secret-2026',
    sentinel_kwargs={'password': 'redis-secret-2026'}
)

# Master für Schreiboperationen
master = sentinel.master_for('mymaster')
master.set('session:user123', 'active')

# Replica für Leseoperationen
replica = sentinel.slave_for('mymaster')
value = replica.get('session:user123')
print(f"Session: {value.decode()}")

Spring Boot Konfiguration

# application.yml
spring:
  data:
    redis:
      sentinel:
        master: mymaster
        nodes: redis.redis.svc.cluster.local:26379
      password: redis-secret-2026

Failover testen

Vertraue keinem HA-Setup, das du nicht getestet hast:

# Aktuellen Master identifizieren
kubectl exec -it redis-node-0 -n redis -- \
  redis-cli -a 'redis-secret-2026' INFO replication

# Master-Pod löschen und Failover beobachten
kubectl delete pod redis-node-0 -n redis

# Sentinel-Logs verfolgen
kubectl logs -f redis-node-1 -c sentinel -n redis

# Neuen Master prüfen (nach ca. 30 Sekunden)
kubectl exec -it redis-node-1 -n redis -- \
  redis-cli -a 'redis-secret-2026' -p 26379 \
  SENTINEL get-master-addr-by-name mymaster

Sentinel erkennt den Ausfall und promotet eine Replica zum neuen Master. Der alte Master wird nach dem Neustart automatisch zur Replica.

FAQ

Sentinel oder Cluster — was soll ich nehmen?

Sentinel, wenn du unter 25 GB Daten hast und kein Sharding brauchst. Redis Cluster, wenn du horizontal skalieren musst oder mehr als 100.000 Operationen pro Sekunde erreichst.

Wie viel Speicher braucht Redis auf Kubernetes?

Plane das Doppelte deiner Datenmenge als Memory-Limit. Redis braucht für Hintergrund-Saves (fork) kurzzeitig doppelten Speicher. Bei 1 GB Daten also mindestens 2 GB Limit setzen.

Kann ich Redis ohne Passwort betreiben?

Technisch ja (auth.enabled: false), aber dringend davon abzuraten. Jeder Pod im Cluster könnte sonst auf Redis zugreifen. Nutze mindestens ein Passwort, besser zusätzlich Network Policies.

Wie monitore ich Redis auf Kubernetes?

Der Bitnami Chart hat einen integrierten Prometheus-Exporter (metrics.enabled: true). Wichtige Metriken sind redis_connected_clients, redis_memory_used_bytes und redis_keyspace_hits_ratio.

Was passiert bei einem Kubernetes-Node-Ausfall?

Der Pod wird auf einem anderen Node neu gescheduled. Bei Sentinel-Modus übernimmt eine Replica sofort den Master. Dank PVC bleiben die Daten erhalten, solange die Storage Class Retain oder Delete mit Replication nutzt.


Nächster Schritt: Sichere deinen Redis mit Network Policies ab, sodass nur autorisierte Namespaces zugreifen können. Kombiniere das mit dem Kubernetes Network Policy Guide für ein vollständiges Sicherheitskonzept.

Kubernetes-Expertise gesucht?

Managed Services, Beratung, Training oder Security – wir unterstützen deutsche Unternehmen bei allen Kubernetes-Themen.

Kubernetes-Beratung gesucht?

Wir helfen deutschen Unternehmen bei der Kubernetes-Implementierung, Migration und Optimierung. DSGVO-konform und praxiserprobt.

📖 Verwandte Artikel

Weitere interessante Beiträge zu ähnlichen Themen