Cette rubrique explique comment utiliser des volumes persistants et des classes de stockage pour implémenter le stockage dynamique pour les clusters de charge de travail Tanzu Kubernetes Grid (TKG).
Dans un cluster Kubernetes, les objets PersistentVolume
(PV) fournissent un stockage partagé pour les espaces de cluster qui ne sont pas affectés par les cycles de vie des espaces. Le stockage est provisionné au volume persistant via un objet PersistentVolumeClaim
(PVC), qui définit la quantité et la manière dont l'espace accède au stockage sous-jacent. Pour plus d'informations, reportez-vous à la section Volumes persistants de la documentation Kubernetes.
Les administrateurs de cluster peuvent définir des objets StorageClass
qui permettent aux utilisateurs du cluster de créer dynamiquement des objets PVC et PV avec différents types et règles de stockage. Tanzu Kubernetes Grid fournit également des objets StorageClass
par défaut qui permettent aux utilisateurs de provisionner un stockage persistant dans un environnement clé en main.
Les objets StorageClass
incluent un champ provisioner
identifiant le plug-in de service interne ou externe qui provisionne les volumes persistants, ainsi qu'un champ parameters
qui associe la classe de stockage Kubernetes aux options de stockage définies au niveau de l'infrastructure, telles que les stratégies de stockage de machine virtuelle dans vSphere. Pour plus d'informations, reportez-vous à la section Classes de stockage de la documentation de Kubernetes.
Tanzu Kubernetes Grid prend en charge les objets StorageClass
pour différents types de stockage, provisionnés par des plug-ins Kubernetes internes (« dans l'arborescence ») ou externes (« hors arborescence »).
Types de stockage
RemarquevSphere CSI ne prend pas en charge les DRS de stockage et prend en charge Storage vMotion dans les conditions décrites dans la section Fonctionnalité vSphere prise en charge par le plug-in de stockage de conteneur vSphere de la documentation vSphere CSI.
vSphere CSI prend en charge Storage vMotion sous certaines conditions. Consultez la documentation de CSI pour plus de détails.
Reportez-vous à la section Classes de stockage par défaut pour obtenir les classes de stockage vSphere CNS, Amazon EBS et Disque Azure par défaut.
Provisionnement externe
Dans TKG v2.1, toutes les classes de stockage par défaut utilisent le provisionnement de stockage externe (« hors arborescence ») et non le provisionnement « dans l'arborescence ».
provisioner
de l'objet StorageClass
ne sont pas précédées de kubernetes.io
.Tanzu Kubernetes Grid fournit des objets StorageClass
par défaut qui permettent aux utilisateurs du cluster de charge de travail de provisionner un stockage persistant sur leur infrastructure dans un environnement clé en main, sans avoir besoin d'objets StorageClass
créés par un administrateur de cluster.
La variable ENABLE_DEFAULT_STORAGE_CLASS
est définie par défaut sur true
dans le fichier de configuration du cluster transmis à l'option --file
de tanzu cluster create
, afin d'activer la classe de stockage par défaut pour un cluster de charge de travail.
ImportantNe modifiez pas les définitions de classe de stockage par défaut. Pour personnaliser une classe de stockage, créez une définition
StorageClass
avec unname
différent au lieu de modifier l'objet par défaut créé par TKG.
Les définitions de classe de stockage Tanzu Kubernetes Grid par défaut sont les suivantes :
vSphere CNS
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: default
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: csi.vsphere.vmware.com
parameters:
storagePolicyName: optional
Reportez-vous aux paramètres de classe de stockage CSI vSphere dans la documentation de Kubernetes.
Amazon EBS
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: default
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.aws.com
Reportez-vous aux paramètres de classe de stockage Pilote CSI Amazon EBS dans la documentation d'AWS.
Disque Azure
apiVersion: storage.k8s.io/v1beta1
kind: StorageClass
metadata:
name: default
annotations:
storageclass.beta.kubernetes.io/is-default-class: "true"
labels:
kubernetes.io/cluster-service: "true"
provisioner: disk.csi.azure.com
parameters:
kind: Managed
storageaccounttype: Standard_LRS
cachingmode: ReadOnly
volumeBindingMode: WaitForFirstConsumer
Reportez-vous aux paramètres de classe de stockage Pilote CSI Disque Azure dans la documentation d'Azure.
Fichier Azure
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: azure-file
labels:
kubernetes.io/cluster-service: "true"
provisioner: file.csi.azure.com
mountOptions:
- dir_mode=0777
- file_mode=0777
- uid=0
- gid=0
- mfsymlinks
- cache=strict
- actimeo=30
allowVolumeExpansion: true
parameters:
skuName: Premium_LRS
Reportez-vous aux paramètres de classe de stockage Fichier Azure dans la documentation de Kubernetes.
Les administrateurs vSphere peuvent configurer vSphere CNS et créer des stratégies de stockage pour le stockage de disque virtuel (VMDK), en fonction des besoins des utilisateurs du cluster Tanzu Kubernetes Grid.
Vous pouvez utiliser vSAN ou un VMFS local (Virtual Machine File System) pour le stockage persistant dans un cluster Kubernetes, comme suit :
Stockage vSAN :
Pour créer une stratégie de stockage pour le stockage vSAN dans vSphere Client, accédez à Accueil (Home) > Stratégies et profils (Policies and Profiles) > Stratégies de stockage VM (VM Storage Policies) et cliquez sur Créer (Create) pour lancer l'assistant Créer une stratégie de stockage VM (Create VM Storage Policy).
Suivez les instructions de la section Créer une stratégie de stockage dans la documentation de vSphere. Assurez-vous d'effectuer les actions suivantes :
storagePolicyName
dans les objets StorageClass
.Stockage VMFS local :
Pour créer une stratégie de stockage pour le stockage local, appliquez une balise au stockage et créez une stratégie de stockage basée sur cette balise comme suit :
Dans le menu vSphere de niveau supérieur, sélectionnez Balises et attributs personnalisés (Tags & Custom Attributes).
Dans le volet Balises (Tags), sélectionnez Catégories et cliquez sur Nouveau (New).
Entrez un nom de catégorie, tel que tkg-storage
. Utilisez les cases à cocher pour l'associer au Centre de données (Datacenter) et aux objets de stockage, Dossier (Folder) et Banque de données (Datastore). Cliquez sur Créer.
Dans la vue Stockage (Storage) de niveau supérieur, sélectionnez votre volume VMFS et, dans son volet Résumé (Summary), cliquez sur Balises (Tags) > Attribuer (Assign)….
Dans la fenêtre contextuelle Attribuer une balise (Assign Tag), cliquez sur Ajouter une balise (Add Tag).
Dans la fenêtre contextuelle Créer une balise (Create Tag), attribuez-lui un nom, tel que tkg-storage-ds1
et attribuez-lui la Catégorie (Category) que vous avez créée. Cliquez sur OK.
Dans Attribuer une balise (Assign Tag), sélectionnez la balise et cliquez sur Attribuer (Assign).
Dans le menu vSphere de niveau supérieur, sélectionnez Stratégies de stockage VM (VM Storage Policies) > Créer une stratégie de stockage (Create a Storage Policy). Un assistant de configuration démarre.
Dans le volet Nom et description (Name and description), entrez un nom pour votre stratégie de stockage. Enregistrez le nom de la stratégie de stockage pour référence comme valeur storagePolicyName
dans les objets StorageClass
.
Dans le volet Structure de la stratégie (Policy structure), sous Règles spécifiques à la banque de données (Datastore specific rules), sélectionnez Activer les règles de placement basées sur des balises (Enable tag-based placement rules).
Dans le volet Placement basé sur des balises (Tag based placement), cliquez sur Ajouter une règle de balise (Add Tag Rule) et configurez les éléments suivants :
Use storage tagged with
Confirmez et configurez les autres volets ou acceptez les valeurs par défaut selon vos besoins, puis cliquez sur Vérifier et terminer (Review and finish). Sélectionnez Terminer (Finish) pour créer la stratégie de stockage.
Les administrateurs de cluster peuvent créer une classe de stockage comme suit :
StorageClass
Kubernetes.
.yaml
de configuration StorageClass
avec provisioner
, parameters
et d'autres options.
storagePolicyName
sur le nom de la stratégie de stockage vSphere, sous la forme d'une chaîne entre guillemets doubles.kubectl create -f
.kubectl describe storageclass <storageclass metadata.name>
.Pour obtenir un exemple, reportez-vous à la section Activer le provisionnement dynamique dans la documentation de Kubernetes.
Pour obtenir des informations et des ressources sur vSphere CSI, reportez-vous à la documentation Plug-in de stockage de conteneur VMware vSphere.
Pour provisionner un stockage persistant pour les nœuds de cluster qui n'utilisent pas l'une des Classes de stockage par défaut décrites ci-dessus, les utilisateurs du cluster incluent une classe de stockage personnalisée dans une configuration d'espace comme suit :
Définissez le contexte de kubectl
sur le cluster. Par exemple :
kubectl config use-context my-cluster-admin@my-cluster
Sélectionnez ou créez une classe de stockage.
kubectl get storageclass
.Créer une PVC et son PV :
.yaml
de configuration PersistentVolumeClaim
avec spec.storageClassName
défini sur la valeur metadata.name
de votre objet StorageClass
. Pour obtenir un exemple, reportez-vous à la section Activer le provisionnement dynamique dans la documentation de Kubernetes.kubectl create -f
.kubectl describe pvc <pvc metadata.name>
pour vérifier la PVC.kubectl describe pvc
après Successfully provisioned volume
.kubectl describe pv <pv unique name>
pour vérifier le PV.Créez un espace utilisant la PVC :
.yaml
de configuration Pod
qui définit spec.volumes
pour inclure votre PVC sous persistentVolumeClaim.claimName
. Pour obtenir un exemple, reportez-vous à la section Provisionner dynamiquement un volume de blocs avec le plug-in de stockage de conteneur vSphere dans la documentation Plug-in de stockage de conteneur vSphere.kubectl create -f
.kubectl get pod <pod metadata.name>
pour vérifier l'espace.Pour activer l'extension de volume pour le stockage vSphere CSI utilisé par les clusters de charge de travail, vous devez ajouter un espace complémentaire csi-resizer
aux processus CSI du cluster.
La configuration CSI des clusters de charge de travail est codée en tant que secret Kubernetes. Cette procédure ajoute le processus csi-resizer
en révisant le secret de configuration CSI. Il ajoute au secret une définition stringData
qui combine deux chaînes de données de configuration codées : une chaîne values.yaml
contenant les données de configuration CSI antérieures du secret et une nouvelle chaîne overlays.yaml
qui déploie l'espace csi-resizer
.
RemarqueL'extension de volume en ligne est prise en charge dans vSphere 7.0 à partir de la version Update 2. Reportez-vous à la section Extension de volume dans vSphere with Tanzu.
Connectez-vous au cluster de gestion pour le cluster de charge de travail que vous modifiez et exécutez tanzu cluster list
si vous devez récupérer le nom du cluster de charge de travail.
Récupérez le nom du secret CSI pour le cluster de charge de travail, à l'aide des sélecteurs d'étiquette vsphere-csi
et du nom du cluster :
$ kubectl get secret \
-l tkg.tanzu.vmware.com/cluster-name=NAME_OF_WORKLOAD_CLUSTER \
-l tkg.tanzu.vmware.com/addon-name=vsphere-csi
my-wc-vsphere-csi-secret
Enregistrez une sauvegarde du contenu du secret au format YAML dans vsphere-csi-secret.yaml
:
kubectl get secret my-wc-vsphere-csi-secret -o yaml > vsphere-csi-secret.yaml
Générez à nouveau le contenu actuel du secret, avec les valeurs data.values
décodées en base64
dans un fichier YAML brut.
$ kubectl get secret my-wc-vsphere-csi-secret -o jsonpath={.data.values\\.yaml} | base64 -d
#@data/values
#@overlay/match-child-defaults missing_ok=True
---
vsphereCSI:
CSIAttacherImage:
repository: projects.registry.vmware.com/tkg
path: csi/csi-attacher
tag: v3.0.0_vmware.1
pullPolicy: IfNotPresent
vsphereCSIControllerImage:
repository: projects.registry.vmware.com/tkg
path: csi/vsphere-block-csi-driver
tag: v2.1.1_vmware.1
pullPolicy: IfNotPresent
livenessProbeImage:
repository: projects.registry.vmware.com/tkg
path: csi/csi-livenessprobe
tag: v2.1.1_vmware.1
pullPolicy: IfNotPresent
vsphereSyncerImage:
repository: projects.registry.vmware.com/tkg
path: csi/volume-metadata-syncer
tag: v2.1.1_vmware.1
pullPolicy: IfNotPresent
CSIProvisionerImage:
repository: projects.registry.vmware.com/tkg
path: csi/csi-provisioner
tag: v2.0.0_vmware.1
pullPolicy: IfNotPresent
CSINodeDriverRegistrarImage:
repository: projects.registry.vmware.com/tkg
path: csi/csi-node-driver-registrar
tag: v2.0.1_vmware.1
pullPolicy: IfNotPresent
namespace: kube-system
clusterName: wc-1
server: 10.170.104.114
datacenter: /dc0
publicNetwork: VM Network
username: <MY-VSPHERE-USERNAME>
password: <MY-VSPHERE-PASSWORD>
Ouvrez vsphere-csi-secret.yaml
dans un éditeur et procédez comme suit afin qu'il ressemble au code ci-dessous :
values.yaml
, qui est une longue chaîne.stringData
et mettez en retrait values.yaml
pour en faire le premier élément.data.values
depuis l'étape précédente.data.values
et mettez-la en retrait comme valeur de values.yaml
.values.yaml
, ajoutez une autre définition stringData
pour overlays.yaml
comme indiqué ci-dessous. Ne modifiez pas d’autres définitions dans le fichier.apiVersion: v1
stringData:
values.yaml: |
#@data/values
#@overlay/match-child-defaults missing_ok=True
---
vsphereCSI:
CSIAttacherImage:
repository: projects.registry.vmware.com/tkg
path: csi/csi-attacher
tag: v3.0.0_vmware.1
pullPolicy: IfNotPresent
vsphereCSIControllerImage:
repository: projects.registry.vmware.com/tkg
path: csi/vsphere-block-csi-driver
tag: v2.1.1_vmware.1
pullPolicy: IfNotPresent
livenessProbeImage:
repository: projects.registry.vmware.com/tkg
path: csi/csi-livenessprobe
tag: v2.1.1_vmware.1
pullPolicy: IfNotPresent
vsphereSyncerImage:
repository: projects.registry.vmware.com/tkg
path: csi/volume-metadata-syncer
tag: v2.1.1_vmware.1
pullPolicy: IfNotPresent
CSIProvisionerImage:
repository: projects.registry.vmware.com/tkg
path: csi/csi-provisioner
tag: v2.0.0_vmware.1
pullPolicy: IfNotPresent
CSINodeDriverRegistrarImage:
repository: projects.registry.vmware.com/tkg
path: csi/csi-node-driver-registrar
tag: v2.0.1_vmware.1
pullPolicy: IfNotPresent
namespace: kube-system
clusterName: wc-1
server: 10.170.104.114
datacenter: /dc0
publicNetwork: VM Network
username: <MY-VSPHERE-USERNAME>
password: <MY-VSPHERE-PASSWORD>
overlays.yaml: |
#@ load("@ytt:overlay", "overlay")
#@overlay/match by=overlay.subset({"kind": "Deployment", "metadata": {"name": "vsphere-csi-controller"}})
---
spec:
template:
spec:
containers:
#@overlay/append
- name: csi-resizer
image: projects.registry.vmware.com/tkg/kubernetes-csi_external-resizer:v1.0.0_vmware.1
args:
- "--v=4"
- "--timeout=300s"
- "--csi-address=$(ADDRESS)"
- "--leader-election"
env:
- name: ADDRESS
value: /csi/csi.sock
volumeMounts:
- mountPath: /csi
name: socket-dir
kind: Secret
...
Exécutez kubectl apply
pour mettre à jour le secret du cluster avec les définitions révisées et recréer l'espace csi-controller
:
kubectl apply -f vsphere-csi-secret.yaml
Pour vérifier que vsphere-csi-controller
et le redimensionneur externe fonctionnent sur le cluster :
Vérifiez que vsphere-csi-controller
est en cours d'exécution sur le cluster de charge de travail avec six espaces sains :
$ kubectl get pods -n kube-system -l app=vsphere-csi-controller
NAME READY STATUS RESTARTS AGE
vsphere-csi-controller-<ID-HASH> 6/6 Running 0 6m49s
Consultez les journaux du vsphere-csi-controller
pour voir si le redimensionneur externe a démarré.
$ kubectl logs vsphere-csi-controller-<ID-HASH> -n kube-system -c csi-resizer
I0308 23:44:45.035254 1 main.go:79] Version : v1.0.0-0-gb22717d
I0308 23:44:45.037856 1 connection.go:153] Connecting to unix:///csi/csi.sock
I0308 23:44:45.038572 1 common.go:111] Probing CSI driver for readiness
I0308 23:44:45.040579 1 csi_resizer.go:77] CSI driver name: "csi.vsphere.vmware.com"
W0308 23:44:45.040612 1 metrics.go:142] metrics endpoint will not be started because `metrics-address` was not specified.
I0308 23:44:45.042184 1 controller.go:117] Register Pod informer for resizer csi.vsphere.vmware.com
I0308 23:44:45.043182 1 leaderelection.go:243] attempting to acquire leader lease kube-system/external-resizer-csi-vsphere-vmware-com...
I0308 23:44:45.073383 1 leaderelection.go:253] successfully acquired lease kube-system/external-resizer-csi-vsphere-vmware-com
I0308 23:44:45.076028 1 leader_election.go:172] new leader detected, current leader: vsphere-csi-controller-87d7dcf48-jcht2
I0308 23:44:45.079332 1 leader_election.go:165] became leader, starting
I0308 23:44:45.079638 1 controller.go:241] Starting external resizer csi.vsphere.vmware.com
Pour plus d'informations sur le développement de volumes de stockage vSphere CSI en mode en ligne ou hors ligne, reportez-vous aux sections Développer un volume persistant en mode en ligne et Développer un volume persistant en mode hors ligne.
Pour les clusters de charge de travail créés à partir d’un cluster de gestion autonome, vous pouvez configurer le provisionnement de volumes de stockage local prenant en charge la topologie. Le provisionnement de volumes prenant en charge la topologie permet à Kubernetes de prendre des décisions intelligentes lors du provisionnement dynamique de volumes. Kubernetes obtient une entrée de planificateur au meilleur endroit afin de provisionner un volume pour un espace.
Créez une zone de disponibilité (AZ) :
Suivez les instructions de la section Déployer des clusters de charge de travail sur plusieurs zones de disponibilité sur vSphere (version d'évaluation technique) pour créer les éléments suivants dans vSphere :
Ajoutez des règles pour limiter le groupe de machines virtuelles dans le groupe d'hôtes.
Un groupe de machines virtuelles et un groupe d'hôtes sont utilisés pour exécuter la zone de disponibilité dans le cluster de charge de travail.
RemarqueLes règles de limite s'appliquent uniquement aux configurations de volume local. Vous n’avez pas besoin de créer des règles de limite si vous déployez sur plusieurs zones de disponibilité.
Déployez les définitions de ressources personnalisées (CRD) VSphereFailureDomain
et VSphereDeploymentZone
dans le cluster de gestion autonome.
La zone de disponibilité sera mappée à une VSphereDeploymentZone
puis à un groupe d'hôtes dans vSphere.
Ajoutez une nouvelle zone de disponibilité. Vous pouvez ajouter une nouvelle zone de disponibilité à l'aide d'une configuration de superposition ytt
ou à l'aide de la CLI Tanzu.
ytt
ytt
dans un cluster hérité et un cluster classe.
Cluster hérité
#@overlay/match by=overlay.subset({"kind":"MachineDeployment", "metadata":{"name": "${CLUSTER_NAME}-md-0"}})
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
name: #@ "{}-md-0".format(data.values.CLUSTER_NAME)
spec:
clusterName: #@ data.values.CLUSTER_NAME
replicas: #@ data.values.WORKER_MACHINE_COUNT_0
selector:
matchLabels: null
strategy:
type: #@ verify_and_configure_machine_deployment_rollout_strategy(data.values.WORKER_ROLLOUT_STRATEGY)
template:
metadata:
labels:
node-pool: #@ "{}-worker-pool".format(data.values.CLUSTER_NAME)
spec:
clusterName: #@ data.values.CLUSTER_NAME
version: #@ data.values.KUBERNETES_VERSION
bootstrap:
configRef:
name: #@ "{}-md-0".format(data.values.CLUSTER_NAME)
apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
kind: KubeadmConfigTemplate
infrastructureRef:
name: #@ "{}-md-0".format(data.values.CLUSTER_NAME)
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSMachineTemplate
failureDomain: #@ default_az_0
Cluster classe
workers:
machineDeployments:
#@overlay/match by=overlay.index(0)
- class: tkg-worker
name: md-0
replicas: #@ data.values.WORKER_MACHINE_COUNT_0
#@overlay/match missing_ok=True
failureDomain: #@ default_az_0
metadata:
annotations:
run.tanzu.vmware.com/resolve-os-image: #@ "ami-region={},os-name={},os-arch={}".format(data.values.AWS_REGION, data.values.OS_NAME, data.values.OS_ARCH)
Cluster hérité
tanzu cl node-pool set cl-name -f node-pool.yaml
# node-pool.yaml
name: vsphere-wc-1-manual-node-pool
replicas: 1
az: "rack4"
Cluster classe
Reportez-vous à la section Définir (Créer) dans Configuration de pool de nœuds pour les clusters basés sur ClusterClass.