This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

Stockage dynamique

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).

Présentation : PersistentVolume, PersistentVolumeClaim et StorageClass

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.

Types de stockage pris en charge

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

  • Stockage cloud natif (CNS) vSphere
  • Amazon EBS
  • Disque Azure
  • Fichier Azure
  • iSCSI
  • NFS
Remarque

vSphere 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 ».

  • Les classes de stockage ne sont pas fournies avec la version Kubernetes de base.
  • Les valeurs provisioner de l'objet StorageClass ne sont pas précédées de kubernetes.io.
  • Les provisionneurs suivent la norme CSI (Container Storage Interface) pour le stockage externe.
  • Les clusters de charge de travail avec des classes de stockage par défaut déployées par des versions précédentes de TKG peuvent avoir un provisionnement de stockage dans l'arborescence. Reportez-vous à la section Créer des volumes persistants avec des classes de stockage.

Classes de stockage par défaut

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.

Important

Ne 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 un name 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.

Configurer CNS et créer une stratégie de stockage (vSphere)

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 :

  • 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 stockage « vSAN » (Enable rules for “vSAN” storage).
  • Configurez les autres volets ou acceptez les valeurs par défaut selon vos besoins.
  • Enregistrez le nom de la stratégie de stockage pour référence comme valeur 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 :

  1. Dans le menu vSphere de niveau supérieur, sélectionnez Balises et attributs personnalisés (Tags & Custom Attributes).

  2. Dans le volet Balises (Tags), sélectionnez Catégories et cliquez sur Nouveau (New).

  3. 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.

  4. 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)….

  5. Dans la fenêtre contextuelle Attribuer une balise (Assign Tag), cliquez sur Ajouter une balise (Add Tag).

  6. 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.

  7. Dans Attribuer une balise (Assign Tag), sélectionnez la balise et cliquez sur Attribuer (Assign).

  8. 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.

  9. 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.

  10. 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).

  11. 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 :

    • Catégorie de balise (Tag category) : sélectionner le nom de votre catégorie
    • Option d'utilisation (Usage option) : Use storage tagged with
    • Balises (Tags) : parcourir et sélectionner votre nom de balise

  12. 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.

Créer une classe de stockage personnalisée

Les administrateurs de cluster peuvent créer une classe de stockage comme suit :

  1. Sur vSphere, sélectionnez ou créez la stratégie de stockage de machine virtuelle à utiliser comme base pour la StorageClass Kubernetes.
  2. Créez un fichier .yaml de configuration StorageClass avec provisioner, parameters et d'autres options.
    • Sur vSphere, associez une classe de stockage Kubernetes à une stratégie de stockage vSphere en définissant son paramètre storagePolicyName sur le nom de la stratégie de stockage vSphere, sous la forme d'une chaîne entre guillemets doubles.
  3. Transmettez le fichier à kubectl create -f.
  4. Vérifiez la classe de stockage en exécutant 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.

Utiliser une classe de stockage personnalisée dans un cluster

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 :

  1. Définissez le contexte de kubectl sur le cluster. Par exemple :

    kubectl config use-context my-cluster-admin@my-cluster

  2. Sélectionnez ou créez une classe de stockage.

    • Sélectionner :
      • Pour répertorier les classes de stockage disponibles, exécutez la commande kubectl get storageclass.
    • Créer

  3. Créer une PVC et son PV :

    1. Créez un fichier .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.
    2. Transmettez le fichier à kubectl create -f.
    3. Exécutez kubectl describe pvc <pvc metadata.name> pour vérifier la PVC.
    4. Un PV est automatiquement créé avec la PVC. Enregistrez son nom, répertorié dans la sortie kubectl describe pvc après Successfully provisioned volume.
    5. Exécutez kubectl describe pv <pv unique name> pour vérifier le PV.

  4. Créez un espace utilisant la PVC :

    1. Créez un fichier .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.
    2. Transmettez le fichier à kubectl create -f.
    3. Exécutez kubectl get pod <pod metadata.name> pour vérifier l'espace.

Activer l’extension de volume pour vSphere CSI (vSphere 7)

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.

Remarque

L'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.

  1. 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.

  2. 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

  3. 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

  4. 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>

  5. Ouvrez vsphere-csi-secret.yaml dans un éditeur et procédez comme suit afin qu'il ressemble au code ci-dessous :

    1. Supprimez la définition existante du fichier values.yaml, qui est une longue chaîne.
    2. Après la première ligne, ajoutez une ligne qui définit stringData et mettez en retrait values.yaml pour en faire le premier élément.
    3. Copiez la sortie data.values depuis l'étape précédente.
    4. Après la troisième ligne, collez la sortie de data.values et mettez-la en retrait comme valeur de values.yaml.
    5. Immédiatement sous la définition 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
...

  6. 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

  7. Pour vérifier que vsphere-csi-controller et le redimensionneur externe fonctionnent sur le cluster :

    1. 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

    2. 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.

Provisionnement de volume prenant en charge la topologie (vSphere)

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) :

  1. 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 :

    1. Ajoutez un groupe d'hôtes et un groupe de machines virtuelles.

    2. 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.

      Remarque

      Les 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é.

    3. 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.

  2. 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
    Les éléments suivants montrent une configuration de superposition 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)
    CLI Tanzu
    Vous pouvez créer une zone de disponibilité pour prendre en charge le provisionnement de stockage local compatible avec la topologie à l'aide de la CLI Tanzu.

    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.

check-circle-line exclamation-circle-line close-line
Scroll to top icon