Stockage Kubernetes : PV, PVC, StorageClass et CSI

Votre Pod redémarre et perd toutes ses données. Votre PVC reste bloqué en Pending. Vous ne comprenez pas pourquoi votre volume n’est pas accessible depuis un autre nœud. Ces situations sont fréquentes quand on découvre le stockage Kubernetes.

Ce guide vous donne les bases essentielles pour comprendre et manipuler le stockage dans Kubernetes : la relation entre Pod, PVC, PV et StorageClass, les access modes, les reclaim policies, et comment diagnostiquer les problèmes courants.

Domaine CKA — Storage (10%)

Ce guide couvre les compétences du domaine Storage de la certification CKA :

• Comprendre les concepts de stockage : PV, PVC, StorageClass
• Configurer les access modes et reclaim policies
• Implémenter le provisionnement statique et dynamique
• Diagnostiquer un PVC qui ne se lie pas

Prérequis

• Savoir créer un Pod avec kubectl
• Notions de base sur les ressources Kubernetes

Pourquoi le stockage est particulier dans Kubernetes

Dans un environnement traditionnel, vos applications stockent leurs données sur des disques locaux stables. Dans Kubernetes, les Pods sont éphémères : ils peuvent être détruits, recréés et déplacés sur d’autres nœuds à tout moment.

Se posent alors trois questions :

1. Comment préserver les données quand un Pod disparaît ?
2. Comment partager du stockage entre plusieurs Pods ?
3. Comment rendre le stockage portable d’un nœud à l’autre ?

Kubernetes répond à ces questions avec un modèle en couches : volumes éphémères pour les données temporaires, et stockage persistant (PV/PVC) pour les données qui doivent survivre aux Pods.

Le modèle mental : Pod → PVC → PV → StorageClass

Avant d’entrer dans les détails, voici le schéma mental que vous devez avoir :

En résumé :

• Le Pod monte un PVC (PersistentVolumeClaim)
• Le PVC réclame un PV (PersistentVolume)
• Le PV peut être créé statiquement par un admin, ou dynamiquement via une StorageClass
• CSI (Container Storage Interface) est l’interface standard entre Kubernetes et le backend de stockage

Volumes éphémères : emptyDir et hostPath

Avant le stockage persistant, voyons les volumes éphémères — ceux dont les données ne survivent pas au Pod.

emptyDir : stockage temporaire dans le Pod

Un volume emptyDir est créé quand le Pod démarre et supprimé quand le Pod est détruit. Il permet aux conteneurs d’un même Pod de partager des fichiers.

Survit aux redémarrages de conteneur, pas du Pod

emptyDir survit aux redémarrages de conteneur dans le même Pod. Mais si le Pod est supprimé ou reschedulé sur un autre nœud, les données disparaissent.

Cas d’usage :

• Cache temporaire
• Partage de fichiers entre conteneurs d’un même Pod
• Répertoire de travail pour des calculs intermédiaires

apiVersion: v1
kind: Pod
metadata:
  name: emptydir-demo
spec:
  containers:
    - name: app
      image: busybox
      command: ["sleep", "3600"]
      volumeMounts:
        - mountPath: /data
          name: temp-storage
  volumes:
    - name: temp-storage
      emptyDir: {}

hostPath : accès au filesystem du nœud

Le volume hostPath monte un répertoire du nœud hôte dans le Pod. Il donne accès direct au système de fichiers du nœud.

hostPath n'est PAS du stockage persistant portable

• Si le Pod est reschedulé sur un autre nœud, les données ne suivent pas
• Pose des problèmes de sécurité (accès au filesystem du nœud)
• À réserver pour des cas très spécifiques : logs système, accès à des devices, tests locaux
• Jamais en production pour du stockage applicatif

Cas d’usage limités :

• Accéder aux logs du nœud (/var/log)
• Monter un socket Docker ou containerd
• Tests locaux en développement

apiVersion: v1
kind: Pod
metadata:
  name: hostpath-demo
spec:
  containers:
    - name: app
      image: busybox
      command: ["sleep", "3600"]
      volumeMounts:
        - mountPath: /host-logs
          name: host-storage
  volumes:
    - name: host-storage
      hostPath:
        path: /var/log
        type: Directory

Stockage persistant : PV, PVC et StorageClass

Le stockage persistant permet de conserver les données même après la suppression du Pod. C’est le cœur du domaine Storage de la CKA.

PersistentVolume (PV)

Un PersistentVolume représente un volume de stockage réel dans le cluster. Il est créé soit :

• Statiquement par un administrateur
• Dynamiquement par une StorageClass

Le PV contient les informations techniques : capacité, access modes, reclaim policy, et les détails du backend de stockage.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: manual
  hostPath:
    path: /mnt/data

PersistentVolumeClaim (PVC)

Un PersistentVolumeClaim est une demande de stockage faite par un utilisateur. Le PVC spécifie :

• La capacité souhaitée
• L’access mode requis
• Optionnellement, une StorageClass

Kubernetes lie automatiquement le PVC à un PV compatible.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-example
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: manual

StorageClass

Une StorageClass définit comment provisionner dynamiquement des volumes. Elle spécifie :

• Le provisioner (driver CSI ou in-tree)
• Les paramètres du backend (type de disque, IOPS, etc.)
• La reclaim policy par défaut
• Le volumeBindingMode

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-ssd
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

StorageClass par défaut

Un cluster a généralement une StorageClass par défaut (annotée storageclass.kubernetes.io/is-default-class: "true"). Si un PVC ne spécifie pas de storageClassName, il utilise cette classe par défaut.

Vérifiez avec : kubectl get storageclass

Access modes : qui peut accéder au volume ?

Les access modes définissent comment un volume peut être monté par les nœuds et les Pods. C’est un point central pour la CKA.

Access mode	Abréviation	Signification	Cas d’usage typique
ReadWriteOnce	RWO	Lecture/écriture depuis un seul nœud	DB mono-instance, app stateful
ReadOnlyMany	ROX	Lecture seule depuis plusieurs nœuds	Assets statiques partagés
ReadWriteMany	RWX	Lecture/écriture depuis plusieurs nœuds	Stockage partagé (NFS, CephFS)
ReadWriteOncePod	RWOP	Lecture/écriture depuis un seul Pod	Apps nécessitant un writer unique strict

Glissez pour voir

RWO ≠ un seul Pod

Attention à cette confusion fréquente : ReadWriteOnce signifie un seul nœud, pas un seul Pod. Plusieurs Pods sur le même nœud peuvent accéder au volume en RWO.

Pour garantir l’accès depuis un seul Pod, utilisez ReadWriteOncePod (stable depuis K8s 1.29, uniquement avec CSI).

Support des access modes selon le backend

Tous les backends ne supportent pas tous les access modes :

Backend	RWO	ROX	RWX	RWOP
AWS EBS	✅	❌	❌	✅
GCE PD	✅	✅	❌	✅
Azure Disk	✅	❌	❌	✅
NFS	✅	✅	✅	❌
CephFS	✅	✅	✅	✅

Glissez pour voir

Reclaim policies : que faire quand le PVC est supprimé ?

La reclaim policy définit ce qui arrive au PV (et au stockage sous-jacent) quand le PVC qui l’utilise est supprimé.

Reclaim Policy	Effet	Usage
Delete	Le PV et le stockage backend sont supprimés	Environnements cloud, données non critiques
Retain	Le PV est conservé (statut Released), données préservées	Données critiques, reprise manuelle
Recycle	Déprécié — Effacement basique (rm -rf /volume/*)	Ne plus utiliser

Glissez pour voir

Delete = Perte de données

Avec reclaimPolicy: Delete, supprimer le PVC supprime aussi les données sur le backend. Utilisez Retain pour les données critiques.

Changer la reclaim policy d’un PV existant

kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

volumeBindingMode : quand lier le PVC au PV ?

Le volumeBindingMode d’une StorageClass contrôle quand le binding PVC → PV se produit.

Mode	Comportement	Quand l’utiliser
Immediate	Le PV est créé/lié dès la création du PVC	Stockage sans contrainte de topologie
WaitForFirstConsumer	Le binding attend qu’un Pod consomme le PVC	Stockage zonal (EBS, GCE PD), scheduling-aware

Glissez pour voir

WaitForFirstConsumer = meilleur pour le scheduling

Avec WaitForFirstConsumer, Kubernetes connaît le nœud cible avant de provisionner le volume. Cela évite de créer un volume dans une zone où aucun Pod ne peut tourner.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: zonal-storage
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer

Provisionnement statique vs dynamique

Provisionnement statique

L’administrateur crée manuellement les PV avant que les utilisateurs créent leurs PVC.

1. Admin crée le PV

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: static-pv
   spec:
     capacity:
       storage: 50Gi
     accessModes:
       - ReadWriteOnce
     persistentVolumeReclaimPolicy: Retain
     storageClassName: manual
     nfs:
       server: nfs.example.com
       path: /exports/data

2. Utilisateur crée le PVC

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: my-pvc
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 50Gi
     storageClassName: manual

3. Kubernetes lie PVC → PV

   Le PVC passe en status Bound.

Avantages : Contrôle total, pas de dépendance au provisioner.

Inconvénients : Manuel, ne scale pas, risque de sur/sous-provisionnement.

Provisionnement dynamique

Kubernetes crée automatiquement les PV à la demande, via une StorageClass et un driver CSI.

1. StorageClass existe

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: fast
   provisioner: csi.example.com
   parameters:
     type: ssd

2. Utilisateur crée le PVC

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: dynamic-pvc
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 20Gi
     storageClassName: fast

3. CSI provisionne automatiquement le PV

   Le driver CSI crée le volume sur le backend et le PV dans Kubernetes.

Avantages : Automatique, scalable, moins d’erreurs humaines.

Inconvénients : Dépendance au driver CSI, debugging plus complexe.

CSI : l’interface standard de stockage

CSI (Container Storage Interface) est l’interface standard pour intégrer des solutions de stockage à Kubernetes. C’est le mécanisme derrière les StorageClasses modernes.

Architecture CSI

Un driver CSI se compose de :

• Controller Plugin : Gère les opérations au niveau du cluster (création/suppression de volumes, attachement aux nœuds)
• Node Plugin : Gère les opérations sur chaque nœud (montage/démontage du volume dans le Pod)

Ces plugins communiquent avec Kubernetes via gRPC.

Fonctionnalités avancées CSI

Selon le driver, CSI permet :

• Provisionnement dynamique
• Snapshots de volumes
• Clonage de volumes
• Expansion de volumes (allowVolumeExpansion: true)
• Topologie (placement zone-aware)

Liste des drivers CSI

Consultez la liste officielle des drivers CSI : kubernetes-csi.github.io/docs/drivers.html

Dépannage : pourquoi mon PVC reste en Pending ?

Un PVC en Pending est un problème classique. Voici les causes les plus fréquentes :

Checklist de diagnostic

Cause	Vérification	Solution
Pas de StorageClass par défaut	kubectl get sc	Créer une SC par défaut ou spécifier storageClassName
StorageClass inexistante	kubectl get sc <nom>	Créer la StorageClass ou corriger le nom
Aucun PV statique compatible	kubectl get pv	Créer un PV avec capacité/access mode compatibles
Capacité demandée trop grande	kubectl describe pvc	Réduire la demande ou créer un PV plus grand
Access mode non supporté	kubectl describe pvc	Vérifier le support du backend
Driver CSI non fonctionnel	kubectl get pods -n kube-system	Vérifier les pods du driver CSI
WaitForFirstConsumer actif	kubectl describe pvc	Créer un Pod qui consomme le PVC

Glissez pour voir

Commandes de diagnostic

# Lister les ressources de stockage
kubectl get pv
kubectl get pvc -A
kubectl get storageclass

# Inspecter un PVC
kubectl describe pvc <nom>

# Inspecter un PV
kubectl describe pv <nom>

# Voir les événements récents
kubectl get events -A --sort-by=.lastTimestamp | grep -i pvc

# Vérifier les pods CSI
kubectl get pods -n kube-system | grep csi

Exemple de diagnostic

$ kubectl describe pvc my-pvc
Name:          my-pvc
Namespace:     default
Status:        Pending
...
Events:
  Type     Reason              Message
  ----     ------              -------
  Warning  ProvisioningFailed  storageclass.storage.k8s.io "nonexistent" not found

Diagnostic : La StorageClass nonexistent n’existe pas.

Solution : Corriger le storageClassName dans le PVC ou créer la StorageClass.

Exemple complet : Pod + PVC + StorageClass

Voici un exemple fonctionnel avec provisionnement dynamique :

# 1. StorageClass (à adapter selon votre environnement)
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: rancher.io/local-path  # Exemple avec local-path-provisioner
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
---
# 2. PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: standard
---
# 3. Pod qui utilise le PVC
apiVersion: v1
kind: Pod
metadata:
  name: app-with-storage
spec:
  containers:
    - name: app
      image: nginx:alpine
      volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: app-data

Appliquez et vérifiez :

kubectl apply -f storage-example.yaml
kubectl get pvc app-data
kubectl get pv
kubectl describe pod app-with-storage

À retenir

Les 5 points essentiels de ce guide :

• Pod → PVC → PV → StorageClass : c’est le modèle mental à avoir pour comprendre le stockage Kubernetes
• Access modes : RWO = un seul nœud, RWX = plusieurs nœuds, RWOP = un seul Pod
• Reclaim policies : Delete supprime les données, Retain les conserve
• Provisionnement dynamique via StorageClass + CSI est le mode moderne
• Un PVC en Pending = vérifier StorageClass, capacité, access mode, et driver CSI

Testez vos connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Prochaines étapes

StorageClass en détail

Approfondissez les paramètres des StorageClasses et le provisionnement dynamique Lire le guide StorageClass

Exercices CKA Storage

Pratiquez avec des exercices format examen sur le stockage Voir les exercices CKA

Backup et restauration

Apprenez à sauvegarder vos données avec Velero Lire le guide backup

etcd et persistance

Comprenez le stockage du control plane Lire le guide etcd

×

📖 Voir la documentation →