Aller au contenu

Module 3b · Stockage persistant

Objectifs

  • Comprendre la différence éphémère vs persistant dans Kubernetes.
  • Manipuler PV, PVC et StorageClass — et voir comme c'est lié.
  • Monter un volume dans un pod et prouver que la donnée survit au redémarrage.
  • Durée : ~2 h · Pré-requis : Module 3.

1. Le problème : un pod est jetable

Par défaut, le système de fichiers d'un conteneur disparaît quand le pod est recréé. Pour une base de données, un upload, un cache durable… il faut du stockage persistant, découplé du cycle de vie du pod.

graph LR
    P[Pod] -->|monte| PVC[PersistentVolumeClaim]
    PVC -->|lié à| PV[PersistentVolume]
    SC[StorageClass] -->|provisionne dynamiquement| PV

2. Les trois objets

Objet Rôle Analogie
StorageClass Comment provisionner du stockage (le « type » de disque) le catalogue
PersistentVolume (PV) Un morceau de stockage réel, dans le cluster le disque
PersistentVolumeClaim (PVC) Une demande de stockage par l'app le bon de commande

En pratique : l'app crée un PVC → la StorageClass provisionne dynamiquement un PV → le pod monte le PVC.

bash kubectl get storageclass # k9s : :sc kubectl get pv # k9s : :pv kubectl get pvc # k9s : :pvc

Dans ta sandbox

Le vcluster expose une StorageClass par défaut (souvent local-path). Vérifie avec kubectl get sc : celle marquée (default) est utilisée si un PVC ne précise rien.

3. Réclamer du stockage — un PVC

yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: donnees spec: accessModes: ["ReadWriteOnce"] # monté en R/W par un seul nœud à la fois resources: requests: storage: 1Gi

bash kubectl apply -f pvc.yaml kubectl get pvc donnees # STATUS doit passer à "Bound"

Access modes

  • ReadWriteOnce (RWO) : un nœud en lecture/écriture (cas le plus courant).
  • ReadOnlyMany (ROX) / ReadWriteMany (RWX) : plusieurs nœuds (besoin d'un backend qui le supporte, ex. NFS).

4. Monter le PVC dans un pod

yaml apiVersion: v1 kind: Pod metadata: name: ecrivain spec: containers: - name: app image: busybox command: ["sh", "-c", "echo coucou >> /data/journal.txt && sleep 3600"] volumeMounts: - name: vol mountPath: /data volumes: - name: vol persistentVolumeClaim: claimName: donnees

5. StatefulSet (pour les apps à état)

Un Deployment est fait pour des pods interchangeables. Une base de données a besoin d'une identité stable et d'un volume dédié par réplica : c'est le rôle du StatefulSet, via son volumeClaimTemplates (un PVC créé automatiquement par pod).

bash :sts # vue StatefulSets dans k9s

6. Exercices

Exercice 3b.1 — La donnée survit

  1. Crée le PVC et le pod ecrivain ci-dessus.
  2. kubectl exec ecrivain -- cat /data/journal.txt → note le contenu.
  3. Supprime le pod (Ctrl-d dans k9s) sans supprimer le PVC, recrée-le.
  4. Relis /data/journal.txt : la ligne est toujours là. La donnée a survécu. ✅

Exercice 3b.2 — Plein le disque

  1. Crée un PVC de 100Mi.
  2. Dans le pod, dd if=/dev/zero of=/data/gros bs=1M count=200 (dépasse la demande).
  3. Observe : selon le backend, l'écriture échoue ou non — discute la différence entre demande (request) et limite réelle du backend de stockage.

7. Ce qu'il faut retenir

  • PVC = demande, PV = disque réel, StorageClass = comment le fabriquer.
  • Une StorageClass par défaut permet le provisioning dynamique (pas de PV à créer à la main).
  • Supprimer le pod ne supprime pas la donnée ; supprimer le PVC (selon la reclaimPolicy) si.
  • Apps à état → StatefulSet + volumeClaimTemplates.

➡️ Suite : Module 3c — Observabilité