Un guide simple pour implémenter le stockage persistant dans Kubernetes

Le stockage persistant dans Kubernetes résout un problème simple : votre conteneur peut disparaître, mais vos fichiers de base de données, téléchargements ou données de file d'attente ne le peuvent pas. Les Pods sans état peuvent être remplacés à tout moment. Les applications avec état ont besoin d'un stockage qui survit aux redémarrages de Pods, aux réaffectations et à la maintenance des nœuds.

Ce guide explique les PersistentVolumes (PV), les PersistentVolumeClaims (PVC), les modes d'accès et les StorageClasses avec des exemples pratiques en YAML que vous pouvez adapter pour une charge de travail réelle.

Comprendre les PersistentVolumes (PV) et les PersistentVolumeClaims (PVC)

Avant de monter un stockage dans un Pod, sachez quel objet gère quelle tâche :

PersistentVolume (PV) : Un PV est un morceau de stockage dans le cluster qui a été provisionné par un administrateur ou provisionné dynamiquement à l'aide de StorageClasses. Les PV sont des ressources de cluster, un peu comme les nœuds. Ils ont un cycle de vie indépendant de tout Pod individuel qui utilise le PV. Les PV abstraient les détails d'implémentation du stockage sous-jacent (par exemple, NFS, iSCSI, stockage par blocs du fournisseur cloud).
PersistentVolumeClaim (PVC) : Un PVC est une demande de stockage par un utilisateur. Il consomme les ressources de stockage disponibles dans le cluster en tant que PV. Les PVC sont similaires aux Pods en ce sens qu'ils consomment des ressources de calcul et sont limités à un espace de noms. Un PVC spécifie la capacité de stockage souhaitée, les modes d'accès et, éventuellement, une StorageClass.

Cette séparation permet aux équipes de plateforme de gérer les détails du stockage tandis que les équipes d'application demandent la capacité et le modèle d'accès dont elles ont besoin.

Concepts clés : Modes d'accès et StorageClasses

Deux paramètres contrôlent la plupart des comportements des PVC : comment le volume peut être monté et quel backend de stockage doit le créer.

Modes d'accès

Les modes d'accès définissent comment un volume peut être monté sur un Pod. Les modes d'accès disponibles sont :

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.
ReadWriteOncePod (RWOP) : Le volume peut être monté en lecture-écriture par un seul Pod. Ceci est utile lorsque vous avez besoin d'un comportement d'écriture unique plus strict et que votre pilote CSI le prend en charge.

Il est important de noter que la prise en charge réelle de ces modes dépend du fournisseur de stockage sous-jacent.

StorageClasses

Une StorageClass fournit un moyen aux administrateurs de décrire les « classes » de stockage qu'ils proposent. Différentes classes peuvent correspondre à des niveaux de qualité de service, des politiques de sauvegarde ou des politiques arbitraires déterminées par les administrateurs du cluster. Une StorageClass a un provisionneur qui provisionne le stockage et un ensemble de paramètres pour le provisionneur. Lorsqu'un PVC est créé sans PV spécifique et qu'il demande une StorageClass, Kubernetes provisionnera dynamiquement un PV en utilisant la StorageClass spécifiée.

Implémentation du stockage persistant étape par étape

Parcourons un scénario courant : demander et utiliser un stockage persistant pour un Pod.

Étape 1 : Définir une PersistentVolumeClaim (PVC)

Tout d'abord, vous devez créer un PVC qui spécifie vos besoins en stockage. Ce PVC agira comme la demande de stockage pour votre application.

Exemple pvc.yaml :

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

Dans cet exemple :

name: my-pvc : C'est le nom de notre PVC.
accessModes: - ReadWriteOnce : Nous demandons un stockage qui peut être monté en lecture-écriture par un seul nœud.
resources.requests.storage: 1Gi : Nous demandons 1 Gigaoctet de stockage.

Application du PVC :

Enregistrez le contenu ci-dessus dans un fichier nommé pvc.yaml et appliquez-le à votre cluster :

kubectl apply -f pvc.yaml

Après l'application, vous pouvez vérifier l'état du PVC :

kubectl get pvc my-pvc

Vous devriez voir une sortie indiquant que le PVC est Bound si un PV approprié est disponible ou a été provisionné dynamiquement.

Étape 2 : Créer un Pod qui utilise le PVC

Maintenant, créons un Pod qui utilisera le stockage demandé par notre PVC. Nous monterons le volume fourni par le PVC dans un répertoire spécifique de notre conteneur.

Exemple pod-with-pv.yaml :

apiVersion: v1
kind: Pod
metadata:
  name: my-stateful-pod
spec:
  containers:
    - name: my-container
      image: nginx
      ports:
        - containerPort: 80
      volumeMounts:
        - name: my-persistent-storage
          mountPath: /usr/share/nginx/html
  volumes:
    - name: my-persistent-storage
      persistentVolumeClaim:
        claimName: my-pvc

Dans cet exemple :

volumes : Nous définissons un volume nommé my-persistent-storage.
persistentVolumeClaim.claimName: my-pvc : Cela lie notre volume au PVC que nous avons créé précédemment.
volumeMounts : Dans la définition du conteneur, nous spécifions où ce volume doit être monté (mountPath: /usr/share/nginx/html).

Application du Pod :

Enregistrez le contenu ci-dessus dans un fichier nommé pod-with-pv.yaml et appliquez-le :

kubectl apply -f pod-with-pv.yaml

Maintenant, votre conteneur nginx aura accès au stockage persistant défini par my-pvc au chemin /usr/share/nginx/html. Toutes les données écrites dans ce chemin à l'intérieur du conteneur seront conservées même si le Pod est supprimé et recréé, tant que le PVC et son PV sous-jacent restent.

Provisionnement dynamique avec les StorageClasses

La création manuelle de PV peut être fastidieuse. Kubernetes offre un provisionnement dynamique, où les PV sont créés automatiquement lorsqu'un PVC demande un stockage qui ne peut pas être satisfait par les PV existants. Ceci est réalisé via les StorageClasses.

La plupart des fournisseurs cloud (AWS, GCP, Azure) proposent des StorageClasses préconfigurées. Vous pouvez les inspecter avec :

kubectl get storageclass

Pour utiliser le provisionnement dynamique, ajoutez simplement un champ storageClassName à votre définition de PVC :

Exemple pvc-dynamic.yaml :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-dynamic-pvc
spec:
  storageClassName: standard # Remplacez 'standard' par un nom de StorageClass réel
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

Lorsque vous appliquez ce PVC, Kubernetes recherchera une StorageClass nommée standard (ou le nom que vous spécifiez) et demandera à son provisionneur de créer un nouveau PV de 5Gi et de le lier à ce PVC.

Conseils et bonnes pratiques

Choisissez le bon mode d'accès : Examinez attentivement le mode d'accès requis par votre application. ReadWriteOnce est courant pour les bases de données à réplica unique, tandis que ReadWriteMany est nécessaire pour les systèmes de fichiers partagés utilisés par plusieurs Pods.
Comprenez les performances du stockage : Différents fournisseurs de stockage et StorageClasses offrent des caractéristiques de performance variables (IOPS, débit). Choisissez une StorageClass qui répond aux besoins de performance de votre application.
Stratégie de sauvegarde : Le stockage persistant ne signifie pas automatiquement sauvegarde. Mettez en œuvre une stratégie de sauvegarde robuste pour vos volumes persistants, en particulier pour les données critiques.
Politique de récupération des PV : Les PV ont une persistentVolumeReclaimPolicy, généralement Delete ou Retain. Les volumes provisionnés dynamiquement utilisent souvent la politique de récupération définie par leur StorageClass. L'ancienne politique Recycle est obsolète et ne doit pas être utilisée pour les nouvelles configurations.
Considérations sur les espaces de noms : Les PVC sont limités à un espace de noms. Assurez-vous que votre Pod et votre PVC sont dans le même espace de noms pour que la liaison se produise.

À retenir

Le stockage persistant dans Kubernetes commence par un PVC, un montage de Pod et une StorageClass qui correspond à votre charge de travail. Pour une base de données à réplica unique, commencez par une demande ReadWriteOnce, vérifiez qu'elle atteint l'état Bound, montez-la dans le conteneur et intégrez les sauvegardes dans la conception dès le premier jour.