Polarys
Kubernetes : les bases/Résilience et mise à l'échelle

Résilience et mise à l'échelle

Volumes persistants et stockage

Volumes persistants et stockage

Le problème du stockage éphémère

Par défaut, tout ce qui est écrit dans un conteneur disparaît quand le Pod est recréé. Pour des données qui doivent survivre (base de données, fichiers uploadés), Kubernetes propose le stockage persistant.

PersistentVolume et PersistentVolumeClaim

  • PersistentVolume (PV) : représente un espace de stockage physique réel (disque cloud, NFS, etc.), provisionné par un administrateur ou dynamiquement.
  • PersistentVolumeClaim (PVC) : une demande de stockage faite par une application, qui se "lie" à un PV compatible.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mon-app-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
spec:
  containers:
    - name: web
      image: mon-app:latest
      volumeMounts:
        - mountPath: /data
          name: mon-volume
  volumes:
    - name: mon-volume
      persistentVolumeClaim:
        claimName: mon-app-pvc

Modes d'accès

ModeSignification
ReadWriteOnceMonté en lecture/écriture par un seul nœud à la fois
ReadOnlyManyMonté en lecture seule par plusieurs nœuds
ReadWriteManyMonté en lecture/écriture par plusieurs nœuds (nécessite un stockage compatible, ex. NFS)

Cas concret

Une base de données PostgreSQL tourne dans un Pod avec un PVC de 10 Gi en ReadWriteOnce. Le Pod est supprimé puis recréé (mise à jour, panne de nœud) : le PVC reste lié au même PersistentVolume, les données de la base sont toujours là au redémarrage. Sans PVC, toutes les données auraient été perdues.

Erreurs fréquentes

  • Stocker une base de données sans PVC : perte totale des données à la moindre recréation de Pod, erreur fréquente en environnement de test qui devient catastrophique en production.
  • Utiliser ReadWriteOnce pour une application multi-nœuds qui a besoin d'écrire depuis plusieurs Pods simultanément : le PVC ne se montera que sur un seul nœud à la fois, bloquant les autres.
  • Oublier de dimensionner le stockage : un PVC trop petit force une intervention manuelle pour l'agrandir plus tard (pas toujours possible selon le type de stockage).

À retenir

  • PersistentVolume = stockage physique réel, PersistentVolumeClaim = demande faite par l'application.
  • ReadWriteOnce est le mode le plus courant, mais bloque le multi-nœud en écriture simultanée.
  • Sans PVC, toute donnée écrite dans un Pod est perdue à sa recréation.

Mini-exercice

Une base de données doit survivre à la recréation de son Pod suite à une panne de nœud. Quel objet Kubernetes le garantit ?

Réponse : un PersistentVolumeClaim lié à un PersistentVolume, qui conserve les données indépendamment du cycle de vie du Pod lui-même.

Quiz de validation

Quiz - 2 questions

1. Que se passe-t-il aux données écrites dans un Pod sans volume persistant, à sa recréation ?

2. Quel mode d'accès permet un montage lecture/écriture depuis un seul nœud à la fois ?

Suis ta progression

Crée un compte gratuit pour suivre ta progression et accéder à toutes les leçons.