Was sind StatefulSets, PersistentVolumes/Claims, und wie betreibst du stateful Workloads auf Kubernetes?

Question

IT Interview Practice · Accepted Answer

Stateful Workloads (Datenbanken, Queues, geclusterte Stores) brauchen **stabile Identität** und **dauerhaften Speicher** — Dinge, die ein Deployment nicht bietet. Ein **StatefulSet** gibt Pods stabile Namen und einen geordneten Lebenszyklus; **PersistentVolumes (PV)** und **PersistentVolumeClaims (PVC)** geben ihnen Speicher, der den Pod überlebt.

## Warum Deployments nicht ausreichen

```text
Deployment-Pods sind AUSTAUSCHBAR: zufällige Namen (web-7f9-abc), beliebige Reihenfolge, teilen
pro Pod nichts. Perfekt für stateless Apps — aber eine Datenbank-Replica braucht:
  → eine STABILE Netzwerkidentität (damit Peers sie finden: db-0, db-1, db-2)
  → ihre EIGENE dauerhafte Disk, die Restarts/Rescheduling übersteht
  → GEORDNETEN, kontrollierten Start/Skalierung (db-0 vor db-1 hochfahren)
StatefulSet liefert genau diese.
```

## StatefulSet-Garantien

```text
Stabile NAMEN     → pod-0, pod-1, pod-2 (ordinal, nicht zufällig)
Stabiles DNS      → db-0.db.default.svc... über einen headless Service
Stabiler STORAGE  → jeder Pod bekommt sein EIGENES PVC (db-0 behält seine Disk über Restarts)
Geordnete Ops     → in Reihenfolge 0,1,2… erstellen/hochskalieren; in umgekehrter beenden
```

## Persistenter Speicher: PV, PVC, StorageClass

```text
StorageClass → das "Wie-provisionieren"-Template (z. B. AWS gp3, fast-ssd)
PVC          → eine ANFRAGE nach Speicher ("Ich brauche 20Gi, ReadWriteOnce")   ← app-seitig
PV           → das TATSÄCHLICH provisionierte Volume, an das PVC gebunden        ← cluster-seitig
Dynamisches Provisioning: ein PVC, das auf eine StorageClass verweist, erzeugt automatisch ein passendes PV.

App → PVC → (StorageClass provisioniert) → PV → echte Disk (EBS, PD, Ceph, NFS…)
```

## Ein StatefulSet mit Speicher pro Pod

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # headless Service für stabiles DNS
  replicas: 3
  selector:
    matchLabels: { app: db }
  template:
    metadata:
      labels: { app: db }
    spec:
      containers:
        - name: db
          image: postgres:16
          ports: [{ containerPort: 5432 }]
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:      # jeder Pod bekommt sein EIGENES PVC/PV aus diesem Template
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# Der headless Service, der stabiles DNS pro Pod gibt (db-0.db, db-1.db, …)
apiVersion: v1
kind: Service
metadata: { name: db }
spec:
  clusterIP: None            # headless
  selector: { app: db }
  ports: [{ port: 5432 }]
```

## Access modes & Vorbehalte

```text
ReadWriteOnce (RWO)  → read-write von EINEM Node gemountet (die meisten Block-Storages: EBS/PD)
ReadOnlyMany (ROX)   → read-only von vielen Nodes
ReadWriteMany (RWX)  → read-write von vielen Nodes (braucht NFS/CephFS/EFS)
⚠ Ein StatefulSet zu löschen löscht standardmäßig NICHT seine PVCs (Daten bleiben erhalten).
⚠ Die reclaim policy (Retain/Delete) entscheidet, was mit dem PV passiert, wenn das PVC entfernt wird.
⚠ Kubernetes gibt Identität+Storage, aber App-Level-Clustering/Replikation ist DEINE Aufgabe
  (oft über einen Operator, z. B. für Postgres/Kafka).
```

```bash
kubectl get statefulset,pvc,pv
kubectl get pods -l app=db      # db-0, db-1, db-2 (stabil, geordnet)
```

## Warum es wichtig ist

Stateful Workloads korrekt zu betreiben ist einer der schwierigeren Teile von Kubernetes, daher ist das Verständnis von StatefulSets und persistentem Speicher Senior-Level-Wissen mit echten Produktionskonsequenzen. Die Kerneinsicht ist, *warum* Deployments zu kurz greifen: Ihre Pods sind austauschbar (zufällige Namen, beliebige Reihenfolge, kein Zustand pro Pod), was für stateless Services ideal, aber für Datenbanken und geclusterte Stores falsch ist, die **stabile Identität** brauchen (damit Peers `db-0`, `db-1`, `db-2` per DNS finden), **ihre eigene dauerhafte Disk**, die Restarts und Rescheduling übersteht, und **geordneten, kontrollierten** Start und Skalierung. Ein **StatefulSet** liefert genau diese Garantien und paart sich mit den Storage-Abstraktionen: Ein **PersistentVolumeClaim** ist die app-seitige Anfrage nach Speicher, ein **PersistentVolume** ist das tatsächlich provisionierte Volume, und eine **StorageClass** ermöglicht dynamisches Provisioning — wobei `volumeClaimTemplates` jedem Pod sein eigenes PVC/PV gibt. Bei den Vorbehalten verdienen sich Senior-Ingenieure ihren Lohn: **access modes** (RWO vs. RWX und welche Backends sie unterstützen), die Tatsache, dass das Löschen eines StatefulSet **seine PVCs standardmäßig erhält**, die **reclaim policy**, die das Schicksal des PV bestimmt, und — entscheidend — dass Kubernetes Identität und Speicher bietet, aber **Replikation und Clustering auf App-Ebene deine Verantwortung bleiben**, oft an einen Operator delegiert. Weil Datenhaltbarkeit und korrektes stateful Verhalten unerbittlich sind (Fehler bedeuten Datenverlust oder Split-Brain), ist die Beherrschung von StatefulSets, PVs/PVCs und ihren Vorbehalten grundlegend, um Datenbanken und andere stateful Systeme zuverlässig auf Kubernetes zu betreiben.

Warum Deployments nicht ausreichen

StatefulSet-Garantien

Persistenter Speicher: PV, PVC, StorageClass

Ein StatefulSet mit Speicher pro Pod

Access modes & Vorbehalte

Warum es wichtig ist

Ähnliche Fragen