Kubernetes 031 – PV, PVC et StorageClass : dynamic provisioning

TL;DR

Un PersistentVolume represente un volume disponible. Un PersistentVolumeClaim est une demande de stockage faite par une application. Une StorageClass decrit comment provisionner dynamiquement des volumes. Cette separation rend le stockage plus portable.

La video de reference

Video: https://www.youtube.com/watch?v=cfKwoAkY3F8

Elle pose les concepts clefs du stockage persistant Kubernetes.

Les trois objets

PV est la ressource de stockage. PVC est la demande consommee par un pod. StorageClass indique au cluster comment creer un PV automatiquement si un provisioner existe.

Cette separation evite de mettre les details NFS, cloud ou hostpath directement dans chaque pod.

Exemple PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Utiliser le PVC dans un pod

volumes:
  - name: data
    persistentVolumeClaim:
      claimName: data
containers:
  - name: app
    image: busybox
    volumeMounts:
      - name: data
        mountPath: /data

AccessModes

ReadWriteOnce signifie que le volume peut etre monte en lecture-ecriture par un noeud. ReadOnlyMany et ReadWriteMany dependent du backend. Il ne faut pas supposer qu’un mode est disponible partout.

StorageClass

kubectl get storageclass
kubectl describe storageclass <nom>

Une StorageClass par defaut peut etre utilisee automatiquement par les PVC qui ne precisent pas storageClassName.

Dynamic provisioning

Avec un provisioner, la creation d’un PVC peut entrainer la creation automatique d’un PV. Sans provisioner, il faut souvent creer le PV a la main.

Liens utiles

• Video: https://www.youtube.com/watch?v=cfKwoAkY3F8
• Persistent Volumes: https://kubernetes.io/docs/concepts/storage/persistent-volumes/
• StorageClasses: https://kubernetes.io/docs/concepts/storage/storage-classes/
• CSI: https://kubernetes.io/docs/concepts/storage/volumes/#csi

FAQ

PVC ou PV dans le manifest applicatif ?

L’application reference le PVC. Le PV est plutot fourni par l’infrastructure.

Pourquoi mon PVC reste Pending ?

Pas de PV compatible, pas de StorageClass par defaut ou provisioner en erreur.

Un PVC supprime-t-il les donnees ?

Cela depend de la reclaim policy du PV ou de la StorageClass.

Erreurs frequentes

• Confondre taille demandee et taille reellement disponible.
• Ignorer storageClassName.
• Supposer que ReadWriteMany fonctionne sur tous les backends.
• Supprimer un PVC sans connaitre la reclaim policy.

Pour pratiquer

kubectl get storageclass
kubectl apply -f pvc.yaml
kubectl get pvc,pv
kubectl describe pvc data

Observez si le PVC passe en Bound et quel PV lui est associe.

Notions et definitions

• Volume: point de montage rendu disponible dans un conteneur.
• PVC: demande de stockage exprimee par une application.
• PV et StorageClass: ressource de stockage et mecanisme de provisionnement associe.

Ces definitions donnent le vocabulaire minimal pour suivre l’article sans reduire Kubernetes a une simple commande. Chaque notion doit etre reliee a un objet visible avec kubectl ou a un composant du cluster.

Exemple concret

Une base de donnees dans un pod ne doit pas dependre du filesystem ephemere du conteneur; elle utilise un PVC pour retrouver ses donnees apres recreation du pod.

Cet exemple sert de fil conducteur: il montre quel probleme operationnel Kubernetes cherche a resoudre et quelle ressource permet de le formaliser.

How-to rapide

• Identifier si le besoin est ephemere, partage ou persistant.
• Creer un PVC adapte en taille et en mode d’acces.
• Monter ce PVC dans le pod ou le workload.
• Tester la persistence en supprimant puis recreant le pod.

Le how-to est volontairement court: l’idee est d’obtenir un resultat observable, puis d’utiliser les commandes de verification pour comprendre ce qui s’est passe.

Approfondir cet article

Cet episode doit surtout permettre de maitriser la difference entre stockage ephemere, volume attache au pod, volume persistant et provisionnement dynamique. L’objectif n’est pas seulement de refaire les commandes, mais de comprendre quel objet Kubernetes est cree, quel composant le prend en charge et comment verifier le resultat.

Questions a se poser

• Quel est l’etat desire exprime dans Kubernetes ?
• Quel composant observe cet etat et tente de le reconciler ?
• Quels symptomes montrent que l’objet est cree mais pas encore operationnel ?
• Quelle commande donne l’information la plus fiable pour diagnostiquer ?

Commandes de verification

• kubectl get pv,pvc,storageclass -o wide
• kubectl describe pvc <pvc> pour suivre les evenements de binding
• kubectl describe pod <pod> pour verifier les montages et les erreurs de volume

Ces commandes ne sont pas a apprendre par coeur. Elles servent a construire un reflexe: partir de l’objet Kubernetes, lire son etat, puis descendre vers les pods, les events, les logs ou le noeud uniquement si c’est necessaire.

Points de vigilance

• penser qu’un volume persistant resout automatiquement les sauvegardes
• melanger les responsabilites entre PVC, PV et StorageClass
• utiliser hostPath comme solution de production alors qu’il depend fortement du noeud

Exercice conseille

Creez un PVC, montez-le dans un pod de test, ecrivez un fichier, supprimez le pod, puis relancez-le pour verifier ce qui persiste vraiment.

Pour valider la comprehension, gardez une trace courte: manifest utilise, commandes lancees, resultat attendu, resultat observe et correction appliquee. Cette methode rend les episodes suivants beaucoup plus faciles a enchainer.

Lien interne conseille

Pour poursuivre la progression, consultez aussi Kubernetes 032 – PV, PVC et StorageClass : demo hostPath et NFS.

Conclusion

PV, PVC et StorageClass donnent un modele propre pour le stockage persistant. L’application demande un besoin, l’infrastructure fournit une implementation.