Retour au cours

stockage dans kubernetes : volumes et persistent volumes

Objectifs

  • Comprendre pourquoi le stockage est un défi pour les applications “stateful” (comme les bases de données) dans Kubernetes.
  • Distinguer les volumes éphémères des volumes persistants.
  • Apprendre le mécanisme de demande et d’attribution de stockage avec les PersistentVolumeClaim (PVC) et les PersistentVolume (PV).

Le problème : Les Pods sont mortels, les données ne doivent pas l’être

Nous avons vu que les Pods sont éphémères. Un Deployment peut les détruire et les recréer à tout moment. C’est parfait pour des applications “stateless” (sans état), comme un serveur web qui sert des fichiers statiques.

Mais pour une application “stateful” comme une base de données, c’est inacceptable. Si le Pod de votre base de données est redémarré, vous ne voulez pas perdre toutes vos données. Le cycle de vie des données doit être indépendant du cycle de vie du Pod.

La solution : découpler le stockage

Kubernetes propose un sous-système de volumes qui permet de découpler le stockage du Pod.

PersistentVolume (PV) et PersistentVolumeClaim (PVC)

C’est le mécanisme central et le plus important à comprendre. Il introduit une séparation des rôles entre l’administrateur du cluster et le développeur.

  1. PersistentVolume (PV) : C’est une ressource de stockage dans le cluster (un disque dur réseau, un volume sur le cloud…). C’est l’administrateur qui le met à disposition. Il décrit la capacité, le type de disque (rapide/lent), et le mode d’accès.

  2. PersistentVolumeClaim (PVC) : C’est une demande de stockage faite par un développeur. Il ne demande pas un disque spécifique, mais il exprime un besoin : “J’ai besoin de 5 GiB de stockage rapide.”

Kubernetes va alors faire correspondre le PVC à un PV disponible qui satisfait la demande. Le PVC est ensuite “lié” (Bound) au PV.

  1. Utilisation dans un Pod : Le développeur peut enfin monter ce PVC comme un volume dans son Pod. Kubernetes s’assurera que le Pod est toujours connecté au bon stockage physique, même s’il est déplacé d’un Node à un autre.

Développeur

Administrateur

est lié à

est utilisé par

Disque physique ou Cloud

PersistentVolume (PV) - L'Offre

PersistentVolumeClaim (PVC) - La Demande

Pod

Exemple de PVC

C’est l’objet que vous manipulerez le plus souvent en tant que développeur.

# pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ma-db-pvc
spec:
  # Mode d'accès :
  # ReadWriteOnce (RWO): Montable en lecture/écriture par un seul Node à la fois. Le plus courant.
  # ReadOnlyMany (ROX): Lecture seule par plusieurs Nodes.
  # ReadWriteMany (RWX): Lecture/écriture par plusieurs Nodes (plus rare).
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi # Je demande 5 Gigaoctets
  # storageClassName: "fast" # Optionnel: pour demander un type de disque spécifique

Exemple d’utilisation dans un Pod

# pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: mon-pod-db
spec:
  containers:
    - name: postgres
      image: postgres:15
      ports:
        - containerPort: 5432
      volumeMounts:
        - name: stockage-postgres
          mountPath: /var/lib/postgresql/data # Le dossier de données de PostgreSQL
  volumes:
    - name: stockage-postgres
      persistentVolumeClaim:
        claimName: ma-db-pvc # On utilise le PVC défini plus haut

Bonnes pratiques

  • Toujours utiliser des PVC pour les données qui doivent survivre à un redémarrage de Pod.
  • Utilisez les StorageClasses (un concept plus avancé) pour demander dynamiquement des types de stockage spécifiques (ex: ssd vs hdd) sans avoir à connaître les détails de l’infrastructure.
  • Dimensionnez vos demandes de stockage (requests.storage) de manière réaliste.

Pièges courants

  • Confondre un volume éphémère (comme emptyDir) avec un stockage persistant. Un volume emptyDir est vide au démarrage du Pod et ses données sont perdues quand le Pod est supprimé.
  • Problèmes d’Access Modes : Essayer de monter un PVC ReadWriteOnce sur plusieurs Pods en même temps. Cela ne fonctionnera pas sur la plupart des infrastructures cloud.
  • Oublier de nettoyer : Quand vous supprimez un Pod et un PVC, le PV sous-jacent n’est pas toujours supprimé automatiquement. Il faut parfois le supprimer manuellement pour ne pas continuer à payer le stockage.

Exercices

(Ces exercices nécessitent un cluster local comme minikube ou k3d qui supporte le provisionnement dynamique de volumes).

  1. Créez votre première demande de stockage :

    • Écrivez le fichier pvc.yaml de l’exemple ci-dessus.
    • Appliquez-le : kubectl apply -f pvc.yaml.
    • Vérifiez son statut avec kubectl get pvc. Il devrait passer de Pending à Bound.
    • Vérifiez aussi avec kubectl get pv qu’un PersistentVolume a été créé pour vous.

  2. Lancez un Pod qui écrit des données :

    • Créez un Pod qui monte ce PVC dans /data et qui écrit un fichier test.txt à l’intérieur.
    • Exemple de commande pour le conteneur : ["/bin/sh", "-c", "echo 'Hello persistent world' > /data/test.txt && sleep 3600"].

  3. Vérifiez la persistance :

    • Supprimez le Pod : kubectl delete pod <nom-du-pod>.
    • Le PVC et le PV doivent toujours exister.
    • Créez un deuxième Pod, identique au premier, qui monte le même PVC.
    • Connectez-vous au shell de ce nouveau Pod (kubectl exec -it <nouveau-pod> -- bash) et vérifiez que le fichier /data/test.txt est toujours là avec son contenu.

Sujets abordés