Redis auf Kubernetes mit dem Redis Operator betreiben

1. Warum Redis auf Kubernetes eine andere Kategorie von Betriebsaufgabe ist

Ein zustandsloser Webserver lässt sich auf Kubernetes fast beliebig skalieren, neu starten oder auf einen anderen Knoten verschieben, ohne dass dabei Daten verloren gehen oder eine bestimmte Instanz besonders wichtig wäre. Redis dagegen hält den kompletten Datensatz im Arbeitsspeicher einer bestimmten Instanz, kennt genau eine Primärinstanz für Schreibvorgänge und muss bei einem Ausfall dieser Primärinstanz koordiniert auf eine Replik umschalten, ohne dass zwei Instanzen gleichzeitig glauben, die Primärinstanz zu sein.

Ein einfaches Kubernetes Deployment mit mehreren Replikas reicht dafür nicht aus, weil es keine Vorstellung von Rollen wie Primär und Replik kennt und Pods bei einem Neustart standardmäßig eine neue, zufällige Identität erhalten. Genau diese Lücke zwischen dem generischen Kubernetes-Modell und den spezifischen Anforderungen von Redis füllt ein Operator, der als eigenständige Kontrollinstanz im Cluster mitläuft und die Redis-spezifische Logik kennt, die Kubernetes selbst nicht mitbringt.

2. Was ein Kubernetes Operator konkret übernimmt: Reconciliation statt Klick-Ops

Ein Operator ist im Kern ein Controller, der eine benutzerdefinierte Ressource, eine sogenannte Custom Resource Definition, beobachtet und den tatsächlichen Zustand des Clusters kontinuierlich an den gewünschten Zustand angleicht. Dieses Prinzip heißt Reconciliation Loop: Der Operator vergleicht in kurzen Abständen, was in der Spezifikation der Custom Resource steht, mit dem, was im Cluster tatsächlich läuft, und korrigiert Abweichungen automatisch, etwa indem er einen fehlenden Pod neu erstellt oder eine ausgefallene Replik ersetzt.

Für Redis bedeutet das konkret, dass der Operator Sentinel-Instanzen überwacht, deren Failover-Entscheidungen ausliest und die zugehörigen Kubernetes-Ressourcen wie Services und StatefulSets entsprechend anpasst, wenn eine neue Primärinstanz gewählt wurde. Der Betreiber muss dafür kein eigenes Skript schreiben, das regelmäßig den Redis-Status abfragt, sondern beschreibt lediglich den gewünschten Endzustand, etwa drei Redis-Instanzen mit Sentinel-Überwachung, und überlässt die operative Umsetzung dem Operator.

3. Sentinel-basiertes Failover deklarativ als Custom Resource abbilden

Redis Sentinel übernimmt seit Jahren die Überwachung einer Primär-Replik-Topologie und initiiert bei Ausfall der Primärinstanz automatisch eine Neuwahl. Auf klassischen virtuellen Maschinen wird Sentinel meist manuell konfiguriert und mit systemd-Units verdrahtet. Ein Operator wie der Spotahome Redis Operator kapselt genau dieses Sentinel-Wissen in einer eigenen Ressource vom Typ RedisFailover und übersetzt eine einzige YAML-Spezifikation in Sentinel-Konfiguration, Redis-Instanzen und die notwendige Verdrahtung zwischen beiden.

Dadurch verschwindet nicht die Komplexität von Sentinel selbst, aber sie wird aus der manuellen Betriebsebene in eine wiederholbare, versionierbare Spezifikation verschoben. Ändert sich beispielsweise die gewünschte Anzahl an Repliken, genügt eine Anpassung des replicas-Felds in der Custom Resource, und der Operator kümmert sich um das Hinzufügen oder Entfernen der passenden Pods samt Aktualisierung der Sentinel-Konfiguration, inklusive der Quorum-Berechnung für Failover-Entscheidungen.

apiVersion: databases.spotahome.com/v1
kind: RedisFailover
metadata:
  name: shop-redis-cache
  namespace: magento
spec:
  sentinel:
    replicas: 3
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
  redis:
    replicas: 3
    resources:
      requests:
        cpu: 200m
        memory: 512Mi
      limits:
        memory: 768Mi
    storage:
      persistentVolumeClaim:
        metadata:
          name: redis-data
        spec:
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 5Gi

4. StatefulSet-Besonderheiten: stabile Pod-Identität und Persistent Volumes

Intern erzeugt der Operator für die Redis-Instanzen kein Deployment, sondern ein StatefulSet, denn nur ein StatefulSet garantiert eine stabile, vorhersehbare Pod-Identität nach dem Schema name-0, name-1, name-2. Diese Ordinal-Nummerierung bleibt über Neustarts hinweg erhalten, was für Sentinel wichtig ist, da es Instanzen anhand ihrer DNS-Namen unterscheidet und nicht anhand zufällig vergebener Pod-Namen, wie sie ein Deployment erzeugen würde.

Ebenso wichtig ist, dass jeder Pod eines StatefulSets ein eigenes Persistent Volume Claim erhält, das bei einem Neustart des Pods auf demselben Knoten oder nach einem Rescheduling erneut an genau diesen Pod gebunden wird. Für Redis bedeutet das, dass eine Replik nach einem Neustart ihre zuletzt persistierten Daten aus dem RDB-Snapshot oder dem AOF-Log wiederfindet, statt mit einem leeren Datensatz zu starten und den kompletten Bestand über die Replikation vom Primär neu laden zu müssen.

5. Praxisbeispiel: eine RedisFailover Custom Resource im Detail

Im obigen Beispiel definiert die Ressource shop-redis-cache drei Redis-Instanzen und drei Sentinel-Instanzen, ein für Produktionsbetrieb übliches Minimum, das auch bei Ausfall eines einzelnen Kubernetes-Knotens noch ein Quorum für Failover-Entscheidungen behält. Der Operator übersetzt diese Spezifikation in ein StatefulSet für Redis, ein Deployment für Sentinel, die notwendigen Services für interne Kommunikation sowie ConfigMaps mit der generierten redis.conf und sentinel.conf.

Praktisch beobachtet man den Status über kubectl get redisfailover und die vom Operator geschriebenen Status-Felder, die unter anderem anzeigen, welche Instanz aktuell als Primärinstanz gilt. Für einen Magento-Shop, der Redis als Full-Page-Cache- oder Session-Backend nutzt, lässt sich dieselbe Custom Resource für unterschiedliche Umgebungen mit angepassten resources-Werten wiederverwenden, etwa kleiner dimensioniert für Staging und großzügiger für Produktion.

6. Storage-Klassen und PVC-Verhalten bei Pod-Neustarts und Rescheduling

Die Wahl der StorageClass entscheidet maßgeblich darüber, wie robust der Betrieb tatsächlich ist. Bei einer StorageClass mit ReadWriteOnce und Node-lokalem Storage bleibt ein Persistent Volume an genau einen Kubernetes-Knoten gebunden, was bedeutet, dass ein Pod bei einem Knotenausfall nicht ohne Weiteres auf einem anderen Knoten mit seinen bisherigen Daten neu starten kann, sondern zunächst auf die Verfügbarkeit des ursprünglichen Knotens warten muss oder ohne persistierte Daten neu aufgebaut wird.

Netzwerkbasierte Storage-Lösungen wie EBS-CSI-Treiber in AWS oder Ceph-basierte Lösungen lösen dieses Problem, indem sie das Volume unabhängig vom Knoten bereitstellen, allerdings mit einer zusätzlichen Latenz gegenüber lokalem NVMe-Speicher, die sich insbesondere bei AOF mit appendfsync everysec bemerkbar macht. Für Cache-Workloads, bei denen ein gelegentlicher Kaltstart tolerierbar ist, reicht häufig auch ein einfacher, lokaler Storage mit bewusst in Kauf genommenem Datenverlust im Ausfallfall.

7. Netzwerk und Service Discovery: Headless Services und Sentinel-Endpunkte

Damit Sentinel und Redis-Clients einzelne Pods gezielt adressieren können, statt nur über einen lastverteilenden Service zu gehen, erzeugt der Operator für das StatefulSet einen Headless Service ohne eigene ClusterIP. Über diesen Headless Service erhält jeder Pod einen stabilen DNS-Namen nach dem Schema shop-redis-cache-0.shop-redis-cache.magento.svc.cluster.local, über den Sentinel gezielt eine bestimmte Instanz überwachen und ansprechen kann.

Für Redis-Clients außerhalb des Clusters, etwa aus der Magento-Anwendung heraus, ist meist ein zusätzlicher, sentinel-fähiger Client sinnvoll, der die aktuelle Primärinstanz über die Sentinel-Endpunkte auflöst, statt eine feste IP-Adresse zu verwenden. Ohne diese Sentinel-Anbindung würde ein Client nach einem Failover weiterhin gegen die alte, inzwischen zur Replik gewordene Instanz schreiben wollen, was zu Schreibfehlern führt, bis die Anwendung neu verbindet.

8. Grenzen des Eigenbetriebs: Split-Brain-Risiken und Operator-Reifegrad

Ein Operator nimmt viel manuelle Arbeit ab, beseitigt aber nicht die grundsätzlichen Herausforderungen verteilter Systeme. Bei einem Netzwerk-Partitionsereignis innerhalb des Kubernetes-Clusters, etwa wenn ein Teil der Knoten die Verbindung zum Rest verliert, kann es weiterhin zu Split-Brain-Situationen kommen, bei denen zwei Teilbereiche des Clusters unterschiedliche Vorstellungen davon haben, welche Instanz die aktuelle Primärinstanz ist. Sentinels Quorum-Mechanismus mindert dieses Risiko, beseitigt es aber nicht vollständig.

Hinzu kommt, dass Community-Operatoren wie der Spotahome Redis Operator mit begrenzten Wartungsressourcen gepflegt werden und Updates von Kubernetes selbst, etwa geänderte API-Versionen für StatefulSets, teils verzögert nachgezogen werden. Wer Redis auf Kubernetes betreibt, übernimmt damit implizit auch die Verantwortung, den Operator selbst zu beobachten, dessen Änderungslogs zu verfolgen und bei größeren Kubernetes-Versionssprüngen vorab in einer Staging-Umgebung zu testen.

9. Wann ein Managed-Service die bessere Wahl als Eigenbetrieb ist

Für Teams mit eigener Kubernetes-Expertise und dem Wunsch, Infrastruktur konsequent als Code zu verwalten, ist ein Redis Operator eine sinnvolle, gut integrierbare Lösung, insbesondere wenn ohnehin schon zahlreiche andere Workloads auf demselben Cluster laufen. Für viele Magento-Betreiber überwiegt jedoch der Aufwand, Sentinel-Failover, Storage-Entscheidungen und Operator-Updates dauerhaft selbst zu verantworten, gegenüber dem eingesparten monatlichen Betrag eines Managed-Service.

Ein Managed-Dienst wie AWS ElastiCache, Azure Cache for Redis oder ein spezialisierter Anbieter wie Redis Cloud übernimmt Failover, Patching und Backups vollständig, wodurch das eigene Team sich auf die Magento-Anwendung konzentrieren kann statt auf die Feinheiten von StatefulSets und Sentinel-Quorum. Als Faustregel gilt: Wer bereits eine ausgereifte Kubernetes-Plattform mit dediziertem Platform-Team betreibt, profitiert vom Operator-Ansatz, während kleinere Teams mit einem Managed-Service in der Regel schneller ein stabileres Ergebnis erzielen.

10. Zusammenfassung

11. FAQ: Redis Operator auf Kubernetes: Das Wichtigste auf einen Blick