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, les ressources PersistentVolume
sont généralement sauvegardées 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 section Accéder aux partages de fichiers depuis les clusters Google Kubernetes Engine 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. Pour obtenir des exemples, consultez la section Cloud Volumes Service pour Google Cloud.
Contrairement aux ressources Volumes, le cycle de vie des ressources 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 Kubernetes.
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 mises en œuvre de volumes telles que gcePersistentDisk
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.
Provisionner dynamiquement des ressources PersistentVolume
La plupart du temps, il n'est pas nécessaire de configurer directement les objets PersistentVolume
ni de créer des disques persistants Compute Engine. À la place, vous pouvez créer une PersistentVolumeClaim
et Kubernetes provisionne automatiquement un disque persistant pour vous.
Le fichier manifeste ci-dessous décrit une requête pour un disque de 30 gigaoctets (Gio) dont le mode d'accès lui permet d'être installé en lecture/écriture par un seul nœud :
# pvc-demo.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-demo
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 30Gi
Lorsque vous créez cet objet PersistentVolumeClaim
à l'aide de kubectl apply -f
pvc-demo.yaml
, Kubernetes crée dynamiquement un objet PersistentVolume
correspondant. L'exemple suivant montre la ressource PersistentVolume
créée.
apiVersion: v1
kind: PersistentVolume
metadata:
name: pvc-cd3fd5e9-695a-11ea-a3da-42010a800003
uid: ced478c1-695a-11ea-a3da-42010a800003
annotations:
kubernetes.io/createdby: gce-pd-dynamic-provisioner
pv.kubernetes.io/bound-by-controller: "yes"
pv.kubernetes.io/provisioned-by: kubernetes.io/gce-pd
spec:
accessModes:
- ReadWriteOnce
capacity:
storage: 30Gi
claimRef:
apiVersion: v1
kind: PersistentVolumeClaim
name: pvc-demo
uid: cd3fd5e9-695a-11ea-a3da-42010a800003
gcePersistentDisk:
fsType: ext4
pdName: gke-cluster-1-pvc-cd3fd5e9-695a-11ea-a3da-42010a800003
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: topology.kubernetes.io/zone
operator: In
values:
- us-central1-c
- key: topology.kubernetes.io/region
operator: In
values:
- us-central1
persistentVolumeReclaimPolicy: Delete
storageClassName: standard
volumeMode: Filesystem
status:
phase: Bound
Si nous partons du principe que vous n'avez pas remplacé la classe de stockage par défaut GKE, ce PersistentVolume
est sauvegardé par un nouveau disque persistant Compute Engine vide. Utilisez ce disque dans un pod en vous servant de la demande comme volume.
Lorsque vous supprimez une revendication, l'objet PersistentVolume
correspondant et le disque persistant Compute Engine provisionné sont également supprimés.
Si vous souhaitez empêcher la suppression de disques persistants provisionnés de manière dynamique, définissez la stratégie de récupération de la ressource PersistentVolume
ou de sa ressource StorageClass
sur Retain
. Dans ce cas, le disque persistant vous est facturé tant qu'il existe, même s'il n'a été utilisé par aucune PersistentVolumeClaim.
Pour obtenir des exemples sur la façon de modifier la règle de récupération, consultez les sections Modifier la règle de récupération d'une ressource PersistentVolume et Ressource StorageClass.
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.
Consultez cet article afin d'obtenir des instructions sur la création de disques persistants pour plusieurs lecteurs.
Utiliser des disques persistants préexistants en tant que PersistentVolumes
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 modèles PersistentVolumeClaim
ou 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 comportant les modes ReadOnlyMany ou 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.
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: kubernetes.io/gce-pd
parameters:
type: pd-standard
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.