Wat zijn StatefulSets, PersistentVolumes/Claims, en hoe draai je stateful workloads op Kubernetes?

Question

IT Interview Practice · Accepted Answer

Stateful workloads (databases, queues, geclusterde stores) hebben **stabiele identiteit** en **duurzame storage** nodig — dingen die een Deployment niet biedt. Een **StatefulSet** geeft Pods stabiele namen en een geordende lifecycle; **PersistentVolumes (PV)** en **PersistentVolumeClaims (PVC)** geven ze storage die de Pod overleeft.

## Waarom Deployments niet volstaan

```text
Deployment-Pods zijn UITWISSELBAAR: willekeurige namen (web-7f9-abc), elke volgorde, delen
niets per Pod. Dat is perfect voor stateless apps — maar een database-replica heeft nodig:
  → een STABIELE netwerkidentiteit (zodat peers hem vinden: db-0, db-1, db-2)
  → zijn EIGEN duurzame schijf die restarts/rescheduling overleeft
  → GEORDENDE, gecontroleerde startup/scaling (breng db-0 op vóór db-1)
StatefulSet levert precies deze.
```

## Garanties van een StatefulSet

```text
Stabiele NAMEN   → pod-0, pod-1, pod-2 (ordinaal, niet willekeurig)
Stabiele DNS     → db-0.db.default.svc... via een headless Service
Stabiele STORAGE → elke Pod krijgt zijn EIGEN PVC (db-0 houdt zijn schijf over restarts heen)
Geordende ops    → aanmaken/opschalen in volgorde 0,1,2…; beëindigen in omgekeerde volgorde
```

## Duurzame storage: PV, PVC, StorageClass

```text
StorageClass → het "hoe te provisionen"-sjabloon (bijv. AWS gp3, fast-ssd)
PVC          → een AANVRAAG voor storage ("Ik heb 20Gi nodig, ReadWriteOnce")  ← app-kant
PV           → het DAADWERKELIJK geprovisionde volume gebonden aan de PVC       ← cluster-kant
Dynamic provisioning: een PVC die naar een StorageClass verwijst, maakt automatisch een passende PV aan.

App → PVC → (StorageClass provisiont) → PV → echte schijf (EBS, PD, Ceph, NFS…)
```

## Een StatefulSet met storage per Pod

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # headless Service voor stabiele 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:      # elke Pod krijgt zijn EIGEN PVC/PV uit dit sjabloon
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# De headless Service die stabiele DNS per Pod geeft (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 & kanttekeningen

```text
ReadWriteOnce (RWO)  → read-write gemount door ÉÉN node (meeste block storage: EBS/PD)
ReadOnlyMany (ROX)   → read-only door veel nodes
ReadWriteMany (RWX)  → read-write door veel nodes (heeft NFS/CephFS/EFS nodig)
⚠ Een StatefulSet verwijderen verwijdert standaard NIET zijn PVCs (data blijft behouden).
⚠ Reclaim policy (Retain/Delete) beslist wat er met de PV gebeurt wanneer de PVC wordt verwijderd.
⚠ Kubernetes geeft identiteit+storage, maar clustering/replicatie op app-niveau is JOUW taak
  (vaak via een Operator, bijv. voor Postgres/Kafka).
```

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

## Waarom het belangrijk is

Stateful workloads correct draaien is een van de moeilijkere onderdelen van Kubernetes, dus StatefulSets en duurzame storage begrijpen is kennis op senior-niveau met echte productiegevolgen. Het kerninzicht is *waarom* Deployments tekortschieten: hun Pods zijn uitwisselbaar (willekeurige namen, elke volgorde, geen state per Pod), wat ideaal is voor stateless services maar verkeerd voor databases en geclusterde stores die **stabiele identiteit** nodig hebben (zodat peers `db-0`, `db-1`, `db-2` via DNS kunnen vinden), **hun eigen duurzame schijf** die restarts en rescheduling overleeft, en **geordende, gecontroleerde** startup en scaling. Een **StatefulSet** biedt precies deze garanties, en het is gekoppeld aan de storage-abstracties: een **PersistentVolumeClaim** is de applicatiegerichte aanvraag voor storage, een **PersistentVolume** is het daadwerkelijk geprovisionde volume, en een **StorageClass** maakt dynamic provisioning mogelijk — waarbij `volumeClaimTemplates` elke Pod zijn eigen PVC/PV geeft. De kanttekeningen zijn waar senior engineers hun geld verdienen: **access modes** (RWO vs RWX en welke backends ze ondersteunen), het feit dat een StatefulSet verwijderen standaard **zijn PVCs behoudt**, de **reclaim policy** die het lot van de PV bepaalt, en — cruciaal — dat Kubernetes identiteit en storage biedt maar **replicatie en clustering op applicatieniveau jouw verantwoordelijkheid blijven**, vaak gedelegeerd aan een Operator. Omdat data-duurzaamheid en correct stateful gedrag onvergeeflijk zijn (fouten betekenen dataverlies of split-brain), is het beheersen van StatefulSets, PV's/PVC's en hun kanttekeningen fundamenteel om databases en andere stateful systemen betrouwbaar op Kubernetes te draaien.

Waarom Deployments niet volstaan

Garanties van een StatefulSet

Duurzame storage: PV, PVC, StorageClass

Een StatefulSet met storage per Pod

Access modes & kanttekeningen

Waarom het belangrijk is

Gerelateerde vragen