Réclamer du stockage : PersistentVolumeClaims (PVC)

Le besoin de l'application : comment demander du stockage ?

Nous avons vu que les PersistentVolumes (PVs) représentent des ressources de stockage disponibles dans le cluster, gérées par les administrateurs ou provisionnées dynamiquement. Cependant, une application (exécutée dans un Pod) ne référence pas directement un PV. D'une part, cela créerait un couplage fort entre l'application et une ressource d'infrastructure spécifique. D'autre part, comment l'application choisirait-elle le bon PV parmi tous ceux disponibles ?

Pour résoudre cela et maintenir le découplage, Kubernetes introduit la PersistentVolumeClaim (PVC). Une PVC est une demande de stockage effectuée par un utilisateur ou une application. C'est comme commander un type spécifique de ressource de stockage sans se soucier de savoir exactement quel disque physique ou partage réseau sera utilisé pour la satisfaire.

La PVC agit comme une interface entre le Pod (qui a besoin de stockage) et le PV (qui fournit le stockage). Le Pod référence la PVC, et Kubernetes se charge de trouver un PV compatible pour satisfaire la demande de la PVC. C'est un objet namespacé, ce qui signifie qu'une PVC existe dans un Namespace spécifique et ne peut être utilisée que par des Pods de ce même Namespace.

La PVC : une demande spécifiant les besoins

Une PersistentVolumeClaim spécifie les exigences de stockage de l'application :

• Quantité de stockage (`spec.resources.requests.storage`) : La taille minimale de stockage requise (ex: `8Gi`, `1Ti`).
• Modes d'accès (`spec.accessModes`) : Comment l'application a besoin de monter le volume (ex: `ReadWriteOnce`, `ReadOnlyMany`, `ReadWriteMany`). Le PV choisi devra supporter au moins l'un des modes demandés.
• Classe de stockage (`spec.storageClassName`) (optionnel) : Permet de demander un type ou une qualité de stockage spécifique, défini par une `StorageClass`. Si omis, le comportement dépend de la configuration du cluster (peut utiliser la StorageClass par défaut ou ne lier que des PVs sans StorageClass).
• Sélecteur (`spec.selector`) (optionnel) : Permet de filtrer plus finement les PVs disponibles en se basant sur leurs labels, en plus des autres critères. Utile principalement avec le provisionnement statique pour cibler un PV spécifique.
• Mode de volume (`spec.volumeMode`) (optionnel) : Permet de demander un volume `Filesystem` (par défaut) ou `Block`. Le PV doit correspondre.

L'utilisateur crée une PVC avec ces spécifications, exprimant ainsi les besoins de son application sans avoir à connaître les détails de l'infrastructure de stockage disponible.

Le processus de liaison (Binding) : marier PVC et PV

Une fois qu'une PVC est créée, le Control Plane de Kubernetes recherche un PersistentVolume (PV) disponible qui puisse satisfaire cette demande. Ce processus est appelé liaison (binding).

Pour qu'un PV soit lié à une PVC, les conditions suivantes doivent être remplies :

1. Le PV doit être dans l'état `Available`.
2. La capacité du PV doit être supérieure ou égale à la capacité demandée par la PVC (`spec.resources.requests.storage`).
3. Les modes d'accès du PV doivent inclure tous les modes d'accès demandés par la PVC. (Par exemple, si la PVC demande RWO, un PV offrant RWO, ROX, RWX pourrait convenir, mais pas un PV offrant seulement ROX).
4. Si la PVC spécifie une `storageClassName`, le PV doit avoir la même `storageClassName`. Si la PVC ne spécifie pas de `storageClassName`, seuls les PVs sans `storageClassName` seront considérés (sauf si une StorageClass par défaut est configurée dans le cluster, auquel cas le provisionnement dynamique peut intervenir).
5. Si la PVC utilise un `selector`, le PV doit correspondre aux labels spécifiés par ce sélecteur.
6. Si la PVC spécifie un `volumeMode`, le PV doit avoir le même `volumeMode`.

Kubernetes tente de trouver le PV qui correspond le mieux (souvent le plus petit PV disponible qui satisfait la demande de capacité et les autres critères). Une fois qu'un PV approprié est trouvé, Kubernetes le lie à la PVC.

• Le statut de la PVC passe de `Pending` à `Bound`.
• Le statut du PV passe de `Available` à `Bound`.
• Le PV est alors exclusivement réservé à cette PVC. Un PV ne peut être lié qu'à une seule PVC à la fois (relation un-à-un).

Si aucun PV ne peut satisfaire la demande (ou si le provisionnement dynamique via une StorageClass échoue), la PVC restera indéfiniment à l'état `Pending`.

Utiliser une PVC dans un Pod

Une fois qu'une PVC est à l'état `Bound`, elle peut être utilisée par un Pod comme source pour un volume. Le Pod référence simplement le nom de la PVC dans sa définition de volume.

Exemple YAML d'un Pod utilisant une PVC :

apiVersion: v1
kind: Pod
metadata:
  name: mon-pod-app
  namespace: production
spec:
  containers:
  - name: mon-conteneur
    image: mon-image
    volumeMounts:
    - name: donnees-app # Nom du montage
      mountPath: /var/lib/app/data # Chemin de montage dans le conteneur
  volumes:
  - name: donnees-app # Nom du volume, doit correspondre au volumeMount
    persistentVolumeClaim:
      claimName: ma-pvc-app # Nom de la PVC à utiliser (doit exister et être 'Bound')

Ici, le Pod `mon-pod-app` demande à monter un volume nommé `donnees-app`. La source de ce volume est la PVC nommée `ma-pvc-app` (qui doit exister dans le même namespace, `production`). Kubernetes s'assurera que le PV qui est lié à `ma-pvc-app` est correctement monté sur le noeud où le Pod s'exécute, puis le rendra disponible dans le conteneur au chemin `/var/lib/app/data`.

Le conteneur peut alors lire et écrire dans ce répertoire, et les données seront stockées de manière persistante dans le volume sous-jacent (le PV).

Cycle de vie et suppression d'une PVC

Les Pods consomment les PVCs comme des volumes. Plusieurs Pods peuvent monter la même PVC simultanément si le mode d'accès du PV sous-jacent le permet (par exemple, avec `ReadOnlyMany` ou `ReadWriteMany`).

Lorsque vous supprimez un Pod qui utilisait une PVC, la PVC elle-même n'est pas supprimée. Elle reste `Bound` au PV.

Lorsque vous supprimez une PVC (`kubectl delete pvc ma-pvc-app`), la protection du stockage est activée par défaut pour empêcher la perte de données si un Pod l'utilise encore. Vous devez d'abord supprimer les Pods utilisant la PVC. Une fois la PVC supprimée :

• Le PV qui lui était lié passe à l'état `Released`.
• La `persistentVolumeReclaimPolicy` du PV détermine ce qui se passe ensuite :
  • `Retain` : Le PV reste `Released`, les données sont conservées, mais le volume n'est pas immédiatement réutilisable. Intervention manuelle nécessaire.
  • `Delete` : Le PV et le volume de stockage sous-jacent sont supprimés. Données perdues.

Structure d'un manifeste de PVC

Voici un exemple de manifeste YAML pour une PVC :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ma-pvc-app # Nom de la PVC
  namespace: production # Namespace de la PVC
spec:
  accessModes:
    - ReadWriteOnce # Mode d'accès demandé
  volumeMode: Filesystem # Mode du volume demandé (Filesystem ou Block)
  resources:
    requests:
      storage: 8Gi # Taille minimale demandée
  # Optionnel: Spécifier une StorageClass
  # storageClassName: fast-ssd
  # Optionnel: Utiliser un sélecteur pour cibler des PVs spécifiques
  # selector:
  #   matchLabels:
  #     type: local-ssd

Gérer les PVCs avec `kubectl`

• Lister les PVCs : `kubectl get persistentvolumeclaims` (ou `kubectl get pvc`) [-n namespace]
• Inspecter une PVC : `kubectl describe pvc [NOM_PVC]` [-n namespace] (Montre le statut, le PV lié, la capacité, etc.)
• Supprimer une PVC : `kubectl delete pvc [NOM_PVC]` [-n namespace] (Attention, cela peut entraîner la suppression du PV et des données selon la politique de réclamation !)

Conclusion : la demande de stockage standardisée

La PersistentVolumeClaim (PVC) est l'interface standard par laquelle les applications dans Kubernetes demandent et consomment du stockage persistant. Elle abstrait les détails de l'infrastructure de stockage, permettant aux développeurs de spécifier leurs besoins (taille, accès) de manière simple et portable.

En travaillant de concert avec les PersistentVolumes (PVs), les PVCs complètent le modèle de découplage du stockage de Kubernetes. Ce mécanisme robuste est la base sur laquelle repose le déploiement d'applications stateful nécessitant une persistance des données fiable et gérée indépendamment du cycle de vie des Pods.