Ce sunt StatefulSets, PersistentVolumes/Claims și cum rulezi workload-uri stateful pe Kubernetes?

Question

IT Interview Practice · Accepted Answer

Workload-urile stateful (baze de date, cozi, store-uri clusterizate) au nevoie de **identitate stabilă** și **stocare durabilă** — lucruri pe care un Deployment nu le oferă. Un **StatefulSet** dă Pod-urilor nume stabile și ciclu de viață ordonat; **PersistentVolumes (PV)** și **PersistentVolumeClaims (PVC)** le dau stocare care supraviețuiește Pod-ului.

## De ce Deployments nu sunt suficiente

```text
Pod-urile de Deployment sunt INTERSCHIMBABILE: nume aleatorii (web-7f9-abc), orice ordine, nu
împart nimic per Pod. E perfect pentru aplicații stateless — dar o replică de bază de date are nevoie de:
  → o IDENTITATE de rețea STABILĂ (ca peer-ii să o găsească: db-0, db-1, db-2)
  → PROPRIUL disc durabil care supraviețuiește restart-urilor/reprogramării
  → pornire/scalare ORDONATĂ, controlată (pornește db-0 înainte de db-1)
StatefulSet oferă exact acestea.
```

## Garanțiile StatefulSet

```text
NUME stabile     → pod-0, pod-1, pod-2 (ordinal, nu aleatoriu)
DNS stabil       → db-0.db.default.svc... prin un Service headless
STOCARE stabilă  → fiecare Pod primește PROPRIUL PVC (db-0 își păstrează discul la restart)
Operații ordonate → creează/scalează în ordine 0,1,2…; termină în ordine inversă
```

## Stocare persistentă: PV, PVC, StorageClass

```text
StorageClass → template-ul "cum se provizionează" (ex. AWS gp3, fast-ssd)
PVC          → o CERERE de stocare ("am nevoie de 20Gi, ReadWriteOnce")   ← orientat spre app
PV           → volumul PROVIZIONAT efectiv legat de PVC                     ← orientat spre cluster
Provizionare dinamică: un PVC care referă un StorageClass creează automat un PV potrivit.

App → PVC → (StorageClass provizionează) → PV → disc real (EBS, PD, Ceph, NFS…)
```

## Un StatefulSet cu stocare per Pod

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # Service headless pentru DNS stabil
  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:      # fiecare Pod primește PROPRIUL PVC/PV din acest template
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# Service-ul headless care dă DNS stabil 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 }]
```

## Moduri de acces & avertismente

```text
ReadWriteOnce (RWO)  → montat read-write de UN singur node (majoritatea block storage: EBS/PD)
ReadOnlyMany (ROX)   → read-only de multe node-uri
ReadWriteMany (RWX)  → read-write de multe node-uri (are nevoie de NFS/CephFS/EFS)
⚠ Ștergerea unui StatefulSet NU șterge PVC-urile sale în mod implicit (datele sunt păstrate).
⚠ Reclaim policy (Retain/Delete) decide ce se întâmplă cu PV-ul când PVC-ul este eliminat.
⚠ Kubernetes dă identitate+stocare, dar clusterizarea/replicarea la nivel de app e sarcina TA
  (adesea prin un Operator, ex. pentru Postgres/Kafka).
```

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

## De ce contează

Rularea corectă a workload-urilor stateful este una dintre părțile mai grele ale Kubernetes, așa că înțelegerea StatefulSets și a stocării persistente este cunoaștere de nivel senior cu consecințe reale în producție. Intuiția centrală este *de ce* Deployments nu sunt suficiente: Pod-urile lor sunt interschimbabile (nume aleatorii, orice ordine, nicio stare per Pod), ceea ce e ideal pentru servicii stateless dar greșit pentru baze de date și store-uri clusterizate care au nevoie de **identitate stabilă** (ca peer-ii să găsească `db-0`, `db-1`, `db-2` prin DNS), **propriul disc durabil** care supraviețuiește restart-urilor și reprogramării, și pornire și scalare **ordonate, controlate**. Un **StatefulSet** oferă exact aceste garanții și se împerechează cu abstracțiile de stocare: un **PersistentVolumeClaim** este cererea de stocare orientată spre aplicație, un **PersistentVolume** este volumul provizionat efectiv, iar un **StorageClass** permite provizionarea dinamică — cu `volumeClaimTemplates` care dă fiecărui Pod propriul PVC/PV. Avertismentele sunt locul unde inginerii senior își câștigă existența: **modurile de acces** (RWO vs RWX și ce backend-uri le susțin), faptul că ștergerea unui StatefulSet **păstrează PVC-urile** în mod implicit, **reclaim policy** care guvernează soarta PV-ului și — critic — că Kubernetes oferă identitate și stocare dar **replicarea și clusterizarea la nivel de aplicație rămân responsabilitatea ta**, adesea delegate unui Operator. Deoarece durabilitatea datelor și comportamentul stateful corect sunt neiertătoare (greșelile înseamnă pierdere de date sau split-brain), stăpânirea StatefulSets, PV/PVC și a avertismentelor lor este fundamentală pentru a rula baze de date și alte sisteme stateful fiabil pe Kubernetes.

De ce Deployments nu sunt suficiente

Garanțiile StatefulSet

Stocare persistentă: PV, PVC, StorageClass

Un StatefulSet cu stocare per Pod

Moduri de acces & avertismente

De ce contează

Întrebări conexe