Kubernetes 030 – Volumes : NFS, Network File System

TL;DR

Un volume NFS reference un serveur et un chemin exporte. Contrairement a hostPath, les donnees ne sont pas liees a un noeud Kubernetes. C’est pratique en lab et pour certains usages partages, mais il faut comprendre les limites de performance, verrouillage et securite.

La video de reference

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

Elle introduit un stockage reseau avant les objets PV et PVC.

Principe

NFS est un systeme de fichiers partage sur le reseau. Kubernetes peut monter un export NFS dans un pod si les noeuds peuvent joindre le serveur et si les droits sont corrects.

Exemple de pod

apiVersion: v1
kind: Pod
metadata:
  name: demo-nfs
spec:
  volumes:
    - name: nfs-data
      nfs:
        server: 192.168.1.50
        path: /exports/kubernetes
  containers:
    - name: app
      image: busybox
      command: ["sh", "-c", "while true; do date >> /data/out; sleep 10; done"]
      volumeMounts:
        - name: nfs-data
          mountPath: /data

Pre-requis

Les noeuds doivent pouvoir resoudre et joindre le serveur NFS. Les paquets clients NFS doivent etre presents selon la distribution. Les exports doivent autoriser les IP des noeuds.

Tester

kubectl apply -f nfs-pod.yaml
kubectl get pod demo-nfs -o wide
kubectl exec demo-nfs -- ls -l /data
kubectl describe pod demo-nfs

En cas d’echec de montage, describe pod et les events sont les premiers reflexes.

Limites

NFS n’est pas magique. Selon l’application, les performances, la concurrence d’ecriture et les permissions peuvent poser probleme. Toutes les bases de donnees ne se satisfont pas d’un partage NFS simple.

Liens utiles

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

FAQ

NFS rend-il les donnees persistantes ?

Oui tant que le serveur NFS conserve les fichiers et que le chemin est le meme.

Peut-on monter le meme NFS dans plusieurs pods ?

Oui, mais l’application doit supporter les acces concurrents.

Pourquoi utiliser PV/PVC ensuite ?

Pour separer la demande de stockage de son implementation concrete.

Erreurs frequentes

• Oublier d’autoriser les noeuds dans l’export NFS.
• Ne pas verifier les permissions UID/GID.
• Utiliser NFS pour une application qui gere mal les acces concurrents.
• Mettre l’IP NFS partout au lieu de passer ensuite par PV/PVC.

Pour pratiquer

Montez le meme export NFS dans deux pods de test et verifiez qu’un fichier ecrit par l’un est visible par l’autre. Cela montre la difference avec emptyDir et hostPath.

Diagnostiquer un montage NFS en erreur

Quand un pod reste bloque a cause d’un volume NFS, les logs applicatifs ne sont pas utiles: l’application n’a parfois meme pas demarre. Il faut lire les events du pod:

kubectl describe pod demo-nfs
kubectl get events --sort-by=.lastTimestamp

Les causes classiques sont simples: serveur injoignable, export mal declare, droits insuffisants, client NFS absent sur le noeud, pare-feu ou probleme de resolution DNS.

NFS direct ou PV/PVC ?

Monter NFS directement dans un pod est pedagogique, mais cela couple le manifest applicatif a l’adresse du serveur et au chemin exporte. Avec PV/PVC, on separe mieux les responsabilites: l’administrateur de plateforme decrit le stockage disponible, l’application demande un volume.

Cette separation rend les manifests applicatifs plus portables. Elle permet aussi de faire evoluer l’implementation du stockage sans modifier partout les pods ou deployments.

Points de vigilance en production

NFS peut etre utile, mais il faut traiter plusieurs sujets avant un usage serieux:

• disponibilite du serveur NFS;
• sauvegarde des donnees;
• permissions UID/GID;
• performances et latence reseau;
• comportement de l’application en acces concurrents;
• supervision du serveur et de l’espace disque.

Kubernetes sait monter le volume, mais il ne garantit pas a lui seul que le serveur NFS est robuste ou adapte a l’application.

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 031 – PV, PVC et StorageClass : dynamic provisioning.

Conclusion

NFS introduit le stockage reseau dans Kubernetes. C’est une bonne etape pedagogique avant d’abstraire le stockage avec PersistentVolume, PersistentVolumeClaim et StorageClass.