Kas yra StatefulSet'ai, PersistentVolume'ai/Claim'ai ir kaip Kubernetes'e paleisti stateful workload'us?

Question

IT Interview Practice · Accepted Answer

Stateful workload'ams (duomenų bazėms, eilėms, klasterizuotoms saugykloms) reikia **stabilaus tapatumo** ir **patvarios saugyklos** — dalykų, kurių Deployment nesuteikia. **StatefulSet** suteikia Pod'ams stabilius vardus ir tvarkingą gyvavimo ciklą; **PersistentVolume'ai (PV)** ir **PersistentVolumeClaim'ai (PVC)** suteikia jiems saugyklą, gyvenančią ilgiau nei Pod'as.

## Kodėl Deployment'ų neužtenka

```text
Deployment Pod'ai yra PAKEIČIAMI: atsitiktiniai vardai (web-7f9-abc), bet kokia tvarka, nieko
nedalija kiekvienam Pod'ui. Tai puiku stateless app — bet DB replikai reikia:
  → STABILAUS tinklo tapatumo (kad kaimynai jį rastų: db-0, db-1, db-2)
  → SAVO patvaraus disko, išgyvenančio restart'us/perplanavimą
  → TVARKINGO, kontroliuojamo starto/mastelio (pakelti db-0 prieš db-1)
StatefulSet suteikia būtent tai.
```

## StatefulSet garantijos

```text
Stabilūs VARDAI    → pod-0, pod-1, pod-2 (eiliniai, ne atsitiktiniai)
Stabilus DNS       → db-0.db.default.svc... per headless Service
Stabili SAUGYKLA   → kiekvienas Pod'as gauna SAVO PVC (db-0 išlaiko diską per restart'us)
Tvarkingos operacijos → kūrimas/didinimas eilės tvarka 0,1,2…; nutraukimas atvirkščiai
```

## Patvari saugykla: PV, PVC, StorageClass

```text
StorageClass → "kaip provisioninti" šablonas (pvz., AWS gp3, fast-ssd)
PVC          → UŽKLAUSA saugyklai ("reikia 20Gi, ReadWriteOnce")   ← į app pusę
PV           → FAKTINIS provisioninTAS volume'as, susietas su PVC   ← į klasterio pusę
Dinaminis provisioning: PVC, nurodantis StorageClass, automatiškai sukuria atitinkamą PV.

App → PVC → (StorageClass provisionina) → PV → realus diskas (EBS, PD, Ceph, NFS…)
```

## StatefulSet su saugykla kiekvienam Pod'ui

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # headless Service stabiliam 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:      # kiekvienas Pod'as gauna SAVO PVC/PV iš šio šablono
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# Headless Service, suteikiantis stabilų DNS kiekvienam Pod'ui (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 ir pastabos

```text
ReadWriteOnce (RWO)  → prijungiamas skaitymui-rašymui VIENO node (dauguma block storage: EBS/PD)
ReadOnlyMany (ROX)   → tik skaitymui daugelio node'ų
ReadWriteMany (RWX)  → skaitymui-rašymui daugelio node'ų (reikia NFS/CephFS/EFS)
⚠ StatefulSet ištrynimas pagal numatymą NEIŠTRINA jo PVC (duomenys išsaugomi).
⚠ Reclaim policy (Retain/Delete) lemia, kas nutinka PV, kai PVC pašalinamas.
⚠ Kubernetes suteikia tapatumą+saugyklą, bet app lygio klasterizavimas/replikacija yra JŪSŲ darbas
  (dažnai per Operator, pvz., Postgres/Kafka).
```

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

## Kodėl tai svarbu

Stateful workload'ų teisingas paleidimas yra viena sudėtingesnių Kubernetes dalių, tad suprasti StatefulSet'us ir patvarią saugyklą yra senior-lygio žinia su realiomis production pasekmėmis. Pagrindinė įžvalga — *kodėl* Deployment'ų neužtenka: jų Pod'ai yra pakeičiami (atsitiktiniai vardai, bet kokia tvarka, jokios būsenos kiekvienam Pod'ui), o tai idealu stateless service'ams, bet netinka duomenų bazėms ir klasterizuotoms saugykloms, kurioms reikia **stabilaus tapatumo** (kad kaimynai rastų `db-0`, `db-1`, `db-2` per DNS), **savo patvaraus disko**, išgyvenančio restart'us ir perplanavimą, bei **tvarkingo, kontroliuojamo** starto ir mastelio keitimo. **StatefulSet** suteikia būtent šias garantijas ir dera su saugyklos abstrakcijomis: **PersistentVolumeClaim** yra į aplikaciją nukreipta užklausa saugyklai, **PersistentVolume** yra faktinis provisioninTas volume'as, o **StorageClass** įgalina dinaminį provisioning'ą — su `volumeClaimTemplates`, suteikiančiais kiekvienam Pod'ui savo PVC/PV. Pastabose senior inžinieriai ir įrodo savo vertę: **access modes** (RWO vs. RWX ir kurie backend'ai juos palaiko), faktas, kad StatefulSet ištrynimas pagal numatymą **išsaugo jo PVC**, **reclaim policy**, valdanti PV likimą, ir — kritiškai — kad Kubernetes suteikia tapatumą bei saugyklą, bet **app lygio replikacija ir klasterizavimas lieka jūsų atsakomybė**, dažnai deleguojama Operator'iui. Kadangi duomenų patvarumas ir teisingas stateful elgesys yra negailestingi (klaidos reiškia duomenų praradimą ar split-brain), StatefulSet'ų, PV/PVC ir jų pastabų įvaldymas yra pamatinis patikimai paleisti duomenų bazes ir kitas stateful sistemas Kubernetes'e.

Kodėl Deployment'ų neužtenka

StatefulSet garantijos

Patvari saugykla: PV, PVC, StorageClass

StatefulSet su saugykla kiekvienam Pod'ui

Access modes ir pastabos

Kodėl tai svarbu

Susiję klausimai