Volumes persistants et provisionnement dynamique

Cette page présente les volumes persistants et les revendications dans Kubernetes, ainsi que leur utilisation avec Google Kubernetes Engine (GKE). Cette page est consacrée aux espaces de stockage sauvegardés par les disques persistants Compute Engine.

PersistentVolumes

Les ressources PersistentVolume permettent de gérer l'espace de stockage durable dans un cluster. Dans GKE, un PersistentVolume est généralement sauvegardé par un disque persistant. Vous pouvez également utiliser d'autres solutions de stockage telles que NFS. Filestore est une solution NFS sur Google Cloud. Pour savoir comment configurer une instance Filestore en tant que solution PersistentVolumes NFS pour vos clusters GKE, consultez la page Accéder aux instances Filestore avec le pilote CSI Filestore dans la documentation de Filestore.

Le service Cloud Volumes est une autre option de stockage. Ce produit est un service de stockage de données entièrement géré, basé sur le cloud, qui offre des fonctionnalités avancées de gestion des données et des performances hautement évolutives.

Le cycle de vie d'un fichier PersistentVolume est géré par Kubernetes. Un PersistentVolume peut être provisionné de manière dynamique. Vous n'avez pas besoin de créer ni de supprimer manuellement l'espace de stockage de sauvegarde.

Les ressources PersistentVolume sont des ressources de cluster qui existent indépendamment des pods. Cela signifie que le disque et les données représentés par une ressource PersistentVolume continuent d'exister à mesure que le cluster change et que les pods sont supprimés et recréés. Les ressources PersistentVolume peuvent être provisionnées de manière dynamique via des ressources PersistentVolumeClaims ou peuvent être créées explicitement par un administrateur de cluster.

Pour en savoir plus sur les ressources PersistentVolume, reportez-vous à la documentation sur PersistentVolumes de Kubernetes et à la documentation de référence de l'API PersistentVolumes.

PersistentVolumeClaims

Une PersistentVolumeClaim représente une requête et une revendication pour une ressource PersistentVolume. Les objets PersistentVolumeClaim demandent une taille, un mode d'accès et une StorageClass spécifiques pour le PersistentVolume. Si un PersistentVolume qui satisfait la requête existe ou peut être provisionné, la ressource PersistentVolumeClaim est associée à ce PersistentVolume.

Les pods utilisent les demandes sous forme de volumes. Le cluster inspecte la demande pour rechercher le volume associé et l'installe pour le pod.

La portabilité est un autre avantage de l'utilisation des ressources PersistentVolumes et PersistentVolumeClaims. Vous pouvez facilement vous servir de la même spécification de pod dans différents clusters et environnements, car PersistentVolume constitue une interface vers le véritable espace de stockage de sauvegarde.

StorageClasses

Les implémentations de volumes telles que le pilote CSI (Container Storage Interface) de disque persistant Compute Engine sont configurées via des ressources StorageClass.

GKE crée automatiquement une StorageClass par défaut qui utilise le type de disque persistant standard (ext4). La StorageClass par défaut est utilisée lorsqu'une PersistentVolumeClaim ne spécifie pas de StorageClassName. Vous pouvez remplacer la StorageClass fournie par défaut par celle que vous avez définie. Pour obtenir des instructions, consultez la section Modifier la ressource StorageClass par défaut.

Vous pouvez créer vos propres ressources StorageClass pour décrire différentes classes de stockage. Par exemple, les classes peuvent correspondre à certains niveaux de qualité de service ou à certaines règles de sauvegarde. Ce concept est parfois appelé "profils" dans d'autres systèmes de stockage.

Si vous utilisez un cluster avec des pools de nœuds Windows, vous devez créer une StorageClass et spécifier un StorageClassName dans la PersistentVolumeClaim, car le fstype par défaut (ext4) n'est pas compatible avec Windows. Si vous utilisez un disque persistant Compute Engine, vous devez utiliser le type de stockage de fichiers NTFS.

Lorsque vous définissez un objet StorageClass, vous devez répertorier un approvisionneur. Sur GKE, nous vous recommandons d'utiliser l'un des approvisionneurs suivants :

Provisionner dynamiquement les PersistentVolume

La plupart du temps, il n'est pas nécessaire de configurer directement des objets PersistentVolume ou de créer des disques persistants Compute Engine. À la place, vous pouvez créer un PersistentVolumeClaim, et Kubernetes va automatiquement provisionner un disque persistant pour vous.

Le fichier manifeste ci-dessous décrit une requête pour un disque avec 30 gibioctets (Gio) de stockage dont le mode d'accès lui permet d'être installé en lecture/écriture par un seul nœud. Il crée également un pod qui utilise PersistentVolumeClaim en tant que volume.

# pvc-pod-demo.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-demo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi
  storageClassName: standard-rwo
---
kind: Pod
apiVersion: v1
metadata:
  name: pod-demo
spec:
  volumes:
    - name: pvc-demo-vol
      persistentVolumeClaim:
       claimName: pvc-demo
  containers:
    - name: pod-demo
      image: nginx
      resources:
        limits:
          cpu: 10m
          memory: 80Mi
        requests:
          cpu: 10m
          memory: 80Mi
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: pvc-demo-vol

Lorsque vous créez cet objet PersistentVolumeClaim à l'aide de kubectl apply -f pvc-pod-demo.yaml, Kubernetes crée dynamiquement un objet PersistentVolume correspondant.

Comme la classe de stockage standard-rwo utilise le mode de liaison de volume WaitForFirstConsumer, le PersistentVolume n'est pas créé tant qu'un pod n'est pas programmé pour utiliser le volume.

L'exemple suivant montre la ressource PersistentVolume créée.

apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: pd.csi.storage.gke.io
  finalizers:
  - kubernetes.io/pv-protection
  - external-attacher/pd-csi-storage-gke-io
  name: pvc-c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  uid: d52af557-edf5-4f96-8e89-42a3008209e6
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 30Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: pvc-demo
    namespace: default
    uid: c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  csi:
    driver: pd.csi.storage.gke.io
    csi.storage.k8s.io/fstype: ext4
    volumeAttributes:
      storage.kubernetes.io/csiProvisionerIdentity: 1660085000920-8081-pd.csi.storage.gke.io
    volumeHandle: projects/xxx/zones/us-central1-c/disks/pvc-c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.gke.io/zone
          operator: In
          values:
          - us-central1-c
  persistentVolumeReclaimPolicy: Delete
  storageClassName: standard-rwo
  volumeMode: Filesystem
status:
  phase: Bound

Si nous partons du principe que vous n'avez pas remplacé la classe de stockage standard-rwo, ce PersistentVolume est sauvegardé par un nouveau disque persistant Compute Engine vide.

Supprimer le stockage persistant

Par défaut, la suppression d'un objet PersistentVolumeClaim pour des volumes provisionnés dynamiquement tels que les disques persistants Compute Engine supprime l'objet PersistentVolume et le disque de sauvegarde réel. Ce comportement est contrôlé par la règle de récupération dans les ressources StorageClass et PersistentVolume, qui peut être définie sur la valeur par défaut Delete, ou Retain. Pour en savoir plus, consultez la documentation Kubernetes concernant la récupération.

Gérer le stockage persistant lors de la suppression du cluster

Lorsqu'un cluster GKE est supprimé, GKE conserve les ressources PersistentVolume avec la règle de récupération Delete ou Retain.

Pour supprimer des ressources PersistentVolume lorsque vous supprimez un cluster, vous pouvez supprimer manuellement l'espace de noms des ressources PersistentVolumeClaim, ce qui déclenche la suppression des objets PersistentVolume avec la règle Delete. Vous pouvez également supprimer des ressources PersistentVolumeClaim individuelles. Toutefois, GKE n'attend pas que ces activités de suppression soient terminées avant de commencer à supprimer le cluster. Ainsi, si vous supprimez un espace de noms, puis supprimez immédiatement le cluster, les ressources PersistentVolume avec des règles Delete risquent de ne pas être supprimées.

Après la suppression du cluster, vous pouvez afficher les ressources PersistentVolume restantes dans la console Google Cloud.

Pour afficher les ressources inutilisées, telles que les ressources PersistentVolume non utilisées, vous pouvez afficher les recommandations pour les ressources inactives.

Modes d'accès

Les ressources PersistentVolume sont compatibles avec les modes d'accès suivants :

  • ReadWriteOnce : le volume peut être installé en lecture/écriture par un seul nœud.
  • ReadOnlyMany : le volume peut être installé en lecture seule par plusieurs nœuds.
  • ReadWriteMany : le volume peut être installé en lecture/écriture par plusieurs nœuds. Les ressources PersistentVolume qui reposent sur des disques persistants Compute Engine ne sont pas compatibles avec ce mode d'accès.

Utiliser des disques persistants Compute Engine en tant que ReadOnlyMany

ReadWriteOnce est le cas d'utilisation le plus courant pour les disques persistants et fonctionne comme mode d'accès par défaut pour la plupart des applications. Les disques persistants Compute Engine sont également compatibles avec le mode ReadOnlyMany, de sorte que plusieurs applications ou plusieurs instances dupliquées de la même application puissent utiliser le même disque en même temps. Un exemple de cas d'utilisation est la diffusion de contenu statique sur plusieurs instances dupliquées.

Pour obtenir des instructions, consultez la page Utiliser des disques persistants avec plusieurs lecteurs.

Utiliser des disques persistants préexistants en tant que PersistentVolume

Les ressources PersistentVolume provisionnées dynamiquement sont vides au moment de leur création. Si vous disposez déjà d'un disque persistant Compute Engine contenant des données, vous pouvez l'introduire dans votre cluster en créant manuellement une ressource PersistentVolume correspondante. Le disque persistant doit être dans la même zone que les nœuds de cluster.

Reportez-vous à cet exemple sur la création d'un volume persistant sauvegardé par un disque persistant préexistant.

Déploiements et StatefulSets

Vous pouvez utiliser des PersistentVolumeClaim ou des modèles de VolumeClaim dans des contrôleurs de niveau supérieur tels que les objets Déploiement ou StatefulSet, respectivement.

Les déploiements sont conçus pour les applications sans état. Par conséquent, toutes les instances dupliquées d'un déploiement partagent la même PersistentVolumeClaim. Les pods d'instances dupliquées créés étant identiques, seuls les volumes en mode ReadWriteMany peuvent fonctionner avec ce paramètre.

Même les déploiements avec une seule instance dupliquée utilisant un volume ReadWriteOnce ne sont pas recommandés. En effet, la stratégie de déploiement par défaut crée un second pod avant de supprimer le premier pod lorsqu'une instance est recréée. Le déploiement risque d'être bloqué. En effet, le second pod ne peut pas démarrer, car le volume ReadWriteOnce est déjà utilisé, et le premier pod ne sera pas supprimé parce que le second pod n'a pas encore démarré. À la place, servez-vous d'un objet StatefulSet avec des volumes ReadWriteOnce.

L'utilisation d'objets StatefulSets est la méthode recommandée pour déployer des applications avec état qui nécessitent un volume unique par instance dupliquée. En vous servant de StatefulSets avec des modèles de PersistentVolumeClaim, vous obtenez des applications qui peuvent évoluer automatiquement avec des PersistentVolumesClaim uniques associées à chaque pod d'instance dupliquée.

Disques persistants régionaux

Les disques persistants régionaux sont des ressources multizonales qui répliquent les données entre deux zones d'une même région. Ils peuvent être utilisés de la même manière que les disques persistants zonaux. En cas de panne de zone, ou si les nœuds de cluster d'une zone donnée ne peuvent pas être planifiés, Kubernetes peut basculer des charges de travail en utilisant le volume sur l'autre zone. Vous pouvez créer des solutions hautement disponibles pour les charges de travail avec état sur GKE à l'aide des disques persistants régionaux. Vous devez vous assurer que les zones principale et de basculement sont configurées avec une capacité de ressources suffisante pour exécuter la charge de travail.

Les disques persistants SSD régionaux constituent une option pour les applications telles que les bases de données qui nécessitent à la fois une haute disponibilité et des performances élevées. Pour plus de détails, consultez la section Comparer les performances des options de stockage de blocs.

Comme pour les disques persistants zonaux, les disques persistants régionaux peuvent être provisionnés de manière dynamique, au besoin, ou manuellement par l'administrateur du cluster. Pour savoir comment ajouter des disques persistants régionaux, consultez la section Provisionner des disques persistants régionaux.

Zones dans des disques persistants

Les disques persistants zonaux sont des ressources zonales et les disques persistants régionaux sont des ressources multi-zonales. Lorsque vous ajoutez un espace de stockage persistant à votre cluster, GKE affecte le disque à une seule zone, sauf si une zone est déjà spécifiée. GKE choisit la zone au hasard. Une fois qu'un disque persistant est provisionné, tous les pods référençant le disque sont planifiés dans la même zone que le disque.

Mode de liaison de volume WaitForFirstConsumer

Si vous provisionnez dynamiquement un disque persistant dans votre cluster, nous vous recommandons de définir le WaitForFirstConsumer mode de liaison de volume sur votre StorageClass. Ce paramètre indique à Kubernetes de provisionner un disque persistant dans la même zone que celle où le pod est programmé. Il respecte les contraintes de planification des pods, telles que l'anti-affinité et les sélecteurs de nœuds. L'anti-affinité sur les zones permet de répartir les pods StatefulSet sur les zones avec les disques correspondants.

Voici un exemple de StorageClass pour le provisionnement de disques persistants zonaux qui définit WaitForFirstConsumer :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-balanced
  csi.storage.k8s.io/fstype: ext4
volumeBindingMode: WaitForFirstConsumer

Pour un exemple d'utilisation des disques persistants régionaux, consultez la section Provisionner des disques persistants régionaux.

Étape suivante