Kubernetes 029 – Volumes : le HostPath

TL;DR

Un volume hostPath donne acces au filesystem du noeud. Il peut servir pour tester, lire des sockets ou deployer des agents techniques. Pour les donnees applicatives, il est rarement le bon choix car il lie le pod a un noeud et pose des risques de securite.

La video de reference

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

Elle presente un volume plus proche de la machine hote.

Exemple hostPath

apiVersion: v1
kind: Pod
metadata:
  name: demo-hostpath
spec:
  volumes:
    - name: host-data
      hostPath:
        path: /tmp/k8s-demo
        type: DirectoryOrCreate
  containers:
    - name: busybox
      image: busybox
      command: ["sh", "-c", "while true; do date >> /data/out; sleep 10; done"]
      volumeMounts:
        - name: host-data
          mountPath: /data

Le repertoire est sur le noeud ou le pod est planifie.

Consequence sur le scheduling

Si le pod est recree sur un autre noeud, il ne retrouve pas forcement les memes donnees. C’est le principal piege de hostPath pour une application.

Cas d’usage legitimes

• agents de log ou monitoring;
• acces a un socket local controle;
• labs de stockage;
• clusters mono-noeud de demonstration.

Risques

Monter des chemins sensibles du noeud peut donner trop de pouvoir au conteneur. Il faut limiter les chemins, les droits et les workloads autorises.

Commandes utiles

kubectl apply -f hostpath.yaml
kubectl get pod demo-hostpath -o wide
kubectl exec demo-hostpath -- tail /data/out
kubectl describe pod demo-hostpath

Liens utiles

• Video: https://www.youtube.com/watch?v=0KSOqB4nea0
• hostPath: https://kubernetes.io/docs/concepts/storage/volumes/#hostpath
• Volumes: https://kubernetes.io/docs/concepts/storage/volumes/
• Pod security: https://kubernetes.io/docs/concepts/security/pod-security-standards/

FAQ

hostPath persiste-t-il ?

Oui sur le noeud, mais pas de facon portable entre noeuds.

Peut-on utiliser hostPath en production ?

Oui pour certains agents systeme, mais rarement pour les donnees applicatives.

Pourquoi est-ce dangereux ?

Parce qu’un conteneur peut acceder a des fichiers du noeud selon le chemin monte.

Erreurs frequentes

• Stocker une base de donnees applicative dans hostPath sur un cluster multi-noeuds.
• Oublier que le pod peut changer de noeud.
• Monter / ou des chemins sensibles sans controle.
• Confondre hostPath et volume persistant portable.

Pour pratiquer

Sur un lab mono-noeud, creez un hostPath dans /tmp, ecrivez un fichier, supprimez le pod puis recreez-le sur le meme noeud. Comparez ensuite avec un cluster multi-noeuds si disponible.

hostPath et securite

hostPath peut donner a un pod une visibilite directe sur la machine hote. Selon le chemin monte et les droits du conteneur, cela peut devenir tres sensible. Monter un socket, un repertoire systeme ou un chemin de configuration peut permettre de lire ou modifier des elements critiques du noeud.

Quelques precautions:

• monter uniquement le chemin necessaire;
• preferer le readOnly quand l’ecriture n’est pas indispensable;
• eviter les pods privileges sans justification;
• reserver hostPath a des namespaces et workloads controles;
• documenter pourquoi ce montage est necessaire.

Lire le noeud choisi

Comme hostPath depend du noeud, il faut toujours regarder ou le pod tourne:

kubectl get pod demo-hostpath -o wide
kubectl describe pod demo-hostpath

Si le pod est recree ailleurs, le chemin /tmp/k8s-demo peut exister mais contenir d’autres donnees, ou ne pas exister du tout selon le type choisi. Cette dependance au noeud est exactement ce que PV/PVC cherchent a abstraire.

Comparaison rapide

| Volume | Portee | Usage typique |

|---|---|---|

| emptyDir | pod | cache, partage temporaire |

| hostPath | noeud | agent systeme, lab, socket local |

| NFS | reseau | partage entre pods ou noeuds |

| PVC | abstrait | demande de stockage portable |

Cette comparaison montre que hostPath n’est pas une solution generale de persistance. C’est un outil specifique, utile quand le lien avec le noeud est volontaire.

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 030 – Volumes : NFS, Network File System.

Conclusion

hostPath est utile pour comprendre le lien entre pod et noeud, mais il doit etre manipule avec prudence. Il prepare la transition vers des volumes plus propres comme NFS, PV et PVC.