- Authors

- Name
- Phillip Pham
- @ddppham
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:
| Modus | Replicas | Failover | Sharding | Use Case |
|---|---|---|---|---|
| Standalone | 1 | Keins | Nein | Development, Testing |
| Sentinel | 1 Master + N Replicas | Automatisch (Sentinel) | Nein | Production, HA ohne Sharding |
| Cluster | N Masters + N Replicas | Automatisch (Cluster) | Ja | Groß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
| Einstellung | Wert | Bedeutung |
|---|---|---|
appendonly yes | AOF aktiv | Jede Schreiboperation wird geloggt |
appendfsync everysec | Sync jede Sekunde | Kompromiss aus Performance und Sicherheit |
save 900 1 | RDB Snapshot | Nach 900s wenn mind. 1 Key geändert |
maxmemory-policy | allkeys-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
Kubernetes-Upgrades ohne Downtime durchführen
Kubernetes-Cluster ohne Ausfallzeit upgraden: Schritt-für-Schritt-Anleitung mit PodDisruptionBudgets, Rolling Node Upgrades und Pre-Upgrade-Checkliste.
Datenbanken auf Kubernetes: StatefulSets richtig nutzen
PostgreSQL mit StatefulSets auf Kubernetes betreiben: Stabile Netzwerk-Identitäten, PersistentVolumeClaims und automatisierte Backups per CronJob.
Disaster Recovery für Kubernetes-Cluster planen
Kubernetes Disaster Recovery planen: Von etcd-Backups über Multi-Cluster-Failover bis zur DR-Teststrategie mit konkreten Befehlen.
Golden Paths: Kubernetes-Templates für Developer
Golden Paths geben Entwicklern standardisierte Kubernetes-Templates für Self-Service-Deployments. So reduzierst du Fehlkonfigurationen und beschleunigst Onboarding.
High Availability: Kubernetes Control Plane absichern
Kubernetes Control Plane hochverfuegbar betreiben: Multi-Master-Setup, etcd-Quorum, API-Server-Loadbalancing und Failure-Szenarien.