Kubernetes 033 – Dynamic Provisioner : exemple avec NFS

TL;DR

Le dynamic provisioning evite de creer chaque PV a la main. Une StorageClass reference un provisioner. Quand un PVC compatible est cree, le provisioner cree le stockage necessaire, souvent un repertoire dedie sur un export NFS dans cet exemple.

La video de reference

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

Elle montre une mise en pratique du provisionnement dynamique avec NFS.

Pourquoi un provisioner ?

Creer des PV statiques devient vite penible. Pour chaque application, il faudrait preparer un chemin, un PV, une taille et des droits. Le provisioner automatise cette partie.

L’utilisateur cree un PVC. Le cluster cree le volume correspondant via la StorageClass.

StorageClass

Un exemple simplifie ressemble a ceci, selon le provisioner installe:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-client
provisioner: example.com/nfs
reclaimPolicy: Delete
volumeBindingMode: Immediate

Le nom exact du provisioner depend de l’implementation deployee.

PVC dynamique

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  storageClassName: nfs-client
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

Apres creation, un PV est genere automatiquement si tout fonctionne.

Observer

kubectl get storageclass
kubectl apply -f pvc.yaml
kubectl get pvc,pv
kubectl describe pvc data
kubectl get pods -n <namespace-du-provisioner>

Les logs du provisioner sont essentiels en cas de blocage.

Points d’attention NFS

Le serveur NFS reste un composant critique. Il faut gerer disponibilite, sauvegarde, permissions et performance. Le provisioner ne transforme pas NFS en stockage parfait.

Liens utiles

• Video: https://www.youtube.com/watch?v=Mz5d8Miphso
• Dynamic volume provisioning: https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/
• StorageClasses: https://kubernetes.io/docs/concepts/storage/storage-classes/
• Persistent Volumes: https://kubernetes.io/docs/concepts/storage/persistent-volumes/

FAQ

Le provisioner stocke-t-il les donnees ?

Non, il orchestre la creation. Les donnees restent sur le backend, ici NFS.

Pourquoi mon PVC reste Pending ?

Verifier la StorageClass, le provisioner, ses logs, les droits NFS et les events.

reclaimPolicy: Delete supprime-t-il les fichiers ?

Selon le provisioner, il peut supprimer le volume ou le repertoire associe. Il faut tester avant production.

Erreurs frequentes

• Installer une StorageClass sans verifier le provisioner.
• Oublier les permissions sur l’export NFS.
• Utiliser Delete sans comprendre l’impact sur les donnees.
• Croire que RWX signifie absence de problemes de concurrence applicative.

Pour pratiquer

Creez deux PVC avec la meme StorageClass et observez les PV generes. Montez ensuite un PVC dans un pod et ecrivez un fichier pour verifier le chemin cree cote NFS.

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 034 – Volumes : TP WordPress partie 1.

Conclusion

Le provisionnement dynamique rend le stockage beaucoup plus fluide pour les equipes applicatives. Il deplace toutefois la responsabilite vers la StorageClass, le provisioner et le backend.