Hva er StatefulSets, PersistentVolumes/Claims, og hvordan kjører du stateful workloads på Kubernetes?

Question

IT Interview Practice · Accepted Answer

Stateful workloads (databaser, køer, clustrede lagre) trenger **stabil identitet** og **varig lagring** — ting en Deployment ikke gir. En **StatefulSet** gir Pods stabile navn og ordnet livssyklus; **PersistentVolumes (PV)** og **PersistentVolumeClaims (PVC)** gir dem lagring som overlever Pod-en.

## Hvorfor Deployments ikke er nok

```text
Deployment-Pods er UTBYTTBARE: tilfeldige navn (web-7f9-abc), hvilken som helst rekkefølge, deler
ingenting per Pod. Det er perfekt for stateless apper — men en database-replica trenger:
  → en STABIL nettverksidentitet (så peers kan finne den: db-0, db-1, db-2)
  → sin EGEN varige disk som overlever restarts/rescheduling
  → ORDNET, kontrollert oppstart/skalering (start db-0 før db-1)
StatefulSet gir nettopp disse.
```

## StatefulSet-garantier

```text
Stabile NAVN     → pod-0, pod-1, pod-2 (ordinal, ikke tilfeldig)
Stabil DNS       → db-0.db.default.svc... via en headless Service
Stabil STORAGE   → hver Pod får sin EGEN PVC (db-0 beholder disken sin over restarts)
Ordnede ops      → opprett/skaler opp i rekkefølge 0,1,2…; terminer i omvendt rekkefølge
```

## Persistent lagring: PV, PVC, StorageClass

```text
StorageClass → "hvordan provisjonere"-malen (f.eks. AWS gp3, fast-ssd)
PVC          → en FORESPØRSEL om lagring ("Jeg trenger 20Gi, ReadWriteOnce")  ← app-vendt
PV           → det FAKTISKE provisjonerte volumet bundet til PVC-en           ← klynge-vendt
Dynamisk provisjonering: en PVC som refererer en StorageClass auto-oppretter en matchende PV.

App → PVC → (StorageClass provisjonerer) → PV → ekte disk (EBS, PD, Ceph, NFS…)
```

## En StatefulSet med lagring per Pod

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # headless Service for stabil 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:      # hver Pod får sin EGEN PVC/PV fra denne malen
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# Den headless Servicen som gir stabil per-Pod DNS (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 og forbehold

```text
ReadWriteOnce (RWO)  → montert read-write av ÉN node (mest block storage: EBS/PD)
ReadOnlyMany (ROX)   → read-only av mange noder
ReadWriteMany (RWX)  → read-write av mange noder (trenger NFS/CephFS/EFS)
⚠ Å slette en StatefulSet sletter IKKE PVC-ene dens som standard (data bevares).
⚠ Reclaim policy (Retain/Delete) avgjør hva som skjer med PV-en når PVC-en fjernes.
⚠ Kubernetes gir identitet+lagring, men clustering/replikering på app-nivå er DIN jobb
  (ofte via en Operator, f.eks. for Postgres/Kafka).
```

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

## Hvorfor det er viktig

Å kjøre stateful workloads korrekt er en av de vanskeligere delene av Kubernetes, så å forstå StatefulSets og persistent lagring er kunnskap på senior-nivå med reelle produksjonskonsekvenser. Kjerneinnsikten er *hvorfor* Deployments kommer til kort: Pods deres er utbyttbare (tilfeldige navn, hvilken som helst rekkefølge, ingen tilstand per Pod), som er ideelt for stateless tjenester, men galt for databaser og clustrede lagre som trenger **stabil identitet** (så peers kan finne `db-0`, `db-1`, `db-2` via DNS), **sin egen varige disk** som overlever restarts og rescheduling, og **ordnet, kontrollert** oppstart og skalering. En **StatefulSet** gir nettopp disse garantiene, og den parres med lagringsabstraksjonene: en **PersistentVolumeClaim** er den app-vendte forespørselen om lagring, et **PersistentVolume** er det faktiske provisjonerte volumet, og en **StorageClass** muliggjør dynamisk provisjonering — der `volumeClaimTemplates` gir hver Pod sin egen PVC/PV. Forbeholdene er der senioringeniører gjør seg fortjent: **access modes** (RWO vs RWX og hvilke backender som støtter dem), det faktum at å slette en StatefulSet **bevarer PVC-ene** som standard, **reclaim policy** som styrer PV-ens skjebne, og — kritisk — at Kubernetes gir identitet og lagring, men **replikering og clustering på applikasjonsnivå forblir ditt ansvar**, ofte delegert til en Operator. Fordi datavarighet og korrekt stateful atferd er ubarmhjertig (feil betyr datatap eller split-brain), er det å mestre StatefulSets, PV-er/PVC-er og forbeholdene deres grunnleggende for å kjøre databaser og andre stateful systemer pålitelig på Kubernetes.

Hvorfor Deployments ikke er nok

StatefulSet-garantier

Persistent lagring: PV, PVC, StorageClass

En StatefulSet med lagring per Pod

Access modes og forbehold

Hvorfor det er viktig

Relaterte spørsmål