Kubernetes 032 – PV, PVC et StorageClass : demo hostPath et NFS

TL;DR

Un PV statique peut pointer vers un hostPath ou un export NFS. Un PVC demande ensuite une taille et un mode d’acces. Kubernetes lie le PVC a un PV compatible. Cette demo montre la mecanique avant le provisionnement dynamique.

La video de reference

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

Elle applique les concepts PV/PVC sur des cas concrets.

PV hostPath de lab

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-hostpath
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /tmp/pv-hostpath
  persistentVolumeReclaimPolicy: Retain

Ce cas est utile en mono-noeud, mais il garde les limites de hostPath.

PVC associe

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: claim-data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi

Kubernetes cherche un PV compatible avec cette demande.

PV NFS

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.1.50
    path: /exports/kubernetes
  persistentVolumeReclaimPolicy: Retain

NFS peut supporter des montages multi-pods selon la configuration et l’application.

Observer le binding

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

Le statut attendu est Bound.

Utiliser dans un pod

volumes:
  - name: data
    persistentVolumeClaim:
      claimName: claim-data

Le pod ne connait pas hostPath ou NFS. Il connait seulement le PVC.

Liens utiles

• Video: https://www.youtube.com/watch?v=1HrHv_HBxwI
• Persistent Volumes: https://kubernetes.io/docs/concepts/storage/persistent-volumes/
• NFS volumes: https://kubernetes.io/docs/concepts/storage/volumes/#nfs
• hostPath: https://kubernetes.io/docs/concepts/storage/volumes/#hostpath

FAQ

Pourquoi mon PVC ne se lie pas ?

Verifier taille, accessModes, storageClassName et disponibilite des PV.

Peut-on lier explicitement un PVC a un PV ?

Oui avec certains champs comme volumeName, mais ce n’est pas le cas le plus souple.

hostPath est-il un bon backend pour PV ?

Pour un lab, oui. Pour une production multi-noeuds, rarement.

Erreurs frequentes

• Oublier storageClassName quand on veut eviter la StorageClass par defaut.
• Demander ReadWriteMany a un PV qui ne le fournit pas.
• Supprimer un PVC sans savoir quoi faire des donnees retenues.
• Utiliser hostPath en pensant avoir un stockage distribue.

Pour pratiquer

Creez un PV hostPath, un PVC, puis un pod qui ecrit dans /data. Supprimez le pod, recreez-le et observez si les donnees restent accessibles dans votre lab.

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 033 – Dynamic Provisioner : exemple avec NFS.

Conclusion

Cette demo rend concret le contrat PV/PVC. Le pod consomme une demande de stockage, pendant que l’administrateur ou le provisioner gere le backend.