Le système de fichiers d’un conteneur ne dure que le temps du conteneur. Quand un Pod est remplacé, tout ce qu’il a écrit disparaît. C’est acceptable pour des serveurs web sans état, et problématique pour les bases de données, les fichiers téléversés et tout ce qui doit survivre. Ce guide montre comment Kubernetes attache du stockage durable aux Pods.

Pourquoi le stockage du conteneur ne suffit pas

Les conteneurs sont conçus pour être petits et jetables : y placer des données va à l’encontre du modèle. Les données doivent vivre en dehors du conteneur et en dehors du Pod, sur un stockage que Kubernetes attache au démarrage d’un Pod. Kubernetes est agnostique quant à la nature de ce stockage : disque cloud, partage réseau ou disque local. Il ne sauvegarde pas non plus les données à votre place. Cela reste votre responsabilité.

La chaîne de stockage

Quatre objets travaillent ensemble :

• Une StorageClass décrit un type de stockage et la façon de le créer à la demande (par exemple « volumes SSD rapides du fournisseur cloud »).
• Un PersistentVolume (PV) est un morceau de stockage réel dans le cluster.
• Une PersistentVolumeClaim (PVC) est une demande de stockage faite par un utilisateur ou une application : « j’ai besoin de 1 Gio qu’un seul nœud puisse lire et écrire ».
• Le Pod référence la claim comme un volume et la monte dans un conteneur.

Container ─ mountPath ─▶ Pod volume ─▶ PVC ─ binds to ─▶ PV ─▶ real storage
                                                          ▲
                                        StorageClass creates PVs on demand

Une PVC est liée à un seul PV. Le Pod ne fait jamais référence au PV, seulement à la claim, ce qui garde les applications indépendantes des détails du stockage.

Demander du stockage avec une PVC

La plupart des clusters ont une StorageClass par défaut qui crée des volumes à la demande (ce qu’on appelle le provisionnement dynamique), et minikube en inclut une. Vérifiez la vôtre :

kubectl get storageclass

Demandez ensuite du stockage :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

kubectl apply -f pvc.yaml
kubectl get pvc,pv

La claim devrait passer à Bound, et un PV correspondant apparaît. Certaines storage classes attendent qu’un Pod utilise réellement la claim avant de créer le volume : un statut Pending à ce stade n’est donc pas forcément une erreur.

La monter dans un Pod et prouver la persistance

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

Écrivez un fichier, détruisez le Pod, recréez-le et vérifiez que le fichier a survécu :

kubectl apply -f pod.yaml
kubectl exec storage-demo -- sh -c 'echo persisted > /data/proof.txt'
kubectl delete pod storage-demo
kubectl apply -f pod.yaml
kubectl exec storage-demo -- cat /data/proof.txt

Le nouveau Pod est un conteneur entièrement différent, mais la claim, et les données derrière elle, ont été rattachées.

Modes d’accès, politique de récupération et volumes statiques

• Les modes d’accès indiquent comment un volume peut être monté. ReadWriteOnce signifie lecture-écriture par un seul nœud : plusieurs Pods sur ce nœud peuvent donc quand même le partager. ReadOnlyMany et ReadWriteMany autorisent plusieurs nœuds, si le stockage le permet. ReadWriteOncePod le restreint à un seul Pod.
• La politique de récupération (reclaim policy) décide de ce qui arrive au volume quand la claim est supprimée. Les volumes provisionnés dynamiquement prennent généralement Delete par défaut, ce qui supprime le stockage sous-jacent et ses données. Utilisez Retain si vous voulez conserver les données.
• Le provisionnement statique signifie qu’un administrateur crée les PV à la main et que les claims se lient à celui qui convient. Un PV hostPath, qui utilise un répertoire d’un nœud, est une démo courante, mais il lie les données à une seule machine et ne convient qu’au développement sur un nœud unique.

Bases de données et StatefulSets

Vous pouvez monter une même claim dans les Pods d’un Deployment, mais les réplicas d’un Deployment sont interchangeables et identiques, et la plupart des bases de données ne fonctionnent pas ainsi. Un StatefulSet est conçu pour les charges de travail avec état. Il donne à chaque Pod une identité stable (db-0, db-1), les démarre et les met à jour dans l’ordre, et peut créer une PVC distincte pour chaque réplica :

spec:
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 5Gi

Un StatefulSet gère l’identité et le stockage, pas la réplication des données. Rendre les réplicas cohérents entre eux est le travail de la base de données, ce qui explique pourquoi exécuter des bases de données sur Kubernetes est plus difficile qu’exécuter des services sans état. Beaucoup d’équipes utilisent une base de données managée ou un operator de base de données, et gardent dans le cluster les applications sans état.