Volumes persistants et revendications

Les Pods apparaissent et disparaissent, mais les données de votre application doivent souvent perdurer. Pensez à une base de données ou à des fichiers importés par les utilisateurs.

• Lorsqu’un Pod redémarre ou est replanifié, toutes les données stockées directement dans le système de fichiers de son conteneur sont perdues.
• Cette nature éphémère convient aux applications sans état, mais les données critiques nécessitent une solution durable.
• Kubernetes fournit un système puissant pour gérer un stockage persistant qui survit aux cycles de vie des Pods.

Un PersistentVolume (PV) est un espace de stockage dans votre cluster Kubernetes.

• Il s’agit d’une ressource dont la portée est le cluster : elle n’appartient donc à aucun espace de noms particulier.
• Les PV sont provisionnés par un administrateur ou automatiquement par une StorageClass.
• Ils masquent les détails de la technologie de stockage sous-jacente (par exemple, Google Persistent Disk, AWS EBS ou un partage NFS).

Les PV sont définis avec des informations telles que la capacité, les modes d’accès et le type de stockage. Ce YAML décrit un PV utilisant un hostPath (pour les tests locaux) avec 5 gigaoctets de stockage.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-local-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/mnt/data"

Remarque : hostPath est généralement destiné au développement sur un seul nœud et n’est pas recommandé en production.

Un PersistentVolumeClaim (PVC) est une demande de stockage formulée par un utilisateur ou une application dans un espace de noms précis.

• Les Pods n’utilisent pas directement les PV : ils demandent du stockage par l’intermédiaire d’un PVC.
• Les PVC ont une portée limitée à un espace de noms : ils résident donc dans l’espace d’un projet ou d’une équipe donnée.
• Ils indiquent la taille souhaitée, les modes d’accès et, éventuellement, une classe de stockage.

Kubernetes associe automatiquement un PVC à un PV disponible lors d’un processus appelé liaison.

• Lorsqu’un PVC est créé, Kubernetes recherche un PV qui répond aux exigences du PVC (taille, modes d’accès et classe de stockage).
• Une fois un PV adapté trouvé, les deux ressources sont « liées » dans une relation individuelle.
• Cette liaison garantit que le PVC obtient exactement le stockage demandé.

Les modes d’accès définissent la manière dont le stockage peut être monté et utilisé par les Pods. Ces modes sont demandés par les PVC et pris en charge par les PV :

• ReadWriteOnce (RWO) : le volume peut être monté en lecture-écriture par un seul nœud.
• ReadOnlyMany (ROX) : le volume peut être monté en lecture seule par plusieurs nœuds.
• ReadWriteMany (RWX) : le volume peut être monté en lecture-écriture par plusieurs nœuds.

La disponibilité de ces modes dépend du fournisseur de stockage concerné.

Les Storage Classes permettent aux administrateurs de décrire des « classes » de stockage, par exemple « fast-ssd » ou « slow-hdd ».

• Au lieu de créer manuellement des PV, une StorageClass peut provisionner automatiquement un PV lorsqu’un PVC le demande.
• Cette approche automatise la création des PV à partir de modèles prédéfinis.
• Elle sépare le provisionnement du stockage de son utilisation, ce qui simplifie la tâche des utilisateurs.

Créons un PVC qui demande 1 gigaoctet de stockage avec l’accès ReadWriteOnce. Ce PVC recherchera un PV existant ou déclenchera un provisionnement automatique via une StorageClass.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-app-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: standard # Optional: if you have a 'standard' StorageClass

Enregistrez ceci sous pvc.yaml, puis appliquez-le avec kubectl apply -f pvc.yaml.

Une fois qu’un PVC est lié, un Pod peut l’utiliser en faisant référence au nom du PVC dans sa configuration de volume. Le Pod n’a pas besoin de connaître le PV sous-jacent, mais uniquement le PVC.

apiVersion: v1
kind: Pod
metadata:
  name: my-data-pod
spec:
  containers:
    - name: data-container
      image: busybox
      command: ["/bin/sh", "-c", "echo 'Hello from CoddyKit!' > /mnt/data/hello.txt && sleep 3600"]
      volumeMounts:
        - name: persistent-storage
          mountPath: /mnt/data
  volumes:
    - name: persistent-storage
      persistentVolumeClaim:
        claimName: my-app-pvc

Ce Pod écrira un fichier dans le volume persistant monté.

Vous pouvez surveiller l’état de vos ressources de stockage persistant à l’aide de kubectl :

• Pour afficher tous les PV : kubectl get pv
• Pour afficher tous les PVC de votre espace de noms : kubectl get pvc
• Pour obtenir des informations détaillées, notamment l’état et les événements :
• kubectl describe pv <pv-name>
• kubectl describe pvc <pvc-name>

Vérifiez que vos PV sont à l’état Bound et que les PVC sont liés au PV approprié.

Un utilisateur souhaite déployer une base de données nécessitant 50 Go de stockage persistant. Quelle ressource Kubernetes représente directement la demande de stockage de l’application de l’utilisateur ?

Nous avons vu comment Kubernetes gère le stockage durable de vos applications :

• Les PersistentVolumes (PVs) sont des ressources du cluster qui représentent le stockage réel.
• Les PersistentVolumeClaims (PVCs) sont des demandes de stockage formulées par les utilisateurs.
• Kubernetes lie les PVC aux PV appropriés en fonction des exigences.
• Les modes d’accès définissent la manière dont le stockage peut être utilisé (RWO, ROX et RWX).
• Les classes de stockage permettent le provisionnement automatique des PV et automatisent leur configuration.

Ce système garantit la persistance des données de votre application, même si les Pods apparaissent et disparaissent, ce qui assure la fiabilité des applications avec état.