Kubernetes 028 – Volumes : principes et emptyDir

TL;DR

Un volume est declare au niveau du pod puis monte dans un ou plusieurs conteneurs. emptyDir cree un repertoire vide pour la duree de vie du pod. Il survit aux redemarrages de conteneurs dans le meme pod, mais disparait quand le pod est supprime.

La video de reference

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

Elle introduit le stockage Kubernetes avant hostPath, NFS, PV et PVC.

Pourquoi des volumes ?

Le filesystem d’un conteneur est lie au conteneur. Si le conteneur redemarre, certaines donnees peuvent etre perdues selon le cas. Kubernetes fournit des volumes pour partager des fichiers entre conteneurs ou connecter un stockage externe.

emptyDir

emptyDir est cree quand le pod est assigne a un noeud. Il est vide au depart et reste disponible tant que le pod existe sur ce noeud.

apiVersion: v1
kind: Pod
metadata:
  name: demo-emptydir
spec:
  volumes:
    - name: cache
      emptyDir: {}
  containers:
    - name: app
      image: busybox
      command: ["sh", "-c", "while true; do date >> /cache/out; sleep 5; done"]
      volumeMounts:
        - name: cache
          mountPath: /cache

Partage entre conteneurs

Un meme volume peut etre monte dans plusieurs conteneurs du meme pod. C’est utile pour un sidecar qui lit ou ecrit des fichiers produits par le conteneur principal.

Tester

kubectl apply -f emptydir.yaml
kubectl exec demo-emptydir -- tail /cache/out
kubectl delete pod demo-emptydir

Apres suppression du pod, le contenu du emptyDir disparait.

Liens utiles

• Video: https://www.youtube.com/watch?v=dWUHBu2oHlg
• Volumes: https://kubernetes.io/docs/concepts/storage/volumes/
• emptyDir: https://kubernetes.io/docs/concepts/storage/volumes/#emptydir
• Pods: https://kubernetes.io/docs/concepts/workloads/pods/

FAQ

emptyDir est-il persistant ?

Non. Il vit avec le pod.

Peut-on l’utiliser pour du cache ?

Oui, c’est un cas classique.

Est-il partageable entre pods ?

Non. Il est local au pod.

Erreurs frequentes

• Utiliser emptyDir pour stocker des donnees importantes.
• Confondre redemarrage de conteneur et suppression de pod.
• Oublier de declarer le volume avant le volumeMount.
• Monter le volume au mauvais chemin.

Pour pratiquer

Creez un pod avec deux conteneurs busybox partageant un emptyDir: l’un ecrit, l’autre lit. Observez que le partage fonctionne seulement dans le meme pod.

Cycle de vie exact d’un emptyDir

Le point important est la difference entre redemarrage de conteneur et disparition du pod. Si un conteneur redemarre dans le meme pod, le volume emptyDir reste present. Si le pod est supprime puis recree, un nouveau emptyDir vide est cree.

Cette nuance est utile pour les caches, fichiers temporaires, donnees intermediaires ou echanges entre conteneurs. Elle est dangereuse pour les donnees que l’on veut conserver apres suppression du pod.

Exemple avec deux conteneurs

Un pod multi-conteneurs peut utiliser emptyDir comme zone de partage locale:

volumes:
  - name: shared
    emptyDir: {}
containers:
  - name: writer
    image: busybox
    command: ["sh", "-c", "while true; do date > /shared/date; sleep 5; done"]
    volumeMounts:
      - name: shared
        mountPath: /shared
  - name: reader
    image: busybox
    command: ["sh", "-c", "while true; do cat /shared/date; sleep 5; done"]
    volumeMounts:
      - name: shared
        mountPath: /shared

Ce pattern est courant pour comprendre les sidecars: un conteneur produit ou transforme des fichiers, un autre les consomme.

Quand ne pas utiliser emptyDir

emptyDir n’est pas adapte pour une base de donnees, des uploads utilisateur ou une configuration que l’on veut conserver. Pour ces cas, il faut passer a des volumes persistants ou a un service externe dedie.

Il faut aussi surveiller la consommation disque ou memoire selon la configuration. Un cache temporaire mal limite peut saturer un noeud si l’application ecrit trop.

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 029 – Volumes : le HostPath.

Conclusion

emptyDir est le volume le plus simple. Il enseigne la separation entre volume du pod et montage dans les conteneurs, notion indispensable pour la suite.