You are viewing documentation for Kubernetes version: v1.26
Kubernetes v1.26 documentation non maintenue. Vous consultez une version statique. Pour une documentation à jour, veuillez consulter: dernière version.
Volumes persistants
Ce document décrit l'état actuel de PersistentVolumes
dans Kubernetes.
Une connaissance des volumes est suggérée.
Introduction
La gestion du stockage est un problème distinct de la gestion des instances de calcul.
Le sous-système PersistentVolume
fournit une API pour les utilisateurs et les administrateurs qui abstrait les détails de la façon dont le stockage est fourni et de la façon dont il est utilisé.
Pour ce faire, nous introduisons deux nouvelles ressources API: PersistentVolume
et PersistentVolumeClaim
.
Un PersistentVolume
(PV) est un élément de stockage dans le cluster qui a été provisionné par un administrateur ou provisionné dynamiquement à l'aide de Storage Classes.
Il s'agit d'une ressource dans le cluster, tout comme un nœud est une ressource de cluster.
Les PV sont des plugins de volume comme Volumes, mais ont un cycle de vie indépendant de tout pod individuel qui utilise le PV.
Cet objet API capture les détails de l'implémentation du stockage, que ce soit NFS, iSCSI ou un système de stockage spécifique au fournisseur de cloud.
Un PersistentVolumeClaim
(PVC) est une demande de stockage par un utilisateur.
Il est similaire à un Pod.
Les pods consomment des ressources de noeud et les PVC consomment des ressources PV.
Les pods peuvent demander des niveaux spécifiques de ressources (CPU et mémoire).
Les PVC peuvent demander une taille et des modes d'accès spécifiques (par exemple, ils peuvent être montés une fois en lecture/écriture ou plusieurs fois en lecture seule).
Alors que les PersistentVolumeClaims
permettent à un utilisateur de consommer des ressources de stockage abstraites, il est courant que les utilisateurs aient besoin de PersistentVolumes
avec des propriétés et des performances variables pour différents problèmes.
Les administrateurs de cluster doivent être en mesure d'offrir une variété de PersistentVolumes
qui diffèrent de bien des façons plus que la taille et les modes d'accès, sans exposer les utilisateurs aux détails de la façon dont ces volumes sont mis en œuvre.
Pour ces besoins, il existe la ressource StorageClass
.
Voir la procédure détaillée avec des exemples.
Cycle de vie d'un PV et d'un PVC
Les PV sont des ressources du cluster. Les PVC sont des demandes pour ces ressources et agissent également comme des contrôles de réclamation pour la ressource. L'interaction entre les PV et les PVC suit ce cycle de vie:
Provisionnement
Les PV peuvent être provisionnés de deux manières: statiquement ou dynamiquement.
Provisionnement statique
Un administrateur de cluster crée un certain nombre de PV. Ils contiennent les détails du stockage réel, qui est disponible pour une utilisation par les utilisateurs du cluster. Ils existent dans l'API Kubernetes et sont disponibles pour la consommation.
Provisionnement dynamique
Lorsqu'aucun des PV statiques créés par l'administrateur ne correspond au PersistentVolumeClaim
d'un utilisateur, le cluster peut essayer de provisionner dynamiquement un volume spécialement pour le PVC.
Ce provisionnement est basé sur les StorageClasses
: le PVC doit demander une storage class et l'administrateur doit avoir créé et configuré cette classe pour que l'approvisionnement dynamique se produise.
Les PVC qui demandent la classe ""
désactive le provisionnement dynamique pour eux-mêmes.
Pour activer le provisionnement de stockage dynamique basé sur la classe de stockage, l'administrateur de cluster doit activer le DefaultStorageClass
dans l'contrôleur d'admission sur le serveur API.
Cela peut être fait, par exemple, en veillant à ce que DefaultStorageClass
figure parmi la liste de valeurs séparées par des virgules pour l'option --enable-admission-plugins
du composant serveur API.
Pour plus d'informations sur les options de ligne de commande du serveur API, consultez la documentation kube-apiserver.
Liaison
Un utilisateur crée, ou dans le cas d'un provisionnement dynamique, a déjà créé, un PersistentVolumeClaim
avec une quantité spécifique de stockage demandée et avec certains modes d'accès.
Une boucle de contrôle dans le maître surveille les nouveaux PVC, trouve un PV correspondant (si possible) et les lie ensemble.
Si un PV a été dynamiquement provisionné pour un nouveau PVC, la boucle liera toujours ce PV au PVC.
Sinon, l'utilisateur obtiendra toujours au moins ce qu'il a demandé, mais le volume peut être supérieur à ce qui a été demandé.
Une fois liées, les liaisons PersistentVolumeClaim
sont exclusives, quelle que soit la façon dont elles ont été liées.
Une liaison PVC-PV est une relation 1-à-1.
Les PVC resteront non liés indéfiniment s'il n'existe pas de volume correspondant. Le PVC sera lié à mesure que les volumes correspondants deviendront disponibles. Par exemple, un cluster provisionné avec de nombreux PV 50Gi ne correspondrait pas à un PVC demandant 100Gi. Le PVC peut être lié lorsqu'un PV 100Gi est ajouté au cluster.
Utilisation
Les Pods utilisent les PVC comme des volumes. Le cluster inspecte le PVC pour trouver le volume lié et monte ce volume pour un Pod. Pour les volumes qui prennent en charge plusieurs modes d'accès, l'utilisateur spécifie le mode souhaité lors de l'utilisation de leur PVC comme volume dans un Pod.
Une fois qu'un utilisateur a un PVC et que ce PVC est lié, le PV lié appartient à l'utilisateur aussi longtemps qu'il en a besoin.
Les utilisateurs planifient des pods et accèdent à leurs PV revendiqués en incluant un persistentVolumeClaim
dans le bloc de volumes de leur Pod Voir ci-dessous pour les détails de la syntaxe.
Protection de l'objet de stockage en cours d'utilisation
Le but de la fonction de protection des objets de stockage utilisés est de garantir que les revendications de volume persistantes (PVC) en cours d'utilisation par un Pod et les volumes persistants (PV) liés aux PVC ne sont pas supprimées du système, car cela peut entraîner des pertes de données.
Si un utilisateur supprime un PVC en cours d'utilisation par un pod, le PVC n'est pas supprimé immédiatement. L'élimination du PVC est différée jusqu'à ce que le PVC ne soit plus activement utilisé par les pods. De plus, si un administrateur supprime un PV lié à un PVC, le PV n'est pas supprimé immédiatement. L'élimination du PV est différée jusqu'à ce que le PV ne soit plus lié à un PVC.
Vous pouvez voir qu'un PVC est protégé lorsque son état est Terminating
et la liste Finalizers
inclus kubernetes.io/pvc-protection
:
kubectl describe pvc hostpath
Name: hostpath
Namespace: default
StorageClass: example-hostpath
Status: Terminating
Volume:
Labels: <none>
Annotations: volume.beta.kubernetes.io/storage-class=example-hostpath
volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath
Finalizers: [kubernetes.io/pvc-protection]
...
Vous pouvez voir qu'un PV est protégé lorsque son état est Terminating
et la liste Finalizers
inclus kubernetes.io/pv-protection
aussi:
kubectl describe pv task-pv-volume
Name: task-pv-volume
Labels: type=local
Annotations: <none>
Finalizers: [kubernetes.io/pv-protection]
StorageClass: standard
Status: Available
Claim:
Reclaim Policy: Delete
Access Modes: RWO
Capacity: 1Gi
Message:
Source:
Type: HostPath (bare host directory volume)
Path: /tmp/data
HostPathType:
Events: <none>
Récupération des volumes
Lorsqu'un utilisateur a terminé avec son volume, il peut supprimer les objets PVC de l'API qui permet la récupération de la ressource.
La politique de récupération pour un PersistentVolume
indique au cluster ce qu'il doit faire du volume une fois qu'il a été libéré de son PVC.
Actuellement, les volumes peuvent être conservés, recyclés ou supprimés.
Volumes conservés
La politique de récupération Retain
permet la récupération manuelle de la ressource.
Lorsque le PersistentVolumeClaim
est supprimé, le PersistentVolume
existe toujours et le volume est considéré comme «libéré».
Mais il n'est pas encore disponible pour une autre demande car les données du demandeur précédent restent sur le volume.
Un administrateur peut récupérer manuellement le volume en procédant comme suit.
- Supprimer le
PersistentVolume
. L'actif de stockage associé dans une infrastructure externe (comme un volume AWS EBS, GCE PD, Azure Disk ou Cinder) existe toujours après la suppression du PV. - Nettoyez manuellement les données sur l'actif de stockage associé en conséquence.
- Supprimez manuellement l'actif de stockage associé ou, si vous souhaitez réutiliser le même actif de stockage, créez un nouveau
PersistentVolume
avec la définition de l'actif de stockage.
Volumes supprimés
Pour les plug-ins de volume qui prennent en charge la stratégie de récupération Delete
, la suppression supprime à la fois l'objet PersistentVolume
de Kubernetes, ainsi que l'actif de stockage associé dans l'infrastructure externe, tel qu'un volume AWS EBS, GCE PD, Azure Disk ou Cinder.
Les volumes qui ont été dynamiquement provisionnés héritent de la politique de récupération de leur StorageClass
, qui par défaut est Delete
.
L'administrateur doit configurer la StorageClass
selon les attentes des utilisateurs; sinon, le PV doit être édité ou corrigé après sa création.
Voir Modifier la politique de récupération d'un PersistentVolume.
Volumes recyclés
Recycle
est obsolète.
Au lieu de cela, l'approche recommandée consiste à utiliser l'approvisionnement dynamique.
Si elle est prise en charge par le plug-in de volume sous-jacent, la stratégie de récupération Recycle
effectue un nettoyage de base (rm -rf /thevolume/*
) sur le volume et le rend à nouveau disponible pour une nouvelle demande.
Cependant, un administrateur peut configurer un modèle de module de recyclage personnalisé à l'aide des arguments de ligne de commande du gestionnaire de contrôleur Kubernetes, comme décrit ici.
Le modèle de pod de recycleur personnalisé doit contenir une définition de volumes
, comme le montre l'exemple ci-dessous:
apiVersion: v1
kind: Pod
metadata:
name: pv-recycler
namespace: default
spec:
restartPolicy: Never
volumes:
- name: vol
hostPath:
path: /any/path/it/will/be/replaced
containers:
- name: pv-recycler
image: "registry.k8s.io/busybox"
command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/* && test -z \"$(ls -A /scrub)\" || exit 1"]
volumeMounts:
- name: vol
mountPath: /scrub
Cependant, le chemin particulier spécifié dans la partie volumes
du template personnalisé de Pod est remplacée par le chemin particulier du volume qui est recyclé.
Redimensionnement des PVC
Kubernetes v1.24 [stable]
La prise en charge du redimensionnement des PersistentVolumeClaims (PVCs) est désormais activée par défaut. Vous pouvez redimensionner les types de volumes suivants:
- gcePersistentDisk
- awsElasticBlockStore
- Cinder
- glusterfs
- rbd
- Azure File
- Azure Disk
- Portworx
- FlexVolumes
- CSI
Vous ne pouvez redimensionner un PVC que si le champ allowVolumeExpansion
de sa classe de stockage est défini sur true.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: gluster-vol-default
provisioner: kubernetes.io/glusterfs
parameters:
resturl: "http://192.168.10.100:8080"
restuser: ""
secretNamespace: ""
secretName: ""
allowVolumeExpansion: true
Pour demander un volume plus important pour un PVC, modifiez l'objet PVC et spécifiez une taille plus grande.
Cela déclenche l'expansion du volume qui soutient le PersistentVolume
sous-jacent.
Un nouveau PersistentVolume
n'est jamais créé pour satisfaire la demande.
Au lieu de cela, un volume existant est redimensionné.
Redimensionnement de volume CSI
Kubernetes v1.24 [stable]
La prise en charge du redimensionnement des volumes CSI est activée par défaut, mais elle nécessite également un pilote CSI spécifique pour prendre en charge le redimensionnement des volumes. Reportez-vous à la documentation du pilote CSI spécifique pour plus d'informations.
Redimensionner un volume contenant un système de fichiers
Vous ne pouvez redimensionner des volumes contenant un système de fichiers que si le système de fichiers est XFS, Ext3 ou Ext4.
Lorsqu'un volume contient un système de fichiers, le système de fichiers n'est redimensionné que lorsqu'un nouveau pod utilise le PersistentVolumeClaim
en mode ReadWrite.
L'extension du système de fichiers est effectuée au démarrage d'un pod ou lorsqu'un pod est en cours d'exécution et que le système de fichiers sous-jacent prend en charge le redimensionnement en ligne.
FlexVolumes autorise le redimensionnement si le pilote est défini avec la capacité requiresFSResize
sur true
.
Le FlexVolume peut être redimensionné au redémarrage du pod.
Redimensionnement d'un PersistentVolumeClaim en cours d'utilisation
Kubernetes v1.15 [beta]
ExpandInUsePersistentVolumes
doit être activée, ce qui est le cas automatiquement pour de nombreux clusters de fonctionnalités bêta.
Se référer à la documentation de la feature gate pour plus d'informations.
Dans ce cas, vous n'avez pas besoin de supprimer et de recréer un pod ou un déploiement qui utilise un PVC existant. Tout PVC en cours d'utilisation devient automatiquement disponible pour son pod dès que son système de fichiers a été étendu. Cette fonctionnalité n'a aucun effet sur les PVC qui ne sont pas utilisés par un pod ou un déploiement. Vous devez créer un pod qui utilise le PVC avant que l'extension puisse se terminer.
Semblable à d'autres types de volume - les volumes FlexVolume peuvent également être étendus lorsqu'ils sont utilisés par un pod.
Types de volumes persistants
Les types PersistentVolume
sont implémentés en tant que plugins.
Kubernetes prend actuellement en charge les plugins suivants:
- GCEPersistentDisk
- AWSElasticBlockStore
- AzureFile
- AzureDisk
- CSI
- FC (Fibre Channel)
- FlexVolume
- Flocker
- NFS
- iSCSI
- RBD (Ceph Block Device)
- CephFS
- Cinder (OpenStack block storage)
- Glusterfs
- VsphereVolume
- Quobyte Volumes
- HostPath (Test de nœud unique uniquement -- le stockage local n'est en aucun cas pris en charge et NE FONCTIONNERA PAS dans un cluster à plusieurs nœuds)
- Portworx Volumes
- ScaleIO Volumes
- StorageOS
Volumes persistants
Chaque PV contient une spécification et un état, qui sont les spécifications et l'état du volume.
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0003
spec:
capacity:
storage: 5Gi
volumeMode: Filesystem
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
storageClassName: slow
mountOptions:
- hard
- nfsvers=4.1
nfs:
path: /tmp
server: 172.17.0.2
/sbin/mount.nfs
est requis pour permettre de monter des systèmes de fichiers de type NFS.
Capacité
Généralement, un PV aura une capacité de stockage spécifique.
Ceci est réglé en utilisant l'attribut capacity
des PV.
Voir le Kubernetes modèle de ressource pour comprendre les unités attendues par capacity
.
Actuellement, la taille du stockage est la seule ressource qui peut être définie ou demandée. Les futurs attributs peuvent inclure les IOPS, le débit, etc.
Mode volume
Kubernetes v1.13 [beta]
Avant Kubernetes 1.9, tous les plug-ins de volume créaient un système de fichiers sur le volume persistant.
Maintenant, vous pouvez définir la valeur de volumeMode
sur block
pour utiliser un périphérique de bloc brut, ou filesystem
pour utiliser un système de fichiers.
filesystem
est la valeur par défaut si la valeur est omise.
Il s'agit d'un paramètre API facultatif.
Modes d'accès
Un PersistentVolume
peut être monté sur un hôte de n'importe quelle manière prise en charge par le fournisseur de ressources.
Comme indiqué dans le tableau ci-dessous, les fournisseurs auront des capacités différentes et les modes d'accès de chaque PV sont définis sur les modes spécifiques pris en charge par ce volume particulier.
Par exemple, NFS peut prendre en charge plusieurs clients en lecture/écriture, mais un PV NFS spécifique peut être exporté sur le serveur en lecture seule.
Chaque PV dispose de son propre ensemble de modes d'accès décrivant les capacités spécifiques de ce PV.
Les modes d'accès sont:
- ReadWriteOnce -- le volume peut être monté en lecture-écriture par un seul nœud
- ReadOnlyMany -- le volume peut être monté en lecture seule par plusieurs nœuds
- ReadWriteMany -- le volume peut être monté en lecture-écriture par de nombreux nœuds
Dans la CLI, les modes d'accès sont abrégés comme suit:
- RWO - ReadWriteOnce
- ROX - ReadOnlyMany
- RWX - ReadWriteMany
Important! Un volume ne peut être monté qu'en utilisant un seul mode d'accès à la fois, même s'il prend en charge plusieurs. Par exemple, un GCEPersistentDisk peut être monté en tant que ReadWriteOnce par un seul nœud ou ReadOnlyMany par plusieurs nœuds, mais pas en même temps.
Volume Plugin | ReadWriteOnce | ReadOnlyMany | ReadWriteMany |
---|---|---|---|
AWSElasticBlockStore | ✓ | - | - |
AzureFile | ✓ | ✓ | ✓ |
AzureDisk | ✓ | - | - |
CephFS | ✓ | ✓ | ✓ |
Cinder | ✓ | - | - |
CSI | dépend du pilote | dépend du pilote | dépend du pilote |
FC | ✓ | ✓ | - |
FlexVolume | ✓ | ✓ | dépend du pilote |
Flocker | ✓ | - | - |
GCEPersistentDisk | ✓ | ✓ | - |
Glusterfs | ✓ | ✓ | ✓ |
HostPath | ✓ | - | - |
iSCSI | ✓ | ✓ | - |
Quobyte | ✓ | ✓ | ✓ |
NFS | ✓ | ✓ | ✓ |
RBD | ✓ | ✓ | - |
VsphereVolume | ✓ | - | - (fonctionne lorsque les pods sont colocalisés) |
PortworxVolume | ✓ | - | ✓ |
ScaleIO | ✓ | ✓ | - |
StorageOS | ✓ | - | - |
Classe
Un PV peut avoir une classe, qui est spécifiée en définissant l'attribut storageClassName
sur le nom d'une StorageClass.
Un PV d'une classe particulière ne peut être lié qu'à des PVC demandant cette classe.
Un PV sans storageClassName
n'a pas de classe et ne peut être lié qu'à des PVC qui ne demandent aucune classe particulière.
Dans le passé, l'annotation volume.beta.kubernetes.io/storage-class
a été utilisé à la place de l'attribut storageClassName
.
Cette annotation fonctionne toujours; cependant, il deviendra complètement obsolète dans une future version de Kubernetes.
Politique de récupération
Les politiques de récupération actuelles sont:
- Retain -- remise en état manuelle
- Recycle -- effacement de base (
rm -rf /thevolume/*
) - Delete -- l'élément de stockage associé tel qu'AWS EBS, GCE PD, Azure Disk ou le volume OpenStack Cinder est supprimé
Actuellement, seuls NFS et HostPath prennent en charge le recyclage. Les volumes AWS EBS, GCE PD, Azure Disk et Cinder prennent en charge la suppression.
Options de montage
Un administrateur Kubernetes peut spécifier des options de montage supplémentaires pour quand un PersistentVolume
est monté sur un nœud.
Les types de volume suivants prennent en charge les options de montage:
- AWSElasticBlockStore
- AzureDisk
- AzureFile
- CephFS
- Cinder (OpenStack block storage)
- GCEPersistentDisk
- Glusterfs
- NFS
- Quobyte Volumes
- RBD (Ceph Block Device)
- StorageOS
- VsphereVolume
- iSCSI
Les options de montage ne sont pas validées, donc le montage échouera simplement si l'une n'est pas valide.
Dans le passé, l'annotation volume.beta.kubernetes.io/mount-options
était utilisée à la place de l'attribut mountOptions
.
Cette annotation fonctionne toujours; cependant, elle deviendra complètement obsolète dans une future version de Kubernetes.
Affinité des nœuds
Un PV peut spécifier une affinité de nœud pour définir les contraintes qui limitent les nœuds à partir desquels ce volume est accessible. Les pods qui utilisent un PV seront uniquement planifiés sur les nœuds sélectionnés par l'affinité de nœud.
Phase
Un volume sera dans l'une des phases suivantes:
- Available -- une ressource libre qui n'est pas encore liée à une demande
- Bound -- le volume est lié à une demande
- Released -- la demande a été supprimée, mais la ressource n'est pas encore récupérée par le cluster
- Failed -- le volume n'a pas réussi sa récupération automatique
Le CLI affichera le nom du PVC lié au PV.
PersistentVolumeClaims
Chaque PVC contient une spécification et un état, qui sont les spécifications et l'état de la réclamation.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: myclaim
spec:
accessModes:
- ReadWriteOnce
volumeMode: Filesystem
resources:
requests:
storage: 8Gi
storageClassName: slow
selector:
matchLabels:
release: "stable"
matchExpressions:
- {key: environment, operator: In, values: [dev]}
Modes d'accès
Les PVC utilisent les mêmes conventions que les volumes lorsque vous demandez un stockage avec des modes d'accès spécifiques.
Modes de volume
Les PVC utilisent la même convention que les volumes pour indiquer la consommation du volume en tant que système de fichiers ou périphérique de bloc.
Ressources
Les PVC, comme les pods, peuvent demander des quantités spécifiques d'une ressource. Dans ce cas, la demande concerne le stockage. Le même modèle de ressource s'applique aux volumes et aux PVC.
Sélecteur
Les PVC peuvent spécifier un sélecteur de labels pour filtrer davantage l'ensemble des volumes. Seuls les volumes dont les étiquettes correspondent au sélecteur peuvent être liés au PVC. Le sélecteur peut comprendre deux champs:
matchLabels
- le volume doit avoir un label avec cette valeurmatchExpressions
- une liste des exigences définies en spécifiant la clé, la liste des valeurs et l'opérateur qui relie la clé et les valeurs. Les opérateurs valides incluent In, NotIn, Exists et DoesNotExist.
Toutes les exigences, à la fois de matchLabels
et de matchExpressions
doivent toutes être satisfaites pour correspondre (application d'un opérateur booléen ET).
Classe
Un PVC peut demander une classe particulière en spécifiant le nom d'une StorageClass en utilisant l'attribut storageClassName
.
Seuls les PV de la classe demandée, ceux ayant le même storageClassName
que le PVC, peuvent être liés au PVC.
Les PVC n'ont pas nécessairement à demander une classe.
Un PVC avec son attribut storageClassName
égal à ""
est toujours interprété comme demandant un PV sans classe, il ne peut donc être lié qu'à des PV sans classe (pas d'annotation ou une annotation égal à ""
).
Un PVC sans storageClassName
n'est pas tout à fait la même et est traité différemment par le cluster, selon que le DefaultStorageClass
admission plugin est activé.
- Si le plug-in d'admission est activé, l'administrateur peut spécifier une valeur par défaut
StorageClass
. Tous les PVC qui n'ont pas destorageClassName
ne peuvent être liés qu'aux PV de cette valeur par défaut. La spécification d'uneStorageClass
par défaut se fait en définissant l'annotationstorageclass.kubernetes.io/is-default-class
égal àtrue
dans un objetStorageClass
. Si l'administrateur ne spécifie pas de valeur par défaut, le cluster répond à la création de PVC comme si le plug-in d'admission était désactivé. Si plusieurs valeurs par défaut sont spécifiées, le plugin d'admission interdit la création de tous les PVC. - Si le plugin d'admission est désactivé, il n'y a aucune notion de défaut
StorageClass
. Tous les PVC qui n'ont passtorageClassName
peut être lié uniquement aux PV qui n'ont pas de classe. Dans ce cas, les PVC qui n'ont passtorageClassName
sont traités de la même manière que les PVC qui ont leurstorageClassName
égal à""
.
Selon la méthode d'installation, une StorageClass
par défaut peut être déployée sur un cluster Kubernetes par le gestionnaire d'extensions pendant l'installation.
Lorsqu'un PVC spécifie un selector
en plus de demander une StorageClass
, les exigences sont ET ensemble: seul un PV de la classe demandée et avec les labels demandées peut être lié au PVC.
selector
non vide ne peut pas avoir un PV provisionné dynamiquement pour cela.
Dans le passé, l'annotation volume.beta.kubernetes.io/storage-class
a été utilisé au lieu de l'attribut storageClassName
.
Cette annotation fonctionne toujours; cependant, elle ne sera pas pris en charge dans une future version de Kubernetes.
PVC sous forme de volumes
Les pods accèdent au stockage en utilisant le PVC comme volume.
Les PVC et les pods qui les utilisent doivent exister dans le même namespace.
Le cluster trouve le PVC dans le namespace où se trouve le pod et l'utilise pour obtenir le PersistentVolume
visé par le PVC.
Le volume est ensuite monté sur l'hôte et dans le pod.
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: myfrontend
image: nginx
volumeMounts:
- mountPath: "/var/www/html"
name: mypd
volumes:
- name: mypd
persistentVolumeClaim:
claimName: myclaim
Remarque au sujet des namespaces
Les liaisons PersistentVolumes
sont exclusives, et comme les objets PersistentVolumeClaims
sont des objets vivant dans un namespace donné, le montage de PVC avec les modes "Many" (ROX
, RWX
) n'est possible qu'au sein d'un même namespace.
Prise en charge du volume de bloc brut
Kubernetes v1.13 [beta]
Les plug-ins de volume suivants prennent en charge les volumes de blocs bruts, y compris l'approvisionnement dynamique, le cas échéant:
- AWSElasticBlockStore
- AzureDisk
- FC (Fibre Channel)
- GCEPersistentDisk
- iSCSI
- Local volume
- RBD (Ceph Block Device)
- VsphereVolume (alpha)
Volumes persistants utilisant un volume de bloc brut
apiVersion: v1
kind: PersistentVolume
metadata:
name: block-pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
volumeMode: Block
persistentVolumeReclaimPolicy: Retain
fc:
targetWWNs: ["50060e801049cfd1"]
lun: 0
readOnly: false
Revendication de volume persistant demandant un volume de bloc brut
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: block-pvc
spec:
accessModes:
- ReadWriteOnce
volumeMode: Block
resources:
requests:
storage: 10Gi
Spécification de pod ajoutant le chemin du périphérique de bloc brut dans le conteneur
apiVersion: v1
kind: Pod
metadata:
name: pod-with-block-volume
spec:
containers:
- name: fc-container
image: fedora:26
command: ["/bin/sh", "-c"]
args: [ "tail -f /dev/null" ]
volumeDevices:
- name: data
devicePath: /dev/xvda
volumes:
- name: data
persistentVolumeClaim:
claimName: block-pvc
Lier des volumes bloc bruts
Si un utilisateur demande un volume de bloc brut en l'indiquant à l'aide du champ volumeMode
dans la spécification PersistentVolumeClaim
, les règles de liaison diffèrent légèrement des versions précédentes qui ne considéraient pas ce mode comme faisant partie de la spécification.
Voici un tableau des combinaisons possibles que l'utilisateur et l'administrateur peuvent spécifier pour demander un périphérique de bloc brut.
Le tableau indique si le volume sera lié ou non compte tenu des combinaisons:
Matrice de liaison de volume pour les volumes provisionnés statiquement:
| PV volumeMode | PVC volumeMode | Result | |---------------|-:-:------------|--:------| | unspecified | unspecified | BIND | | unspecified | Block | NO BIND | | unspecified | Filesystem | BIND | | Block | unspecified | NO BIND | | Block | Block | BIND | | Block | Filesystem | NO BIND | | Filesystem | Filesystem | BIND | | Filesystem | Block | NO BIND | | Filesystem | unspecified | BIND |
Snapshot et restauration de volumes
Kubernetes v1.12 [alpha]
La fonction de snapshot de volume a été ajoutée pour prendre en charge uniquement les plug-ins de volume CSI. Pour plus de détails, voir volume snapshots.
Pour activer la prise en charge de la restauration d'un volume à partir d'un snapshot de volume, activez la fonctionnalité VolumeSnapshotDataSource
sur l'apiserver et le controller-manager.
Créer du PVC à partir d'un snapshot de volume
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: restore-pvc
spec:
storageClassName: csi-hostpath-sc
dataSource:
name: new-snapshot-test
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
Clonage de volume
Kubernetes v1.16 [beta]
La fonctionnalité de clonage de volume a été ajoutée pour prendre en charge uniquement les plug-ins de volume CSI. Pour plus de détails, voir clonage de volume.
Pour activer la prise en charge du clonage d'un volume à partir d'une source de données PVC, activez la propriété VolumePVCDataSource
sur l'apiserver et le controller-manager.
Créer un PVC à partir d'un PVC existant
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: cloned-pvc
spec:
storageClassName: my-csi-plugin
dataSource:
name: existing-src-pvc-name
kind: PersistentVolumeClaim
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
Écriture d'une configuration portable
Si vous écrivez des templates de configuration ou des exemples qui s'exécutent sur une large gamme de clusters et nécessitent un stockage persistant, il est recommandé d'utiliser le modèle suivant:
- Incluez des objets
PersistentVolumeClaim
dans votre ensemble de config (aux côtés deDeployments
,ConfigMaps
, etc.). - N'incluez pas d'objets
PersistentVolume
dans la configuration, car l'utilisateur qui instancie la configuration peut ne pas être autorisé à créer desPersistentVolumes
. - Donnez à l'utilisateur la possibilité de fournir un nom de classe de stockage lors de l'instanciation du template.
- Si l'utilisateur fournit un nom de classe de stockage, mettez cette valeur dans le champ
persistentVolumeClaim.storageClassName
. Cela entraînera le PVC pour utiliser la bonne classe de stockage si le cluster a cetteStorageClasses
activé par l'administrateur. - Si l'utilisateur ne fournit pas de nom de classe de stockage, laissez le champ
persistentVolumeClaim.storageClassName
à zéro. Cela entraînera un PV à être automatiquement provisionné pour l'utilisateur avec laStorageClass
par défaut dans le cluster. De nombreux environnements de cluster ont uneStorageClass
par défaut installée, où les administrateurs peuvent créer leur propreStorageClass
par défaut.
- Si l'utilisateur fournit un nom de classe de stockage, mettez cette valeur dans le champ
- Dans votre outillage, surveillez les PVCs qui ne sont pas liés après un certain temps et signalez-le à l'utilisateur, car cela peut indiquer que le cluster n'a pas de support de stockage dynamique (auquel cas l'utilisateur doit créer un PV correspondant) ou que le cluster n'a aucun système de stockage (auquel cas l'utilisateur ne peut pas déployer de configuration nécessitant des PVCs).