Czym są StatefulSets, PersistentVolumes/Claims i jak uruchamiać stanowe workloady na Kubernetes?

Question

IT Interview Practice · Accepted Answer

Workloady stanowe (bazy danych, kolejki, klastrowane magazyny) potrzebują **stabilnej tożsamości** i **trwałej pamięci masowej** — rzeczy, których Deployment nie zapewnia. **StatefulSet** nadaje Podom stabilne nazwy i uporządkowany cykl życia; **PersistentVolumes (PV)** i **PersistentVolumeClaims (PVC)** dają im pamięć, która przeżywa Poda.

## Dlaczego Deploymenty nie wystarczą

```text
Pody Deploymentu są WYMIENNE: losowe nazwy (web-7f9-abc), dowolna kolejność, nic nie
współdzielą per-Pod. To idealne dla aplikacji bezstanowych — ale replika bazy danych potrzebuje:
  → STABILNEJ tożsamości sieciowej (aby peery ją znalazły: db-0, db-1, db-2)
  → WŁASNEGO trwałego dysku, który przeżyje restarty/przeplanowanie
  → UPORZĄDKOWANEGO, kontrolowanego startu/skalowania (postaw db-0 przed db-1)
StatefulSet zapewnia dokładnie to.
```

## Gwarancje StatefulSet

```text
Stabilne NAZWY     → pod-0, pod-1, pod-2 (porządkowe, nie losowe)
Stabilny DNS       → db-0.db.default.svc... przez headless Service
Stabilna PAMIĘĆ    → każdy Pod dostaje WŁASNY PVC (db-0 zachowuje swój dysk przez restarty)
Uporządkowane ops  → tworzenie/skalowanie w górę w kolejności 0,1,2…; kończenie w odwrotnej
```

## Trwała pamięć: PV, PVC, StorageClass

```text
StorageClass → szablon "jak provisionować" (np. AWS gp3, fast-ssd)
PVC          → ŻĄDANIE pamięci ("potrzebuję 20Gi, ReadWriteOnce")   ← od strony aplikacji
PV           → FAKTYCZNIE zprovisionowany wolumen powiązany z PVC     ← od strony klastra
Dynamiczne provisionowanie: PVC odwołujący się do StorageClass auto-tworzy pasujący PV.

Aplikacja → PVC → (StorageClass provisionuje) → PV → prawdziwy dysk (EBS, PD, Ceph, NFS…)
```

## StatefulSet z pamięcią per-Pod

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # headless Service dla stabilnego 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żdy Pod dostaje WŁASNY PVC/PV z tego szablonu
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# Headless Service, który daje stabilny DNS per-Pod (db-0.db, db-1.db, …)
apiVersion: v1
kind: Service
metadata: { name: db }
spec:
  clusterIP: None            # headless
  selector: { app: db }
  ports: [{ port: 5432 }]
```

## Tryby dostępu i zastrzeżenia

```text
ReadWriteOnce (RWO)  → montowany do odczytu-zapisu przez JEDEN node (większość block storage: EBS/PD)
ReadOnlyMany (ROX)   → tylko do odczytu przez wiele nodów
ReadWriteMany (RWX)  → odczyt-zapis przez wiele nodów (potrzebuje NFS/CephFS/EFS)
⚠ Usunięcie StatefulSet domyślnie NIE usuwa jego PVC (dane są zachowane).
⚠ Reclaim policy (Retain/Delete) decyduje, co dzieje się z PV, gdy PVC jest usuwany.
⚠ Kubernetes daje tożsamość+pamięć, ale klastrowanie/replikacja na poziomie aplikacji to TWOJE zadanie
  (często przez Operatora, np. dla Postgres/Kafka).
```

```bash
kubectl get statefulset,pvc,pv
kubectl get pods -l app=db      # db-0, db-1, db-2 (stabilne, uporządkowane)
```

## Dlaczego to ważne

Poprawne uruchamianie stanowych workloadów to jedna z trudniejszych części Kubernetesa, więc zrozumienie StatefulSetów i trwałej pamięci to wiedza na poziomie senior o realnych produkcyjnych konsekwencjach. Kluczowe spostrzeżenie to *dlaczego* Deploymenty nie wystarczają: ich Pody są wymienne (losowe nazwy, dowolna kolejność, brak stanu per-Pod), co jest idealne dla usług bezstanowych, ale błędne dla baz danych i klastrowanych magazynów, które potrzebują **stabilnej tożsamości** (aby peery znalazły `db-0`, `db-1`, `db-2` po DNS), **własnego trwałego dysku**, który przeżyje restarty i przeplanowanie, oraz **uporządkowanego, kontrolowanego** startu i skalowania. **StatefulSet** zapewnia dokładnie te gwarancje i łączy się z abstrakcjami pamięci: **PersistentVolumeClaim** to żądanie pamięci od strony aplikacji, **PersistentVolume** to faktycznie zprovisionowany wolumen, a **StorageClass** umożliwia dynamiczne provisionowanie — z `volumeClaimTemplates` dającym każdemu Podowi własny PVC/PV. Zastrzeżenia to miejsce, gdzie inżynierowie senior zarabiają na swoje utrzymanie: **tryby dostępu** (RWO vs RWX i które backendy je wspierają), fakt, że usunięcie StatefulSet domyślnie **zachowuje jego PVC**, **reclaim policy** rządząca losem PV oraz — co kluczowe — że Kubernetes zapewnia tożsamość i pamięć, ale **replikacja i klastrowanie na poziomie aplikacji pozostają twoją odpowiedzialnością**, często delegowaną do Operatora. Ponieważ trwałość danych i poprawne zachowanie stanowe są bezlitosne (błędy oznaczają utratę danych lub split-brain), opanowanie StatefulSetów, PV/PVC i ich zastrzeżeń jest fundamentalne dla niezawodnego uruchamiania baz danych i innych systemów stanowych na Kubernetes.

Dlaczego Deploymenty nie wystarczą

Gwarancje StatefulSet

Trwała pamięć: PV, PVC, StorageClass

StatefulSet z pamięcią per-Pod

Tryby dostępu i zastrzeżenia

Dlaczego to ważne

Powiązane pytania