Kubernetes 040 – Affinities : persistent volumes with nodeAffinity

TL;DR

Un PersistentVolume peut porter une nodeAffinity pour indiquer sur quel noeud le stockage existe reellement. C’est crucial avec les volumes locaux: le scheduler doit placer le pod sur le noeud capable de monter le volume. Sinon, le pod peut rester bloque ou etre place au mauvais endroit.

La video de reference

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

L’episode fait le lien entre stockage persistant, contraintes de noeuds et decisions du scheduler.

Pourquoi un volume a une affinite ?

Tous les stockages ne sont pas accessibles depuis tous les noeuds. Un disque local, un repertoire hote ou un volume attache a une machine ne peut pas etre monte n’importe ou.

La nodeAffinity du PersistentVolume indique a Kubernetes: ce volume est disponible seulement sur tel domaine de noeud.

Exemple de PersistentVolume local

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-local-1
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: /data/pv1
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
                - worker1

Ce volume ne doit etre utilise que sur le noeud worker1.

PVC associe

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-local
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: local-storage
  resources:
    requests:
      storage: 5Gi

Le PVC demande du stockage. Kubernetes le lie a un PV compatible selon la capacite, les modes d’acces, le StorageClass et d’autres criteres.

Pod consommateur

apiVersion: v1
kind: Pod
metadata:
  name: app-local
spec:
  containers:
    - name: app
      image: busybox
      command: ["sh", "-c", "sleep 3600"]
      volumeMounts:
        - name: data
          mountPath: /data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: pvc-local

Le pod ne declare pas directement le noeud. Le scheduler tient compte du volume lie au PVC.

Role du scheduler

Quand un pod reference un PVC, Kubernetes doit eviter de le placer sur un noeud incompatible avec le PV. Avec un volume local, cette coordination est indispensable.

Sans cette information, on obtiendrait un pod qui ne peut pas monter son stockage.

StorageClass et binding

Pour les volumes locaux, le mode WaitForFirstConsumer est souvent important. Il retarde le binding du PVC jusqu’a ce qu’un pod consommateur existe, afin de prendre le scheduling en compte.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

Ce mode evite certains choix trop tot dans le cycle de vie du PVC.

Commandes de verification

kubectl get pv
kubectl get pvc
kubectl describe pv pv-local-1
kubectl describe pvc pvc-local
kubectl get pod app-local -o wide

La colonne NODE du pod doit correspondre a la contrainte du volume.

Liens utiles

• Video: https://www.youtube.com/watch?v=UTfdoXmRevU
• Playlist Kubernetes v2: https://www.youtube.com/playlist?list=PLn6POgpklwWo6wiy2G3SjBubF6zXjksap
• Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
• Persistent Volumes: https://kubernetes.io/docs/concepts/storage/persistent-volumes/
• Local persistent volumes: https://kubernetes.io/docs/concepts/storage/volumes/#local

FAQ

Pourquoi utiliser Retain ?

Pour eviter une suppression automatique des donnees quand le PVC disparait. Cela demande ensuite un nettoyage manuel.

Un volume local est-il hautement disponible ?

Non. Si le noeud tombe, le volume local tombe avec lui.

nodeAffinity du PV remplace-t-elle nodeAffinity du pod ?

Non. Elle decrit la contrainte du stockage. Le pod peut aussi avoir ses propres contraintes.

Erreurs frequentes

• Creer un PV local sans nodeAffinity.
• Utiliser un hostname qui ne correspond pas au label reel du noeud.
• Oublier de creer le repertoire local sur le noeud.
• Confondre stockage local et stockage distribue.

Pour pratiquer

Creez deux PV locaux sur deux workers, puis observez quel noeud est choisi pour un pod consommateur. Modifiez ensuite le hostname du PV pour provoquer une erreur de scheduling.

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 041 – StatefulSets : principe, fonctionnement et demo.

Conclusion

Les volumes persistants locaux obligent a penser ensemble stockage et scheduling. La nodeAffinity du PV rend cette dependance explicite et evite des placements impossibles.