Que sont les StatefulSets, les PersistentVolumes/Claims, et comment fait-on tourner des workloads stateful sur Kubernetes ?

Question

IT Interview Practice · Accepted Answer

Les workloads stateful (bases de données, files d'attente, stores en cluster) ont besoin d'une **identité stable** et d'un **stockage durable** — des choses qu'un Deployment ne fournit pas. Un **StatefulSet** donne aux Pods des noms stables et un cycle de vie ordonné ; les **PersistentVolumes (PV)** et les **PersistentVolumeClaims (PVC)** leur donnent un stockage qui survit au Pod.

## Pourquoi les Deployments ne suffisent pas

```text
Les Pods d'un Deployment sont INTERCHANGEABLES : noms aléatoires (web-7f9-abc), n'importe quel ordre, ne
partagent rien par Pod. C'est parfait pour les apps stateless — mais un réplica de base de données a besoin de :
  → une IDENTITÉ réseau STABLE (pour que les pairs le trouvent : db-0, db-1, db-2)
  → son PROPRE disque durable qui survit aux redémarrages/replanifications
  → un démarrage/scaling ORDONNÉ et contrôlé (démarrer db-0 avant db-1)
Le StatefulSet fournit exactement cela.
```

## Garanties du StatefulSet

```text
NOMS stables     → pod-0, pod-1, pod-2 (ordinal, pas aléatoire)
DNS stable       → db-0.db.default.svc... via un headless Service
STOCKAGE stable  → chaque Pod obtient sa PROPRE PVC (db-0 garde son disque au fil des redémarrages)
Opérations ordonnées → création/scale up dans l'ordre 0,1,2… ; terminaison en ordre inverse
```

## Stockage persistant : PV, PVC, StorageClass

```text
StorageClass → le template « comment provisionner » (ex. AWS gp3, fast-ssd)
PVC          → une DEMANDE de stockage (« Il me faut 20Gi, ReadWriteOnce »)   ← côté app
PV           → le volume réellement provisionné lié à la PVC                    ← côté cluster
Provisioning dynamique : une PVC référençant une StorageClass crée automatiquement un PV correspondant.

App → PVC → (la StorageClass provisionne) → PV → disque réel (EBS, PD, Ceph, NFS…)
```

## Un StatefulSet avec stockage par Pod

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # headless Service pour un DNS stable
  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:      # chaque Pod obtient sa PROPRE PVC/PV depuis ce template
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# Le headless Service qui donne un DNS stable par 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 & mises en garde

```text
ReadWriteOnce (RWO)  → monté en read-write par UN SEUL node (la plupart du block storage : EBS/PD)
ReadOnlyMany (ROX)   → read-only par plusieurs nodes
ReadWriteMany (RWX)  → read-write par plusieurs nodes (nécessite NFS/CephFS/EFS)
⚠ Supprimer un StatefulSet ne supprime PAS ses PVCs par défaut (les données sont préservées).
⚠ La reclaim policy (Retain/Delete) décide ce qu'il advient du PV quand la PVC est retirée.
⚠ Kubernetes fournit identité+stockage, mais le clustering/la réplication au niveau applicatif sont VOTRE travail
  (souvent via un Operator, ex. pour Postgres/Kafka).
```

```bash
kubectl get statefulset,pvc,pv
kubectl get pods -l app=db      # db-0, db-1, db-2 (stables, ordonnés)
```

## Pourquoi c'est important

Faire tourner correctement des workloads stateful est l'une des parties les plus difficiles de Kubernetes, donc comprendre les StatefulSets et le stockage persistant est une connaissance de niveau senior aux conséquences réelles en production. L'idée centrale est *pourquoi* les Deployments sont insuffisants : leurs Pods sont interchangeables (noms aléatoires, n'importe quel ordre, aucun état par Pod), ce qui est idéal pour les services stateless mais faux pour les bases de données et les stores en cluster qui ont besoin d'une **identité stable** (pour que les pairs trouvent `db-0`, `db-1`, `db-2` par DNS), de **leur propre disque durable** qui survit aux redémarrages et replanifications, et d'un démarrage et scaling **ordonnés et contrôlés**. Un **StatefulSet** fournit exactement ces garanties, et il s'associe aux abstractions de stockage : une **PersistentVolumeClaim** est la demande de stockage côté application, un **PersistentVolume** est le volume réellement provisionné, et une **StorageClass** permet le provisioning dynamique — avec `volumeClaimTemplates` donnant à chaque Pod sa propre PVC/PV. Les mises en garde sont là où les ingénieurs senior justifient leur valeur : les **access modes** (RWO vs RWX et quels backends les supportent), le fait que supprimer un StatefulSet **préserve ses PVCs** par défaut, la **reclaim policy** qui gouverne le sort du PV, et — surtout — que Kubernetes fournit l'identité et le stockage mais que **la réplication et le clustering au niveau applicatif restent votre responsabilité**, souvent délégués à un Operator. Parce que la durabilité des données et le comportement stateful correct sont impitoyables (les erreurs signifient perte de données ou split-brain), maîtriser les StatefulSets, les PV/PVC et leurs mises en garde est fondamental pour faire tourner des bases de données et autres systèmes stateful de façon fiable sur Kubernetes.

Pourquoi les Deployments ne suffisent pas

Garanties du StatefulSet

Stockage persistant : PV, PVC, StorageClass

Un StatefulSet avec stockage par Pod

Access modes & mises en garde

Pourquoi c'est important

Questions connexes