StatefulSet Kubernetes: Daten ehrlich betreiben 2026

Felix, Kubernetes-Betrieb bei Pexon Consulting | 11 Min. Lesezeit | 11.09.2026

TL;DR: StatefulSet Kubernetes ohne Märchen

StatefulSet Kubernetes liefert stabile Pod-Namen, ein Headless Service und ein PVC pro Replica. Es wählt keinen Postgres-Primary und heilt keine Queue. Pexon Consulting (80 Mitarbeitende, Deutschland, Microsoft Partner) setzt Operatoren über nackte YAML-Sets. local-path ist Test-Storage. In Prod ist es eine ehrliche Grenze, kein Provisioner.

Das Problem: Pending, weil niemand Storage bestellt hat

Der Reddit-Klassiker ist älter als mancher Cluster und immer noch wahr. Elasticsearch als StatefulSet, VolumeClaimTemplate gesetzt, kein StorageClass-Controller im Cluster. Die Pods bleiben Pending. Jemand löscht das Template, das Set rollt, die Logs sind nach dem nächsten Restart weg.

Das ist kein Elasticsearch-Bug. Das ist ein Cluster ohne dynamisches Volume und ein Team, das StatefulSet mit „die Daten bleiben“ verwechselt.

Wir sehen denselben Schnitt in kleinen On-Prem-Kellern. Microservices sind Deployments. Daneben sollen Postgres, RabbitMQ, Valkey und Elasticsearch „auch schnell rein“. Rancher zeigt grün. local-path ist die Default-StorageClass, weil jemand das so gefunden hat. Dann stirbt ein Node, und mit ihm das Verzeichnis /opt/local-path-provisioner/....

Pexon Consulting sagt das ungern elegant: ihr habt keinen Datenbetrieb. Ihr habt einen Ordner auf einer Platte, den Kubernetes höflich PVC nennt.

StatefulSet Kubernetes ist Identität, nicht Hochverfügbarkeit

Die kurze Antwort: ein StatefulSet macht aus Pods benannte Dinge mit festem Speicher. Es macht daraus keine Datenbank.

postgres-0 bleibt postgres-0. Das Volume hängt am Claim, nicht am Zufalls-Pod. Scale-up kommt geordnet, Scale-down auch, wenn ihr nicht Parallel gesetzt habt und euch wundert. Ein Headless Service gibt DNS, damit Replikas sich finden.

Was fehlt: wer Primary ist. Wer nach einem Node-Verlust befördert wird. Ob das Backup gestern wirklich lesbar war. Ob zwei Instanzen dieselbe Disk nicht gleichzeitig beschreiben.

Deshalb raten wir von dem nackten Drei-Replica-Set plus „wird schon“ ab. Für einen Cache im Test reicht es. Für Rechnungslauf nicht.

Deployments bleiben der Default für zustandslose Services. StatefulSet Kubernetes ist der Sonderweg, sobald die Anwendung ihren Hostnamen oder ihr Volume wiedererkennen muss. Wer jedes Microservice-YAML auf StatefulSet umstellt, weil es seriöser klingt, zahlt Komplexität ohne Nutzen.

Mehr zum Weg von der VM in den Container steht im Migrationsleitfaden. Stateful kommt dort zuletzt, und das ist Absicht.

Postgres, RabbitMQ, Valkey, Elasticsearch: ein Schnitt, vier Wahrheiten

Ein Post, nicht vier Tools. Die Frage ist überall dieselbe: wer besitzt den Zustand?

Postgres. CloudNativePG 1.30.0 ist am 29.06.2026 erschienen, mit DatabaseRole und einer Lease-basierten Primary-Wahl. Das Repo cloudnative-pg/cloudnative-pg stand am 11.09.2026 bei 9.169 GitHub-Stars. Wichtig für diesen Text: CNPG verwaltet PVCs selbst. Es stützt sich nicht auf ein klassisches StatefulSet für PGDATA. Wer 2026 „Postgres als StatefulSet“ googelt, sucht das Primitive. Wer Prod will, sucht den Operator. Clients sprechen den -rw-Service an, nicht postgres-0.

RabbitMQ. Hier ist das StatefulSet ehrlich. Der Cluster Operator erzeugt es, ein PVC pro Node, Quorum-Queues mit drei oder fünf Replikas. Ohne festes Volume ist die Queue nach dem Restart eine andere Persönlichkeit. reclaimPolicy: Retain ist hier keine Pedanterie. Ein versehentlich gelöschtes Claim ist eine gelöschte Historie.

Valkey. Der offizielle Operator valkey-io/valkey-operator trägt selbst den Hinweis: Early Development, nicht production-ready, API v1alpha1 darf sich ändern. 327 Stars am 11.09.2026. Unsere klare Empfehlung: Valkey 2026 als StatefulSet plus bewährtes Chart, oder als gemanagte Instanz neben dem Cluster. Nicht als WIP-Operator in Prod, nur weil der Name Redis abgelöst hat.

Elasticsearch. Ohne StorageClass bleiben die Pods Pending. Mit local-path starten sie und sterben mit dem Node. Drei Replicas auf drei Nodes brauchen drei Volumes, die wirklich auf drei Nodes liegen, plus eine Anti-Affinity, die das erzwingt. Sonst liegen zwei Shards auf derselben Platte und ihr habt Theater-HA.

# Nur das Primitive. Kein Postgres-Ersatz.
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: valkey
spec:
  serviceName: valkey
  replicas: 1
  podManagementPolicy: OrderedReady
  selector:
    matchLabels:
      app: valkey
  template:
    metadata:
      labels:
        app: valkey
    spec:
      containers:
        - name: valkey
          image: valkey/valkey:8
          ports:
            - containerPort: 6379
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: local-path
        resources:
          requests:
            storage: 10Gi

Ein Replica, local-path, Test. In Prod ersetzen wir das Bild, nicht nur die Zahl.

local-path ist ehrlich: Test ja, Prod nur mit offenen Augen

Rancher local-path-provisioner macht das, was der Name sagt. Ein Ordner auf dem Node, dynamisch als PVC. WaitForFirstConsumer bindet das Volume dort, wo der Pod landet. Schön für local und Test. In Staging schon eine Lüge, wenn Staging Prod-ähnlich heißen soll.

Grenzen, die wir nicht weichspülen:

Kein Replikat des Blocks. Node weg, Daten weg, außer ihr habt ein Backup außerhalb des Nodes.

Kein sinnvolles Verschieben. Der Claim klebt am Node. Der Scheduler kann den Pod nicht einfach woanders hinsetzen.

Keine Snapshot-API, die ein Operator wie CNPG ernsthaft nutzen kann. Restore wird zum Kopieren von Dateien, nicht zum VolumeSnapshot.

Auf drei Prod-Knoten mit Postgres plus Elasticsearch plus RabbitMQ plus Valkey füllt local-path die Platten, bevor die CPU knapp wird. Disk-full ist dann ein Cluster-Event. Wer das nicht alarmiert, merkt es an der Fachanwendung. Den Metrik-Schnitt haben wir bei Grafana und Prometheus schon getrennt. Hier zählt nur: PVC-Füllstand ist Pflicht, nicht Kür.

Wir raten aktuell davon ab, local-path in Prod umzubenennen, damit es „enterprise“ klingt. Nennt es Test-Storage. Oder zieht einen Provisioner, der Snapshots und einen zweiten Rechner kann. Dazwischen liegt Selbstbetrug.

aks-pilot ist der Gegenpol. Azure Disk oder Files, andere Latency, andere Preise. Derselbe Claim-Name, andere Klasse. Wer Staging auf local-path und den Pilot auf Premium-SSD vergleicht, vergleicht nicht die App. Ihr vergleicht die Platte.

Worauf Sie vor dem ersten Prod-PVC achten

Fünf Punkte. Mehr erzeugt Checklisten-Nebel.

1. StorageClass bewusst, nicht Default. local-path nur wo Reset erlaubt ist. Prod bekommt eine Klasse mit Retain und, wenn möglich, Snapshot.
2. Anti-Affinity für alles mit Replica größer 1. Sonst liegen zwei Elasticsearch-Nodes auf einem Host und applaudieren sich selbst.
3. Operator vor nacktem Set, sobald Failover ernst ist. Postgres: CNPG. RabbitMQ: Cluster Operator. Valkey: noch kein Prod-Operator von uns.
4. Restore testen, nicht Backup-Job grün feiern. Ein PVC-Snapshot, den niemand zurückgespielt hat, ist eine Datei.
5. Ressourcen und Disk getrennt denken. CPU-Limits ohne Disk-Alarm sind die Hälfte.

Ein sechster Punkt, den Teams überspringen: Secrets und Passwörter der Datenklasse gehören nicht ins selbe Git wie das Overlay ohne Sealing. Das ist kein StatefulSet-Thema. Es wird eines, sobald postgres-0 neu entsteht und das Passwort aus einem Klartext-Manifest kommt.

Pexon Consulting (Microsoft Partner, 30 Azure-Spezialisten) sieht denselben Ablauf: erst die zustandslosen Services, dann eine Datenkomponente, dann die nächste. Wer alle vier Infra-Services in Woche eins in denselben Drei-Knoten-Cluster wirft, baut sich den Incident vor dem Go-Live. Ein Service nach dem anderen, mit Restore-Beweis dazwischen, ist langsamer auf der Folie und schneller im Ernstfall.

Häufig gestellte Fragen

Was kostet StatefulSet Kubernetes mit Postgres und Queues?

Das Primitive ist kostenlos. Geld sitzt in Storage, Operator-Betrieb, Restore-Übungen und dem Tag, an dem ein Node stirbt. Wir setzen keinen Listenpreis in diesen Artikel. Der Einstieg ist ein Betriebsgespräch in 45 Minuten.

StatefulSet Kubernetes oder Deployment: wann was?

Deployment für zustandslose Apps. StatefulSet, wenn Name oder Volume stabil sein müssen. Hochverfügbarkeit kommt vom Operator oder von der Datenbank selbst, nicht vom Kind-Namen -0.

Reicht local-path für Elasticsearch im Test?

Ja, mit dem Wissen, dass ein Node-Verlust die Indizes kostet. Für Prod reicht es nicht, sobald ihr Replica und Wiederherstellung behauptet.

Warum nicht Valkey über den offiziellen Operator?

Weil das Projekt selbst „not ready for production“ schreibt. Wir glauben Warnhinweisen auf der Titelseite. Ein Chart plus StatefulSet ist 2026 die ehrlichere Variante.

Für wen gehören Datenbanken gar nicht in den Cluster?

Für Teams ohne Storage-Strategie und ohne jemanden, der Restore übt. Dann ist eine gemanagte Datenbank neben Kubernetes der billigere Stolz. Der Cluster bleibt der Ort für die App, nicht für jede Platte, die ihr kennt.

Nächster Schritt

Verwandte Themen

and headings):**
* Let’s count words in German draft:
* Para 1:
„Bei einem Deployment bedeutet ein Node-Drain schlicht, dass der Scheduler neue Pods auf anderen Knoten startet, bevor oder während die alten beendet werden. Ein StatefulSet verhält sich grundlegend anders, weil

Wartung, Node-Drain und VolumeAttachment: Wo StatefulSets im Alltag blockieren

Bei einem zustandslosen Deployment ist ein Node-Drain ein Routinevorgang. Der Scheduler platziert neue Instanzen auf freien Knoten, der Datenverkehr schwenkt um und

Speicher vergrößern: Warum die PVC-Expansion am StatefulSet scheitert

Wenn die Datenbankplatte zu neunzig Prozent gefüllt ist, greifen Teams intuitiv zum Manifest des StatefulSets und erhöhen die Gigabyte-Angabe im Template. Die

Ungemeldete Node-Ausfälle: Warum Kubernetes StatefulSet-Pods nicht automatisch verlegt

Wenn ein Worker-Node im laufenden Betrieb unerwartet die Verbindung zur Control-Plane verliert, markiert Kubernetes diesen Knoten nach