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.
Pour éviter ou limiter la perte de données lorsque vous supprimez le stockage persistant, nous vous recommandons d'activer Sauvegarde pour GKE et de planifier des sauvegardes régulières de votre cluster GKE, y compris les charges de travail déployées et leurs données.
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
- Découvrez les StatefulSets, qui constituent la méthode recommandée pour déployer des applications avec état.
- Apprenez à déployer une application avec état à l'aide d'un StatefulSet.
- Apprenez à utiliser des disques persistants dans un cluster.
- Découvrez comment créer un disque pouvant être lu à partir de plusieurs nœuds.
- Apprenez à créer des disques persistants sauvegardés par des disques SSD.
- Découvrez comment provisionner des disques persistants régionaux.