Hvad er StatefulSets, PersistentVolumes/Claims, og hvordan kører man stateful workloads på Kubernetes?

Question

IT Interview Practice · Accepted Answer

Stateful workloads (databaser, køer, klyngede stores) har brug for **stabil identitet** og **holdbar storage** — ting, en Deployment ikke leverer. Et **StatefulSet** giver Pods stabile navne og ordnet livscyklus; **PersistentVolumes (PV)** og **PersistentVolumeClaims (PVC)** giver dem storage, der overlever Pod'en.

## Hvorfor Deployments ikke er nok

```text
Deployment-Pods er UDSKIFTELIGE: tilfældige navne (web-7f9-abc), enhver rækkefølge, deler
intet pr. Pod. Det er perfekt til stateless apps — men en database-replica har brug for:
  → en STABIL netværksidentitet (så peers kan finde den: db-0, db-1, db-2)
  → sin EGEN holdbare disk, der overlever genstarter/omplacering
  → ORDNET, kontrolleret opstart/skalering (bring db-0 op før db-1)
StatefulSet leverer præcis disse.
```

## StatefulSet-garantier

```text
Stabile NAVNE    → pod-0, pod-1, pod-2 (ordinal, ikke tilfældig)
Stabil DNS       → db-0.db.default.svc... via en headless Service
Stabil STORAGE   → hver Pod får sin EGEN PVC (db-0 beholder sin disk på tværs af genstarter)
Ordnede ops      → opret/skalér op i rækkefølge 0,1,2…; termineret i omvendt rækkefølge
```

## Persistent storage: PV, PVC, StorageClass

```text
StorageClass → "hvordan-man-provisionerer"-skabelonen (fx AWS gp3, fast-ssd)
PVC          → en ANMODNING om storage ("Jeg skal bruge 20Gi, ReadWriteOnce")   ← app-vendt
PV           → det FAKTISK provisionerede volume bundet til PVC'en               ← klynge-vendt
Dynamisk provisionering: en PVC, der refererer en StorageClass, opretter automatisk en matchende PV.

App → PVC → (StorageClass provisionerer) → PV → rigtig disk (EBS, PD, Ceph, NFS…)
```

## Et StatefulSet med storage pr. Pod

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # headless Service til 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 skabelon
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# Den headless Service, der giver stabil DNS pr. Pod (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 & forbehold

```text
ReadWriteOnce (RWO)  → mountet læse-skrive af ÉN node (de fleste block storage: EBS/PD)
ReadOnlyMany (ROX)   → skrivebeskyttet af mange nodes
ReadWriteMany (RWX)  → læse-skrive af mange nodes (kræver NFS/CephFS/EFS)
⚠ At slette et StatefulSet sletter IKKE dets PVC'er som standard (data bevares).
⚠ Reclaim policy (Retain/Delete) afgør, hvad der sker med PV'en, når PVC'en fjernes.
⚠ Kubernetes giver identitet+storage, men clustering/replikering på app-niveau er DIT ansvar
  (ofte via en Operator, fx til Postgres/Kafka).
```

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

## Hvorfor det betyder noget

At køre stateful workloads korrekt er en af de sværere dele af Kubernetes, så det er viden på seniorniveau med reelle production-konsekvenser at forstå StatefulSets og persistent storage. Kerneindsigten er *hvorfor* Deployments kommer til kort: deres Pods er udskiftelige (tilfældige navne, enhver rækkefølge, ingen tilstand pr. Pod), hvilket er ideelt til stateless services, men forkert til databaser og klyngede stores, der har brug for **stabil identitet** (så peers kan finde `db-0`, `db-1`, `db-2` via DNS), **deres egen holdbare disk**, der overlever genstarter og omplacering, og **ordnet, kontrolleret** opstart og skalering. Et **StatefulSet** leverer præcis disse garantier, og det parres med storage-abstraktionerne: en **PersistentVolumeClaim** er den app-vendte anmodning om storage, et **PersistentVolume** er det faktisk provisionerede volume, og en **StorageClass** muliggør dynamisk provisionering — hvor `volumeClaimTemplates` giver hver Pod sin egen PVC/PV. Forbeholdene er, hvor senioringeniører gør sig fortjent: **access modes** (RWO vs RWX og hvilke backends der understøtter dem), det faktum at sletning af et StatefulSet **bevarer dets PVC'er** som standard, **reclaim policy** der styrer PV'ens skæbne, og — afgørende — at Kubernetes leverer identitet og storage, men **replikering og clustering på applikationsniveau forbliver dit ansvar**, ofte uddelegeret til en Operator. Fordi dataholdbarhed og korrekt stateful adfærd er utilgivelige (fejl betyder datatab eller split-brain), er det at mestre StatefulSets, PV'er/PVC'er og deres forbehold fundamentalt for at køre databaser og andre stateful systemer pålideligt på Kubernetes.

Hvorfor Deployments ikke er nok

StatefulSet-garantier

Persistent storage: PV, PVC, StorageClass

Et StatefulSet med storage pr. Pod

Access modes & forbehold

Hvorfor det betyder noget

Relaterede spørgsmål