Co jsou StatefulSety, PersistentVolume/Claim a jak provozovat stavové (stateful) workloady na Kubernetes?

Question

IT Interview Practice · Accepted Answer

Stavové workloady (databáze, fronty, clusterovaná úložiště) potřebují **stabilní identitu** a **trvalé úložiště** — což Deployment neposkytuje. **StatefulSet** dává Podům stabilní jména a uspořádaný životní cyklus; **PersistentVolume (PV)** a **PersistentVolumeClaim (PVC)** jim dávají úložiště, které přežije Pod.

## Proč Deploymenty nestačí

```text
Pody Deploymentu jsou ZAMĚNITELNÉ: náhodná jména (web-7f9-abc), libovolné pořadí, nic
nesdílejí per-Pod. To je ideální pro bezstavové aplikace — ale replika databáze potřebuje:
  → STABILNÍ síťovou identitu (aby ji peers našli: db-0, db-1, db-2)
  → VLASTNÍ trvalý disk, který přežije restarty/přeplánování
  → USPOŘÁDANÝ, řízený start/škálování (nejdřív db-0, pak db-1)
StatefulSet poskytuje přesně tohle.
```

## Záruky StatefulSetu

```text
Stabilní JMÉNA    → pod-0, pod-1, pod-2 (pořadová, ne náhodná)
Stabilní DNS      → db-0.db.default.svc... přes headless Service
Stabilní ÚLOŽIŠTĚ  → každý Pod dostane VLASTNÍ PVC (db-0 si drží disk přes restarty)
Uspořádané operace → vytváření/zvětšování v pořadí 0,1,2…; ukončování v opačném
```

## Trvalé úložiště: PV, PVC, StorageClass

```text
StorageClass → šablona "jak provisionovat" (např. AWS gp3, fast-ssd)
PVC          → POŽADAVEK na úložiště ("potřebuji 20Gi, ReadWriteOnce")   ← směrem k aplikaci
PV           → SKUTEČNĚ vytvořený volume navázaný na PVC                  ← směrem ke clusteru
Dynamic provisioning: PVC odkazující na StorageClass automaticky vytvoří odpovídající PV.

App → PVC → (StorageClass provisionuje) → PV → skutečný disk (EBS, PD, Ceph, NFS…)
```

## StatefulSet s úložištěm pro každý Pod

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # headless Service pro stabilní 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:      # každý Pod dostane VLASTNÍ PVC/PV z této šablony
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# Headless Service, který dává stabilní DNS pro každý Pod (db-0.db, db-1.db, …)
apiVersion: v1
kind: Service
metadata: { name: db }
spec:
  clusterIP: None            # headless
  selector: { app: db }
  ports: [{ port: 5432 }]
```

## Přístupové režimy a výhrady

```text
ReadWriteOnce (RWO)  → připojeno pro čtení i zápis JEDNÍM nodem (většina blokových úložišť: EBS/PD)
ReadOnlyMany (ROX)   → jen pro čtení mnoha nody
ReadWriteMany (RWX)  → pro čtení i zápis mnoha nody (potřebuje NFS/CephFS/EFS)
⚠ Smazání StatefulSetu ve výchozím stavu NESMAŽE jeho PVC (data se zachovají).
⚠ Reclaim policy (Retain/Delete) rozhoduje, co se stane s PV po odstranění PVC.
⚠ Kubernetes dává identitu+úložiště, ale clustering/replikace na úrovni aplikace je VAŠE práce
  (často přes Operator, např. pro Postgres/Kafka).
```

```bash
kubectl get statefulset,pvc,pv
kubectl get pods -l app=db      # db-0, db-1, db-2 (stabilní, uspořádané)
```

## Proč je to důležité

Správný provoz stavových workloadů je jedna z těžších částí Kubernetes, takže pochopení StatefulSetů a trvalého úložiště je znalost na seniorní úrovni se skutečnými produkčními důsledky. Klíčové je pochopit, *proč* Deploymenty nestačí: jejich Pody jsou zaměnitelné (náhodná jména, libovolné pořadí, žádný stav per Pod), což je ideální pro bezstavové služby, ale špatné pro databáze a clusterovaná úložiště, které potřebují **stabilní identitu** (aby peers našli `db-0`, `db-1`, `db-2` přes DNS), **vlastní trvalý disk**, který přežije restarty a přeplánování, a **uspořádaný, řízený** start a škálování. **StatefulSet** poskytuje přesně tyto záruky a spojuje se s abstrakcemi úložiště: **PersistentVolumeClaim** je požadavek na úložiště směrem k aplikaci, **PersistentVolume** je skutečně vytvořený volume a **StorageClass** umožňuje dynamic provisioning — přičemž `volumeClaimTemplates` dává každému Podu vlastní PVC/PV. Výhrady jsou tam, kde si senioři zaslouží svou mzdu: **přístupové režimy** (RWO vs RWX a které backendy je podporují), fakt, že smazání StatefulSetu ve výchozím stavu **zachová jeho PVC**, **reclaim policy** řídící osud PV a — zásadně — že Kubernetes poskytuje identitu a úložiště, ale **replikace a clustering na úrovni aplikace zůstávají vaší zodpovědností**, často delegovanou na Operator. Protože trvanlivost dat a správné stavové chování jsou nemilosrdné (chyby znamenají ztrátu dat nebo split-brain), zvládnutí StatefulSetů, PV/PVC a jejich výhrad je základem pro spolehlivý provoz databází a dalších stavových systémů na Kubernetes.

Proč Deploymenty nestačí

Záruky StatefulSetu

Trvalé úložiště: PV, PVC, StorageClass

StatefulSet s úložištěm pro každý Pod

Přístupové režimy a výhrady

Proč je to důležité

Související otázky