Introduction à l'abstraction du stockage : PersistentVolumes (PV)

Découpler le stockage : au-delà des limites du Pod

Nous avons vu que les volumes directement liés aux Pods, comme `emptyDir` ou `hostPath`, ne fournissent pas la persistance ou la portabilité nécessaires aux applications stateful. Les données sont soit perdues avec le Pod (`emptyDir`), soit dangereusement liées au noeud hôte (`hostPath`). Pour gérer le stockage de manière fiable et indépendante du cycle de vie des Pods, Kubernetes introduit une abstraction essentielle : le PersistentVolume (PV).

Le PV est une ressource au niveau du cluster qui représente un "morceau" de stockage réseau ou local mis à disposition du cluster. Pensez à un PV comme à une ressource d'infrastructure de stockage (un disque réseau, un LUN SAN, un volume EBS sur AWS, un Persistent Disk sur GCP, un partage NFS...) qui a été provisionné par un administrateur ou automatiquement par le système, et qui est prêt à être utilisé par les applications.

L'idée fondamentale est de séparer la *gestion* du stockage (le provisionnement, la configuration des détails techniques – rôle de l'administrateur ou du système via les PVs) de la *consommation* de ce stockage par les applications (rôle de l'utilisateur via les PersistentVolumeClaims, que nous verrons ensuite).

Le PersistentVolume : une ressource de stockage dans le cluster

Un PersistentVolume (PV) n'est pas lié à un Namespace spécifique ; c'est une ressource globale disponible pour l'ensemble du cluster. Il capture les détails de l'implémentation du stockage, tels que le type de volume (NFS, iSCSI, Ceph, GCEPersistentDisk, AWSElasticBlockStore, etc.), sa taille, et comment y accéder.

Un administrateur peut créer manuellement des PVs pour représenter des ressources de stockage existantes (provisionnement statique), ou bien les PVs peuvent être créés automatiquement par Kubernetes lorsqu'une demande de stockage (une PVC) est faite, grâce au mécanisme des StorageClasses (provisionnement dynamique, que nous aborderons plus loin).

Un PV existe indépendamment de tout Pod qui pourrait l'utiliser. Son cycle de vie est géré séparément, garantissant que les données persistent même si tous les Pods qui l'utilisaient sont supprimés.

Attributs clés d'un PersistentVolume

La définition d'un PV contient plusieurs informations importantes dans sa `spec` :

• `capacity` : La quantité de stockage disponible dans ce volume (ex: `storage: 5Gi`). C'est une information clé utilisée pour lier le PV à une demande de stockage (PVC).
• `volumeMode` : Indique si le volume doit être utilisé comme un système de fichiers (`Filesystem`, par défaut) ou comme un périphérique de bloc brut (`Block`).
• `accessModes` : Définit comment le volume peut être monté par les noeuds. C'est crucial pour déterminer si plusieurs Pods peuvent utiliser le volume simultanément. Les modes courants sont :
  • `ReadWriteOnce` (RWO) : Le volume peut être monté en lecture-écriture par un unique noeud à la fois. C'est le mode le plus courant pour les volumes de bloc comme EBS ou GCE PD.
  • `ReadOnlyMany` (ROX) : Le volume peut être monté en lecture seule par plusieurs noeuds simultanément.
  • `ReadWriteMany` (RWX) : Le volume peut être monté en lecture-écriture par plusieurs noeuds simultanément. Ce mode est généralement supporté par les systèmes de fichiers réseau comme NFS ou CephFS.
  • `ReadWriteOncePod` (RWOP) : (Plus récent) Le volume peut être monté en lecture-écriture par un unique Pod à la fois.
  La demande de stockage (PVC) devra spécifier un mode d'accès compatible.
• `persistentVolumeReclaimPolicy` : Définit ce qu'il advient du PV (et de ses données) lorsque la PersistentVolumeClaim (PVC) qui lui était liée est supprimée. Les options sont :
  • `Retain` (souvent le défaut sûr) : Le PV n'est pas supprimé, il passe à l'état `Released`. Les données sont conservées, mais le volume n'est plus disponible pour une nouvelle PVC tant qu'il n'est pas nettoyé et réclamé manuellement par l'administrateur. C'est l'option la plus sûre pour éviter la perte de données.
  • `Delete` : Le volume de stockage sous-jacent (ex: le disque EBS/GCE) est supprimé en même temps que le PV. Les données sont perdues. Souvent utilisé avec le provisionnement dynamique.
  • `Recycle` (déprécié) : Tentait d'effectuer un nettoyage basique du volume avant de le rendre disponible pour une nouvelle PVC. N'est plus recommandé.
• `storageClassName` : Associe le PV à une `StorageClass` spécifique. Les StorageClasses sont utilisées pour le provisionnement dynamique et permettent aux PVCs de demander un certain "type" ou "qualité" de stockage sans connaître les PVs spécifiques. Un PV sans `storageClassName` ne peut être lié qu'à une PVC qui demande explicitement *aucun* StorageClass ou qui correspond via des labels.
• Type de volume spécifique (ex: `nfs`, `awsElasticBlockStore`, `gcePersistentDisk`, `csi`...) : Contient les détails techniques nécessaires pour monter et utiliser le volume physique sous-jacent (adresse du serveur NFS, chemin d'exportation, ID du volume EBS, etc.). L'utilisation de pilotes CSI (Container Storage Interface) est la méthode moderne et standardisée pour intégrer divers systèmes de stockage.

Voici un exemple très simplifié d'un PV provisionné statiquement pour un partage NFS :

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv-data
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany # NFS supporte RWX
  persistentVolumeReclaimPolicy: Retain
  storageClassName: slow-nfs # Associé à une StorageClass (optionnel pour statique)
  nfs:
    path: /exports/data
    server: nfs-server.example.com

Cycle de vie d'un PersistentVolume

Un PV passe par différentes phases au cours de sa vie :

• Provisioning : Le stockage est créé, soit manuellement par un admin (statique), soit automatiquement via une StorageClass (dynamique).
• Binding : Le processus où Kubernetes trouve un PV approprié pour satisfaire une PVC. Une fois lié (bind), le PV est exclusivement réservé à cette PVC.
• Using : La PVC est liée, et un ou plusieurs Pods montent et utilisent le volume via cette PVC.
• Reclaiming : Lorsque la PVC est supprimée par l'utilisateur, le PV passe à l'état `Released`. La politique `persistentVolumeReclaimPolicy` détermine alors si le volume sous-jacent est conservé (`Retain`) ou supprimé (`Delete`).

L'état actuel d'un PV peut être l'un des suivants :

• Available : Disponible, non lié à une PVC.
• Bound : Lié à une PVC.
• Released : La PVC a été supprimée, mais la ressource PV existe toujours (en attente de réclamation selon la policy).
• Failed : Le PV a échoué d'une manière ou d'une autre (ex: échec de la réclamation automatique).

Le rôle clé du PV dans la persistance découplée

En introduisant le PersistentVolume, Kubernetes crée une séparation nette entre l'infrastructure de stockage et son utilisation par les applications. Les PVs encapsulent les détails spécifiques au fournisseur de stockage, rendant le stockage disponible comme une ressource standardisée dans le cluster.

Cela contraste fortement avec les volumes comme `hostPath`, qui lient directement le Pod à un noeud spécifique, ou `emptyDir`, qui lie les données au cycle de vie du Pod. Les PVs offrent une persistance réelle, indépendante des Pods et des noeuds.

Cependant, les Pods n'utilisent pas directement les PVs. Ils ont besoin d'un moyen de "demander" du stockage avec certaines caractéristiques. C'est là qu'intervient l'objet PersistentVolumeClaim (PVC), qui fait le pont entre l'application et le PV disponible.