Volumes persistants | Kubernetes

Les informations contenues dans ce document peuvent être obsolètes
Ce document a une date de mise à jour antérieure à celle de l'original, les informations qu'il contient peuvent donc être obsolètes. Si vous comprenez l'anglais, consultez la version anglaise pour obtenir les informations les plus récentes : Persistent Volumes
Ce document décrit l'état actuel de PersistentVolumes dans Kubernetes. Une connaissance des volumes est suggérée.
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.
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:
Les PV peuvent être provisionnés de deux manières: statiquement ou dynamiquement.
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.
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.
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.
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.
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 utilisate