Kubernetes StatefulSet einfach erklärt – Zustandsbehaftete Anwendungen korrekt betreiben

Ein Kubernetes StatefulSet ist ein Workload-Objekt für zustandsbehaftete Anwendungen mit stabilen Pod-Namen und persistentem Speicher.

Während Deployments ideal für zustandslose Anwendungen sind, stößt man bei Datenbanken, Message Queues oder verteilten Systemen schnell an Grenzen. Genau hier kommt das StatefulSet ins Spiel.

In diesem Artikel erfährst du ausführlich, was ein Kubernetes StatefulSet ist, wie es funktioniert, wann du es brauchst – und wann besser nicht.

Du lernst unter anderem:

• was ein StatefulSet in :contentReference[oaicite:0]{index=0} ist
• den Unterschied zwischen StatefulSet und Deployment
• wie stabile Identitäten & Volumes funktionieren
• YAML-Beispiele für StatefulSets
• Best Practices und typische Fehler

1) Was ist ein Kubernetes StatefulSet?

Ein StatefulSet ist ein Kubernetes-Workload-Objekt zur Verwaltung zustandsbehafteter Anwendungen. Im Gegensatz zu Deployments behandelt Kubernetes die Pods hier nicht als austauschbar.

Jedes Pod in einem StatefulSet besitzt:

• eine stabile, eindeutige Identität (Name & Hostname)
• ein fest zugeordnetes Persistent Volume
• eine definierte Start- und Stop-Reihenfolge

Merksatz: StatefulSet = Pods mit Gedächtnis

2) Wann braucht man ein StatefulSet?

StatefulSets sind immer dann sinnvoll, wenn eine Anwendung Zustand speichert oder eine feste Identität benötigt.

Typische Anwendungsfälle

• Datenbanken (z. B. PostgreSQL, MySQL, MongoDB)
• Message Queues (Kafka, RabbitMQ)
• verteilte Systeme mit Leader-Follower-Modell
• Legacy-Anwendungen mit lokalem Zustand

Für klassische Web-Frontends oder APIs ist ein StatefulSet meist die falsche Wahl.

3) StatefulSet vs Deployment

4) Zentrale Eigenschaften eines StatefulSets

4.1 Stabile Pod-Namen

Pods werden fortlaufend nummeriert:

myapp-0
myapp-1
myapp-2

Selbst nach einem Neustart bleibt der Name erhalten.

4.2 Stabile Netzwerknamen (Headless Service)

StatefulSets nutzen fast immer einen Headless Service, um jedem Pod einen festen DNS-Namen zu geben:

myapp-0.myapp.default.svc.cluster.local

4.3 Feste Persistent Volumes

Jeder Pod erhält sein eigenes Volume. Wird ein Pod neu erstellt, wird das gleiche Volume erneut gemountet.

5) Beispiel: Einfaches StatefulSet

Dieses Beispiel zeigt ein StatefulSet mit 3 Replikas und einem Persistent Volume pro Pod.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: myapp
spec:
  serviceName: myapp
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: app
        image: nginx:1.25
        volumeMounts:
        - name: data
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 5Gi

6) Skalierung eines StatefulSets

StatefulSets werden kontrolliert und sequenziell skaliert.

kubectl scale statefulset myapp --replicas=5

Neue Pods entstehen der Reihe nach: myapp-3, dann myapp-4.

7) Updates und Rollouts

Auch StatefulSets unterstützen Updates, allerdings vorsichtiger als Deployments.

Standardmäßig wird immer ein Pod nach dem anderen aktualisiert, beginnend mit dem höchsten Index.

Das ist besonders wichtig für Datenbanken oder Cluster, bei denen nicht alle Instanzen gleichzeitig neu starten dürfen.

8) Löschen von Pods und Volumes

Ein wichtiger Unterschied:

• Pods können gelöscht werden
• Volumes bleiben bestehen

Selbst wenn du das StatefulSet löschst, bleiben die Persistent Volumes erhalten – ideal für Datensicherheit, aber gefährlich, wenn man es vergisst.

9) Best Practices für StatefulSets

• Nur verwenden, wenn wirklich Zustand nötig ist
• Immer Backups für Persistent Volumes einplanen
• Headless Services korrekt konfigurieren
• Ressourcen-Limits setzen
• Updates zuerst in Staging testen

10) Häufige Fehler & Troubleshooting

• Pods hängen auf Pending → StorageClass prüfen
• DNS-Probleme → Headless Service fehlt
• Volumes blockieren Skalierung → Zugriffstyp prüfen

kubectl describe statefulset myapp
kubectl get pvc
kubectl get pods

11) Fazit

Ein Kubernetes StatefulSet ist das richtige Werkzeug für Anwendungen mit Zustand, stabiler Identität und persistentem Speicher. Es ist mächtiger – aber auch komplexer – als ein Deployment.

Faustregel: Nutze Deployments für zustandslose Workloads, StatefulSets nur, wenn der Zustand wirklich entscheidend ist.