Exécution de clusters sur plusieurs zones de disponibilité

Cette rubrique décrit comment déployer de nouveaux clusters de charge de travail Tanzu Kubernetes Grid (TKG) qui s'exécutent dans plusieurs zones de disponibilité (AZ) et comment modifier les clusters de gestion et de charge de travail existants pour qu'ils s'exécutent dans plusieurs zones de disponibilité ou différentes zones de disponibilité.

Pour utiliser l'interface du programme d'installation afin de configurer un nouveau cluster de gestion autonome qui s'exécute sur plusieurs zones de disponibilité, reportez-vous à la section Configurer les ressources vSphere du document Déployer des clusters de gestion avec l'interface du programme d'installation.

Remarque
Cette rubrique s’applique à TKG avec un cluster de gestion autonome. Pour exécuter TKG avec un superviseur dans des zones de disponibilité, reportez-vous à la section Créer des zones vSphere pour un déploiement de superviseur à plusieurs zones dans la documentation de vSphere 8.0.

Présentation

Dans TKG sur vSphere, vous pouvez éventuellement définir des régions et des zones de disponibilité dans Kubernetes pour héberger des clusters de gestion autonomes et leurs clusters de charge de travail, puis les étiqueter dans vSphere pour les associer à des clusters vSphere, des groupes d'hôtes ou des centres de données.

Cette configuration permet à TKG de prendre en charge la distribution et la redondance de la charge de travail sur vSphere de la même manière qu'avec les régions et les zones de disponibilité sur d'autres infrastructures.

Sans ces constructions, vous pouvez placer des clusters TKG au niveau de vSphere en faisant directement référence à des objets vSphere, mais TKG et Kubernetes ne peuvent pas gérer leur placement.

Définition des zones de disponibilité

Pour définir des zones de disponibilité dans TKG sur vSphere, créez des objets Kubernetes et associez-les à des objets vSphere en fonction de la portée des zones de disponibilité :

Objets Kubernetes : Pour activer plusieurs zones de disponibilité pour les clusters sur vSphere, le fournisseur d'API de cluster vSphere (CAPV) utilise deux définitions de ressources personnalisées (CRD) :

La CRD VSphereFailureDomain capture les informations de balisage spécifiques à la région/zone, ainsi que la définition de topologie qui inclut les informations de centre de données, de cluster, d'hôte et de banque de données vSphere.
La CRD VSphereDeploymentZone capture l'association d'un VSphereFailureDomain avec les informations de contrainte de placement pour le nœud Kubernetes.

Pour créer ces objets, définissez-les dans une spécification d'objet telle qu'un fichier vsphere-zones.yaml, que vous pouvez ensuite utiliser pour créer les objets à différents moments, comme suit :

Lorsque vous créez initialement le cluster de gestion, transmettez le fichier à l'option --az-file de tanzu mc create.
- Pour exécuter le cluster de gestion lui-même dans des zones de disponibilité définies, vous devez créer les objets de zone de disponibilité de cette manière à ce stade.
- Si vous prévoyez d'avoir besoin d'objets de zone de disponibilité supplémentaires pour vos clusters de charge de travail et de conserver toutes vos définitions de zone de disponibilité dans un emplacement unique, vous pouvez définir des zones de disponibilité supplémentaires dans ce même fichier. Si vous effectuez cette opération, définissez SKIP_MULTI_AZ_VERIFY=true comme variable d'environnement pour ignorer la validation vSphere comme décrit dans la section Contrôles de validation sous Exécuter la commande tanzu mc create, car ces zones de disponibilité supplémentaires peuvent ne pas avoir encore toutes les configurations vSphere en place.
Une fois le cluster de gestion créé, mais avant de créer des clusters de charge de travail qui nécessitent la mise en place des objets de zone de disponibilité, transmettez le fichier à l'option -f de la commande tanzu mc az set ou kubectl apply.
Lorsque vous créez des clusters de charge de travail, transmettez le fichier à l'option --az-file de tanzu cluster create.

Pour répertorier les objets de zone de disponibilité qui ont déjà été créés, exécutez :

kubectl get VSphereFailureDomain,VSphereDeploymentZone -a

Association de Kubernetes à vSphere : Les définitions d'objets VSphereFailureDomain et VSphereDeploymentZone définissent les régions et les zones de disponibilité avec les paramètres suivants :

Région : spec.region
Zone/Zone de disponibilité : spec.zone

Les balises vSphere k8s-region et k8s-zone associent les régions et les zones de disponibilité dans Kubernetes à leurs objets sous-jacents dans vSphere.

Étendue de la zone de disponibilité : Vous pouvez étendre des zones de disponibilité et des régions à différents niveaux dans vSphere en les associant à des objets vSphere comme suit :

Étendue de la zone de disponibilité	Zone/Zone de disponibilité	Région	Utilisation de plusieurs zones de disponibilité
Zones de disponibilité du cluster	Cluster vSphere	Centre de données vSphere	Répartir les nœuds sur plusieurs clusters dans un centre de données
Zones de disponibilité du groupe d'hôtes	Groupe d'hôtes vSphere	Cluster vSphere	Répartir les nœuds sur plusieurs hôtes dans un cluster unique

Les configurations de cette rubrique répartissent le plan de contrôle du cluster TKG et les nœuds worker entre les objets entre vSphere, à savoir les centres de données, les clusters et les hôtes vSphere, en fonction de la manière dont les objets sont balisés dans vSphere et référencés dans les définitions VSphereFailureDomain et VSphereDeploymentZone dans Kubernetes.

Configuration de clusters pour utiliser des zones de disponibilité

Avec les objets VSphereFailureDomain et VSphereDeploymentZone définis pour les zones de disponibilité dans Kubernetes, vous pouvez configurer la manière dont les clusters les utilisent via des variables de fichier de configuration ou des propriétés d'objet Cluster.

Variables de configuration : Pour utiliser des variables de configuration de cluster, définissez VSPHERE_AZ_0, VSPHERE_AZ_1, VSPHERE_AZ_2, VSPHERE_AZ_CONTROL_PLANE_MATCHING_LABELS, VSPHERE_REGION et VSPHERE_ZONE comme décrit sous vSphere dans Configuration de référence des variables de fichier.

Propriétés des objets : Pour les propriétés des objets Cluster, la spécification des objets configure les zones de disponibilité pour leur plan de contrôle et leurs nœuds worker de différentes manières, en faisant correspondre les différentes propriétés des objets de la VSphereDeploymentZone qui définissent les zones de disponibilité :

Type de nœud	Propriété sous `spec.topology`	Propriétés `VSphereDeploymentZone` à faire correspondre	Exemple
Nœuds de plan de contrôle	`variables.controlPlaneZoneMatchingLabels`	Liste des paires `metadata.labels`	`{"environment": "staging", "region": "room1"}`
Nœuds Worker	`machineDeployments.MD-INDEX.failureDomain` pour chaque déploiement de machine	Liste des valeurs `metadata.name`	`[rack1,rack2,rack3]`

Étant donné que les nœuds de plan de contrôle sont attribués à des zones de disponibilité en fonction de la correspondance des étiquettes, vous devez créer une étiquette qui distingue chaque combinaison de zones de disponibilité que les nœuds de plan de contrôle de cluster peuvent utiliser.

Conditions requises

Les conditions préalables au déploiement ou à la modification des clusters TKG pour qu'ils s'exécutent dans plusieurs zones de disponibilité ou différentes zones de disponibilité incluent les éléments suivants :

Cluster de gestion Tanzu Kubernetes Grid avec des clusters de charge de travail s'exécutant sur vSphere.
L'autorisation suivante a été ajoutée au compte vSphere configuré pour TKG, comme décrit dans la section suivante Autorisations requises pour le compte vSphere :
- Hôte (Host) > Inventaire (Inventory) > Modifier cluster (Modify cluster)

Déployer des clusters de charge de travail sur plusieurs zones de disponibilité

Vous pouvez déployer un cluster de charge de travail pour qu'il exécute son plan de contrôle ou ses nœuds worker dans plusieurs zones de disponibilité (AZ) selon trois étapes de base, comme décrit dans les sections suivantes.

Préparer des régions et des zones de disponibilité dans vSphere
Créer des objets FailureDomain et DeploymentZone dans Kubernetes
Déployer le cluster

Préparer des régions et des zones de disponibilité dans vSphere

Pour préparer vSphere à la prise en charge des régions et des zones de disponibilité dans TKG :

Identifiez ou créez les objets vSphere pour les régions et les zones de disponibilité dans lesquelles vos nœuds de cluster TKG seront hébergés.
- Zones de disponibilité du groupe d'hôtes : Si vous utilisez des groupes d'hôtes vSphere en tant que zones de disponibilité, vous devez créer un groupe d'hôtes et un groupe de machines virtuelles correspondant pour chaque zone de disponibilité que vous prévoyez d'utiliser :
  1. Créez des objets de groupe d'hôtes et de groupe de machines virtuelles de l'une des manières suivantes :
    - Dans vCenter, créez un groupe d'hôtes et un groupe de machines virtuelles à partir de Configurer > VM/Groupes d'hôtes > Ajouter…
      - Pour créer un groupe d'hôtes, vous devrez peut-être créer une machine virtuelle factice à ajouter en tant que membre du groupe.
    - Avec la CLI govc, exécutez des commandes govc semblables aux commandes suivantes. Par exemple, pour créer un groupe d'hôtes rack1 et un groupe de machines virtuelles rack1-vm-group :
```
govc cluster.group.create -cluster=RegionA01-MGMT -name=rack1 -host esx-01a.corp.tanzu esx-02a.corp.tanzu
```
```
govc cluster.group.create -cluster=RegionA01-MGMT -name=rack1-vm-group -vm
```
  2. Ajoutez des règles d'affinité entre les groupes de machines virtuelles et les groupes d'hôtes créés afin que les machines virtuelles du groupe de machines virtuelles s'exécutent sur les hôtes du groupe d'hôtes créé :
    - Définissez Type sur Machines virtuelles aux hôtes et incluez la règle Doit s'exécuter sur des hôtes en groupe.
Balisez les objets vSphere comme suit, selon que vous configurez des zones de disponibilité de clusters ou de groupes d'hôtes vSphere. Ces exemples utilisent la CLI govc, mais vous pouvez également utiliser le volet Balises et attributs personnalisés dans vCenter :
- Zones de disponibilité du cluster :
  
  Pour chaque zone de disponibilité, utilisez govc pour créer et attacher une balise de catégorie k8s-region au centre de données et une balise de catégorie k8s-zone à chaque cluster vSphere. Par exemple, pour baliser le centre de données dc0 en tant que région us-west-1 et ses clusters cluster1, etc., en tant que zones de disponibilité us-west-1a, etc. :
```
govc tags.category.create -t Datacenter k8s-region

govc tags.category.create -t ClusterComputeResource k8s-zone

govc tags.create -c k8s-region us-west-1

govc tags.create -c k8s-zone us-west-1a
govc tags.create -c k8s-zone us-west-1b
govc tags.create -c k8s-zone us-west-1c

govc tags.attach -c k8s-region us-west-1 /dc0

govc tags.attach -c k8s-zone us-west-1a /dc0/host/cluster1
govc tags.attach -c k8s-zone us-west-1b /dc0/host/cluster2
govc tags.attach -c k8s-zone us-west-1c /dc0/host/cluster3
```
- Zones de disponibilité du groupe d'hôtes :
  
  Pour chaque zone de disponibilité, utilisez govc pour créer et attacher une balise de catégorie k8s-region au cluster vSphere et une balise de catégorie k8s-zone à chaque hôte. Par exemple, pour étiqueter le cluster /dc1/host/room1-mgmt en tant que région room1 et l'hôte dans ce groupe /dc1/host/room1-mgmt/esx-01a.corp.tanzu, etc. en tant que zones de disponibilité rack1, etc. :
```
govc tags.category.create -t ClusterComputeResource k8s-region
govc tags.category.create -t HostSystem k8s-zone

govc tags.create -c k8s-region room1

govc tags.create -c k8s-zone rack1
govc tags.create -c k8s-zone rack2
govc tags.create -c k8s-zone rack3

govc tags.attach -c k8s-region room1 /dc1/host/room1-mgmt

govc tags.attach -c k8s-zone rack1 /dc1/host/room1-mgmt/esx-01a.corp.tanzu
govc tags.attach -c k8s-zone rack1 /dc1/host/room1-mgmt/esx-01b.corp.tanzu
govc tags.attach -c k8s-zone rack1 /dc1/host/room1-mgmt/esx-01c.corp.tanzu
```
Identifiez ou créez les pools de ressources et les dossiers vSphere à utiliser pour placer les machines virtuelles de chaque zone de disponibilité. Ces exemples utilisent la CLI govc, mais vous pouvez également utiliser le volet Inventaire dans vCenter :
- Zones de disponibilité du cluster :
  
  Pour chaque zone de disponibilité, utilisez govc pour créer un objet resource-pool sur chaque cluster vSphere correspondant chacun à l'une des 3 zones de disponibilité, ainsi que 3 dossiers de VM
```
govc pool.create /dc0/host/cluster1/pool1
govc pool.create /dc0/host/cluster2/pool2
govc pool.create /dc0/host/cluster3/pool3
govc folder.create /dc0/vm/folder1
govc folder.create /dc0/vm/folder2
govc folder.create /dc0/vm/folder3
```
- Zones de disponibilité du groupe d'hôtes :
  
  Pour chaque zone de disponibilité, utilisez govc pour créer 3 objets resource-pool et 3 dossiers de VM
```
govc pool.create /dc1/host/cluster1/pool1
govc pool.create /dc1/host/cluster1/pool2
govc pool.create /dc1/host/cluster1/pool3
govc folder.create /dc1/vm/folder1
govc folder.create /dc1/vm/folder2
govc folder.create /dc1/vm/folder3
```

Créer des objets `FailureDomain` et `DeploymentZone` dans Kubernetes

Avant de déployer un cluster sur plusieurs zones de disponibilité, vous devez définir les objets Kubernetes FailureDomain et DeploymentZone pour la région et les zones, comme décrit dans la section Définition des zones de disponibilité ci-dessus.

Chaque paramètre sous spec.region, spec.zone et spec.topology doit correspondre aux chemins d'accès et aux balises des objets configurés dans vCenter :

Pour les objets VSphereDeploymentZone, la valeur spec.failuredomain doit correspondre à l'une des valeurs metadata.name des définitions VSphereFailureDomain.
La valeur spec.server dans les objets VSphereDeploymentZone doit correspondre à l'adresse de serveur vCenter (adresse IP ou nom de domaine complet) entrée pour VCENTER SERVER dans le volet Fournisseur IaaS (IaaS Provider) de l'interface du programme d'installation ou au paramètre VSPHERE_SERVER du fichier de configuration du cluster de gestion.
Les valeurs metadata.name doivent toutes être en minuscules.

Créez des définitions d'objet FailureDomain et DeploymentZone comme suit, selon que vous configurez des zones de disponibilité de cluster ou de groupe d'hôtes vSphere.

Zones de disponibilité du cluster :

Comme exemple de répartition du cluster de charge de travail entre plusieurs nœuds de cluster vSphere dans un centre de données, le code suivant définit les objets nécessaires pour les trois zones de déploiement nommées us-west-1a, us-west-1b et us-west-1c, chacune étant un cluster vSphere ayant ses propres paramètres réseau et de stockage :

  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereFailureDomain
  metadata:
    name: us-west-1a
  spec:
    region:
      name: us-west-1
      type: Datacenter
      tagCategory: k8s-region
    zone:
      name: us-west-1a
      type: ComputeCluster
      tagCategory: k8s-zone
    topology:
      datacenter: dc0
      computeCluster: cluster1
      datastore: ds-c1
      networks:
      - net1
      - net2
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereFailureDomain
  metadata:
    name: us-west-1b
  spec:
    region:
      name: us-west-1
      type: Datacenter
      tagCategory: k8s-region
    zone:
      name: us-west-1b
      type: ComputeCluster
      tagCategory: k8s-zone
    topology:
      datacenter: dc0
      computeCluster: cluster2
      datastore: ds-c2
      networks:
      - net3
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereFailureDomain
  metadata:
    name: us-west-1c
  spec:
    region:
      name: us-west-1
      type: Datacenter
      tagCategory: k8s-region
    zone:
      name: us-west-1c
      type: ComputeCluster
      tagCategory: k8s-zone
    topology:
      datacenter: dc0
      computeCluster: cluster3
      datastore: ds-c3
      networks:
      - net4
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
    name: us-west-1a
    labels:
      environment: "staging"
      region: "us-west-1"
  spec:
    server: VSPHERE_SERVER
    failureDomain: us-west-1a
    placementConstraint:
      resourcePool: pool1
      folder: folder1
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
    name: us-west-1b
    labels:
      environment: "staging"
      region: "us-west-1"
  spec:
    server: VSPHERE_SERVER
    failureDomain: us-west-1b
    placementConstraint:
      resourcePool: pool2
      folder: folder2
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
    name: us-west-1c
    labels:
      environment: "staging"
      region: "us-west-1"
  spec:
    server: VSPHERE_SERVER
    failureDomain: us-west-1c
    placementConstraint:
      resourcePool: pool3
      folder: folder3

Où VSPHERE_SERVER est l'adresse IP ou le nom de domaine complet de votre instance de vCenter Server.

Si différents clusters de vSphere disposent de pools de ressources avec des noms identiques, définissez la valeur spec.placementConstraint.resourcePool des objets VSphereDeploymentZone sur un chemin de ressource complet, pas seulement sur le nom.

Zones de disponibilité du groupe d'hôtes :

Comme exemple de répartition des nœuds de cluster de charge de travail sur trois groupes d'hôtes dans un cluster vSphere unique, le code suivant définit les objets nécessaires pour les trois zones de disponibilité rack1, rack2 et rack3, chacun d'eux représentant un rack d'hôtes dans le même cluster vSphere, défini comme region room1 :

  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereFailureDomain
  metadata:
    name: rack1
  spec:
    region:
      name: room1
      type: ComputeCluster
      tagCategory: k8s-region
    zone:
      name: rack1
      type: HostGroup
      tagCategory: k8s-zone
    topology:
      datacenter: dc0
      computeCluster: cluster1
      hosts:
        vmGroupName: rack1-vm-group
        hostGroupName: rack1
      datastore: ds-r1
      networks:
      - net1
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereFailureDomain
  metadata:
    name: rack2
  spec:
    region:
      name: room1
      type: ComputeCluster
      tagCategory: k8s-region
    zone:
      name: rack2
      type: HostGroup
      tagCategory: k8s-zone
    topology:
      datacenter: dc0
      computeCluster: cluster1
      hosts:
        vmGroupName: rack2-vm-group
        hostGroupName: rack2
      datastore: ds-r2
      networks:
      - net2
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereFailureDomain
  metadata:
    name: rack3
  spec:
    region:
      name: room1
      type: ComputeCluster
      tagCategory: k8s-region
    zone:
      name: rack3
      type: HostGroup
      tagCategory: k8s-zone
    topology:
      datacenter: dc0
      computeCluster: cluster1
      hosts:
        vmGroupName: rack3-vm-group
        hostGroupName: rack3
      datastore: ds-c3
      networks:
      - net3
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
    name: rack1
    labels:
      region: room1
  spec:
    server: VSPHERE_SERVER
    failureDomain: rack1
    placementConstraint:
      resourcePool: pool1
      folder: folder1
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
    name: rack2
    labels:
      region: room1
  spec:
    server: VSPHERE_SERVER
    failureDomain: rack2
    placementConstraint:
      resourcePool: pool2
      folder: folder2
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
    name: rack3
    labels:
      region: room1
  spec:
    server: VSPHERE_SERVER
    failureDomain: rack3
    placementConstraint:
      resourcePool: pool3
      folder: folder3

Où VSPHERE_SERVER est l'adresse IP ou le nom de domaine complet de votre instance de vCenter Server.

Après avoir créé les définitions d'objets FailureDomain et DeploymentZone pour vos zones de disponibilité, continuez en fonction du type de cluster que vous déployez :

Cluster de gestion autonome : Continuez avec Configurer plusieurs zones de disponibilité dans le cadre de Déployer des clusters de gestion à partir d'un fichier de configuration.
Cluster de charge de travail : Continuez avec Déployer le cluster ci-dessous.

Déployer le cluster

Une fois que vous avez effectué les étapes dans Préparer des régions et des zones de disponibilité dans vSphere et Créer des objets FailureDomain et DeploymentZone dans Kubernetes, vous pouvez déployer un cluster de charge de travail avec ses nœuds répartis sur plusieurs zones de disponibilité.

Les étapes suivantes utilisent vsphere-zones.yaml comme fichier contenant les définitions d'objets FailureDomain et DeploymentZone.

Suivez vSphere avec des fichiers de configuration de cluster de gestion autonome pour créer le fichier de configuration du cluster de charge de travail que vous déployez.
Vérifiez ou modifiez les variables de la zone de disponibilité dans votre fichier de configuration de cluster pour qu'elle correspondent aux définitions d'objets de votre zone de disponibilité :
- Définissez VSPHERE_REGION et VSPHERE_ZONE sur la région et les catégories de balises de région, k8s-region et k8s-zone.
  - Ces variables configurent également la topologie CSI ; reportez-vous à la section Déployer un cluster avec des balises de région et de zone pour CSI.
- Définissez VSPHERE_AZ_0, VSPHERE_AZ_1 et VSPHERE_AZ_2 avec les noms des objets VsphereDeploymentZone sur lesquels les machines doivent être déployées.
  - L'objet VsphereDeploymentZone associé à VSPHERE_AZ_0 est le VSphereFailureDomain dans lequel le déploiement de machine se terminant par md-0 est déployé. De la même manière, VSPHERE_AZ_1 est le VSphereFailureDomain dans lequel le déploiement de machine se terminant par md-1 est déployé et VSPHERE_AZ_2 est le VSphereFailureDomain dans lequel le déploiement de la machine se terminant par md-2 est déployé
  - Si l'une des configurations de zone de disponibilité n'est pas définie, ce déploiement de machine est déployé sans VSphereFailureDomain
- WORKER_MACHINE_COUNT définit le nombre total de nœuds worker pour le cluster. Le nombre total de nœuds worker est distribué par permutation circulaire selon le nombre de zones de disponibilité spécifiées.
- VSPHERE_AZ_CONTROL_PLANE_MATCHING_LABELS définit des étiquettes de sélecteur clé/valeur pour les zones de disponibilité dans lesquelles les nœuds de plan de contrôle de cluster peuvent se déployer.
  - Définissez cette variable si VSPHERE_REGION et VSPHERE_ZONE sont définis.
  - Les étiquettes doivent exister dans les ressources VSphereDeploymentZone que vous créez.
  - Ces étiquettes vous permettent de spécifier toutes les zones de disponibilité dans une région et un environnement sans avoir à les répertorier individuellement, par exemple : "region=us-west-1,environment=staging".
Les variables de configuration de cluster pour les zones de disponibilité fonctionnent de la même manière pour les clusters de gestion autonomes et les clusters de charge de travail. Pour obtenir la liste complète des options que vous devez spécifier lors du déploiement de clusters de charge de travail sur vSphere, reportez-vous à la Référence de variable de fichier de configuration.
Exécutez la commande tanzu cluster create pour créer le cluster de charge de travail. Pour plus d'informations, reportez-vous à la section Créer des clusters de charge de travail.
- Pour créer les objets de zone de disponibilité séparément du cluster, connectez-vous au cluster de gestion avec tanzu login, puis exécutez les éléments suivants avant d'exécuter tanzu cluster create :
```
tanzu mc az set -f vsphere-zones.yaml
```
  Vous pouvez également exécuter kubectl apply -f vsphere-zones.yaml
- Pour utiliser les définitions d'objets de zone de disponibilité avec un fichier de configuration de cluster plat et créer les objets de zone de disponibilité et de cluster ensemble, transmettez le fichier vsphere-zones.yaml à l'option --az-file de tanzu cluster create :
```
tanzu cluster create --file cluster-config-file.yaml --az-file vsphere-zones.yaml
```
- Pour combiner les définitions d'objets de zone de disponibilité dans le manifeste du cluster, créez le manifeste du cluster en suivant l'étape 1 du processus en deux étapes décrit dans la section Créer un cluster basé sur une classe, ajoutez le contenu de vsphere-zones.yaml au manifeste, puis exécutez tanzu cluster create, comme décrit à l'étape 2.
- Pendant le processus de création du cluster, vous pouvez voir ses machines virtuelles et d'autres ressources s'afficher dans vCenter.
- Si vous avez créé une machine virtuelle factice dans vCenter afin de créer un groupe de machines virtuelles, vous pouvez supprimer la machine virtuelle des groupes de machines virtuelles une fois que le cluster est en cours d'exécution.

Mettre à jour des clusters existants pour utiliser plusieurs zones de disponibilité ou différentes zones de disponibilité

Vous pouvez mettre à jour un cluster de gestion ou de charge de travail déjà déployé pour exécuter son plan de contrôle ou ses nœuds worker dans plusieurs zones de disponibilité (AZ) ou modifier les zones de disponibilité dans lesquelles les nœuds s'exécutent.

Vous pouvez attribuer des zones de disponibilité au plan de contrôle ou aux nœuds worker d'un cluster globalement, ou définir des zones de disponibilité pour les déploiements de machines sous-jacents, afin de personnaliser les paramètres de la machine vSphere, ainsi que des zones de disponibilité pour le déploiement de machines défini.

Lorsque vous mettez à jour les zones de disponibilité d'un cluster de charge de travail existant, vous devez mettre à jour son interface de stockage de conteneur (CSI) et son interface de fournisseur de cloud (CPI) pour appliquer la modification, comme décrit dans la section Mettre à jour la CPI et la CSI pour les modifications des zones de disponibilité.

Les sections suivantes expliquent comment mettre à jour les configurations de zones de disponibilité de cluster existantes pour différents scénarios.

Ajouter des zones de disponibilité pour les nœuds de plan de contrôle

Pour développer un cluster existant dont les nœuds de plan de contrôle s'exécutent dans une zone de disponibilité unique afin que son plan de contrôle s'exécute dans plusieurs zones de disponibilité :

Préparez un fichier de configuration qui définit des objets VSphereFailureDomain et VSphereDeploymentZone pour chaque nouvelle zone de disponibilité. L'exemple ci-dessous, vsphere-3-zones.yaml, définit les zones de disponibilité rack1, rack2 et rack3 avec la région room1 :

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind:VSphereFailureDomain
metadata:
  name:rack
spec:
 region:
   name: room1
   type: ComputeCluster
   tagCategory: k8s-region
 zone:
   name:rack
   type: HostGroup
   tagCategory: k8s-zone
 topology:
   datacenter: dc0
   computeCluster: cluster0
 hosts:
   vmGroupName:rack-vm-group
   hostGroupName:rack
   datastore: ds1
   networks:
   - "VM Network"
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind:VSphereFailureDomain
metadata:
  name:rack
spec:
  region:
    name: room1
    type: ComputeCluster
    tagCategory: k8s-region
  zone:
    name: rack2
    type: HostGroup
    tagCategory: k8s-zone
  topology:
    datacenter: dc0
    computeCluster: cluster0
  hosts:
    vmGroupName: rack2-vm-group
    hostGroupName: rack2
    datastore: ds2
    networks:
    - "VM Network"
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereFailureDomain
metadata:
  name: rack3
spec:
  region:
    name: room1
    type: ComputeCluster
    tagCategory: k8s-region
  zone:
    name: rack3:
    type: HostGroup
    tagCategory: k8s-zone
  topology:
    datacenter: dc0
    computeCluster: cluster0
  hosts:
    vmGroupName: rack3-vm-group
    hostGroupName: rack3
    datastore: ds3
    networks:
    - "VM Network"
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
  name: rack1
  labels:
    environment: "staging"
    region: "room1"
spec:
  server: VSPHERE_SERVER
  failureDomain: rack1
  placementConstraint:
    resourcePool: rp0
    folder: folder0
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
  name: rack2
  labels:
    environment: "staging"
    region: "room1"
spec:
  server: VSPHERE_SERVER
  failureDomain: rack2
  placementConstraint:
    resourcePool: rp0
    folder: folder0
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
  name: rack3
  labels:
    environment: "staging"
    region: "room1"
spec:
  server: VSPHERE_SERVER
  failureDomain: rack3
  placementConstraint:
    resourcePool: rp0
    folder: folder0

Où VSPHERE_SERVER est l'adresse IP ou le nom de domaine complet de votre instance de vCenter Server.

Remarques :

Assurez-vous que les balises sont créées et que les ressources de l'inventaire vCenter Server ont été correctement balisées, comme décrit dans la section Balises vSphere de la documentation du produit vSphere.
Vous devez définir spec.placementConstraint.resourcePool dans VSphereDeploymentZone. S'il n'existe aucun pool de ressources créé par l'utilisateur pour le cluster, définissez la valeur sur le pool de ressources par défaut du cluster, dont le chemin d'accès est /dc0/host/cluster1/Resources.
Pour les objets VSphereFailureDomain, les variables spec.region.autoConfigure et spec.zone.autoConfigure ne sont plus prises en charge.

Créez les objets vSphereFailureDomain et VSphereDeploymentZone, par exemple :
```
tanzu mc az set -f vsphere-3-zones.yaml
```
Obtenez le KubeAdmControlPlane du cluster cible. Dans notre exemple, la cible est le cluster de gestion tkg-mgmt-vc, mais il peut également s'agir d'un cluster de charge de travail :
```
kubectl get kcp --selector cluster.x-k8s.io/cluster-name=tkg-mgmt-vc -n tkg-system -o=name

kubeadmcontrolplane.controlplane.cluster.x-k8s.io/tkg-mgmt-vc-cpkxj
```

Mettez à jour le sélecteur de zone de disponibilité du cluster, par exemple controlPlaneZoneMatchingLabels: {"environment": "staging", "region": "room1"} :

kubectl get cluster tkg-mgmt-vc -n tkg-system -o json | jq '.spec.topology.variables |= map(if .name == "controlPlaneZoneMatchingLabels" then .value = {"environment": "staging", "region": "room1"} else . end)'| kubectl apply -f -

cluster.cluster.x-k8s.io/tkg-mgmt-vc replaced

Vérifiez que le domaine de pannes du cluster a été mis à jour comme prévu :

kubectl get cluster tkg-mgmt-vc -n tkg-system -o json | jq -r '.status.failureDomains | to_entries[].key'

Corrigez le KubeAdmControlPlane avec rolloutAfter pour déclencher une mise à jour des nœuds de plan de contrôle.

kubectl patch kcp tkg-mgmt-vc-cpkxj -n tkg-system --type merge -p "{\"spec\":{\"rolloutAfter\":\"$(date +'%Y-%m-%dT%TZ')\"}}"

Vérifiez que les nœuds de plan de contrôle ont été déplacés vers les nouvelles zones de disponibilité, en vérifiant l'hôte et la banque de données des nœuds dans vCenter ou en exécutant les commandes kubectl get node ou govc vm.info comme suit :
- kubectl get node NODE-NAME -o=jsonpath='{.metadata.labels.node.cluster.x-k8s.io/esxi-host}' --context tkg-mgmt-vc-admin@tkg-mgmt-vc
- govc vm.info -json NODE-NAME | jq -r '.VirtualMachines[].Config.Hardware.Device[] | select(.DeviceInfo.Label == "Hard disk 1") | .Backing.FileName'

Utiliser les étiquettes de sélecteur pour spécifier de nouvelles zones de disponibilité du plan de contrôle

La sélection de zones de disponibilité avec des étiquettes de sélecteur implique la spécification de VSphereDeploymentZone par ses metadata.labels plutôt que son metadata.name. Cela permet de configurer les nœuds de plan de contrôle d'un cluster, par exemple, pour qu'ils s'exécutent dans toutes les zones de disponibilité d'une région et d'un environnement spécifiés sans répertorier individuellement les zones de disponibilité : "region=us-west-1,environment=staging". Cela signifie également que vous pouvez mettre à jour les zones de disponibilité d'un plan de contrôle d'un cluster sans avoir à modifier les noms de zone de disponibilité pour les nœuds de plan de contrôle.

Pour utiliser des étiquettes de sélecteur afin qu'elles indiquent de nouvelles zones de disponibilité pour les nœuds de plan de contrôle d'un cluster existant :

Préparez un fichier de configuration qui définit des objets VSphereFailureDomain et VSphereDeploymentZone pour chaque nouvelle zone de disponibilité. L'exemple ci-dessous, vsphere-labeled-zones.yaml, définit une zone de disponibilité rack4 avec des métadonnées d'étiquettes de sélecteur :

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereFailureDomain
metadata:
  name: rack4
spec:
  region:
    name: room1
    type: ComputeCluster
    tagCategory: k8s-region
  zone:
    name: rack4
    type: HostGroup
    tagCategory: k8s-zone
  topology:
    datacenter: dc0
    computeCluster: cluster0
  hosts:
    vmGroupName: rack4-vm-group
    hostGroupName: rack4
    datastore: vsanDatastore
    networks:
    - "VM Network"
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
  name: rack4
  labels:
    environment: staging
    region: room1
spec:
  server: VSPHERE_SERVER
  failureDomain: rack4
  placementConstraint:
    resourcePool: rp0
    folder: folder0

Créez les objets VSphereFailureDomain et VSphereDeploymentZone, par exemple :
```
tanzu mc az set -f vsphere-labeled-zones.yaml
```
Mettez à jour le cluster avec l'étiquette du sélecteur de zone de disponibilité. L'exemple ici utilise un sélecteur de zone de disponibilité controlPlaneZoneMatchingLabels: {"environment": "staging", "region": "room1"} pour le cluster de gestion tkg-mgmt-vc, mais il peut également s'agir d'un cluster de charge de travail :
```
kubectl get cluster tkg-mgmt-vc -n tkg-system -o json | \
jq '.spec.topology.variables |= \
map(if .name == "controlPlaneZoneMatchingLabels" \
then .value = {"environment": "staging", "region": "room1"} \
else . end)'| kubectl apply -f -

cluster.cluster.x-k8s.io/tkg-mgmt-vc replaced
```

Vérifiez l'état du cluster pour vous assurer que le domaine de pannes a été mis à jour comme prévu :

kubectl get cluster tkg-mgmt-vc -n tkg-system -o json | jq -r '.status.failureDomains | to_entries[].key'

Corrigez le KubeAdmControlPlane avec rolloutAfter pour déclencher une mise à jour des nœuds de plan de contrôle.

kubectl patch kcp tkg-mgmt-vc-cpkxj -n tkg-system --type merge -p "{\"spec\":{\"rolloutAfter\":\"$(date +'%Y-%m-%dT%TZ')\"}}"

Vérifiez que les nœuds de plan de contrôle sont déplacés vers de nouvelles zones de disponibilité sélectionnées par le sélecteur dans controlPlaneZoneMatchingLabels en vérifiant l'hôte et la banque de données des nœuds dans vCenter ou en exécutant les commandes kubectl get node ou govc vm.info comme suit. Dans notre exemple, la nouvelle zone de disponibilité est rack4 :
- kubectl get node NODE-NAME -o=jsonpath='{.metadata.labels.node.cluster.x-k8s.io/esxi-host}' --context tkg-mgmt-vc-admin@tkg-mgmt-vc
- govc vm.info -json NODE-NAME | jq -r '.VirtualMachines[].Config.Hardware.Device[] | select(.DeviceInfo.Label == "Hard disk 1") | .Backing.FileName'

Modifier les zones de disponibilité de déploiement de machines

Pour modifier une configuration de zone de disponibilité dans un cluster existant, corrigez les configurations MachineDeployment sous-jacentes de ses nœuds avec la nouvelle valeur de la zone de disponibilité.

Par exemple, si le fichier de configuration de cluster définit VSPHERE_AZ_0 sur rack1 et que vous souhaitez déplacer ses nœuds worker vers rack2 :

Interrogez les zones de disponibilité actuelles utilisées pour le cluster. Cet exemple utilise un cluster de charge de travail tkg-wc, mais il peut également s'agir d'un cluster de gestion :
```
kubectl get cluster tkg-wc -o json \| jq -r '.spec.topology.workers.machineDeployments\[0\].failureDomain'
```

Répertoriez toutes les zones de disponibilité disponibles.

kubectl get vspheredeploymentzones -o=jsonpath='{range .items[?(@.status.ready == true)]}{.metadata.name}{"\n"}{end}'

rack1
rack2

Corrigez la configuration spec.toplogy.workers.machineDeployments du cluster tkg-wc pour définir sa zone VSphereFailureDomain sur rack2. Cet exemple part du principe que tkg-wc est un cluster de plan dev à nœud unique. Pour un cluster de plan prod, vous devez corriger les trois configurations d'objets MachineDeployment dans le cluster.
```
kubectl patch cluster tkg-wc --type=json -p='[{"op": "replace", "path": "/spec/topology/workers/machineDeployments/0/failureDomain", "value": "rack2"}]'

cluster.cluster.x-k8s.io/tkg-wc patched
```

Vérifiez que le cluster est mis à jour avec VSphereFailureDomain rack2.

kubectl get cluster tkg-wc -o=jsonpath='{.spec.topology.workers.machineDeployments[?(@.name=="md-0")].failureDomain}'

rack2

Vérifiez que les nœuds worker sont désormais déployés dans VSphereFailureDomain rack2.

Ajouter des zones de disponibilité pour les déploiements de machines

Pour configurer de nouvelles zones de disponibilité à utiliser par les clusters TKG, puis les utiliser dans un cluster existant :

Préparez un fichier de configuration qui définit des objets VSphereFailureDomain et VSphereDeploymentZone pour chaque nouvelle zone de disponibilité. Utilisez l'exemple vsphere-3-zones.yaml de la section Ajouter des zones de disponibilité pour les nœuds de plan de contrôle ci-dessus, qui définit les zones de disponibilité rack1, rack2 et rack3 avec la région room1.
Créez les objets VSphereFailureDomain et VSphereDeploymentZone.
```
tanzu mc az set -f vsphere-3-zones.yaml
```
Vous pouvez également exécuter kubectl apply -f vsphere-3-zones.yaml

Corrigez le cluster tkg-wc avec VSphereFailureDomain rack1, rack2 et rack3. Dans cet exemple, tkg-wc est un plan de cluster de plan prod avec trois configurations MachineDeployment. Avec un cluster de plan dev, il vous suffit de mettre à jour un MachineDeployment dans les spec.toplogy.workers.machineDeployments du cluster.

kubectl patch cluster tkg-wc --type=json -p='[  \
{"op": "replace", "path": "/spec/topology/workers/machineDeployments/0/failureDomain", "value": "rack1"}, \
{"op": "replace", "path": "/spec/topology/workers/machineDeployments/1/failureDomain", "value": "rack2"}, \
{"op": "replace", "path": "/spec/topology/workers/machineDeployments/2/failureDomain", "value": "rack3"}]'

Vérifiez que le cluster est mis à jour avec les nouvelles zones de disponibilité.

kubectl get cluster tkg-wc -o=jsonpath='{range .spec.topology.workers.machineDeployments[*]}{"Name: "}{.name}{"\tFailure Domain: "}{.failureDomain}{"\n"}{end}'

Vérifiez que ses nœuds worker sont désormais déployés dans VSphereFailureDomain rack1, rack2 et rack3.

Ajouter des zones de disponibilité et de nouveaux déploiements de machines

Pour configurer les nouvelles zones de disponibilité et les nouveaux objets MachineDeployment à utiliser par les clusters TKG, puis les utiliser dans un cluster existant :

Préparez un fichier de configuration qui définit des objets VSphereFailureDomain et VSphereDeploymentZone pour chaque nouvelle zone de disponibilité. L'exemple ci-dessous, vsphere-1-zone.yaml, définit la nouvelle zone de disponibilité rack2 avec la région room1 :

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereFailureDomain
metadata:
 name: rack2
spec:
 region:
   name: room1
   type: ComputeCluster
   tagCategory: k8s-region
 zone:
   name: rack2
   type: HostGroup
   tagCategory: k8s-zone
 topology:
   datacenter: dc0
   computeCluster: cluster0
   hosts:
     vmGroupName: rack2-vm-grou
     hostGroupName: rack2
     datastore: ds-r2
   networks:
   - "VM Network"
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
  name: rack2
spec:
  server: VSPHERE_SERVER
  failureDomain: rack2
  placementConstraint:
    resourcePool: rp0
    folder: folder0

Créez les objets VSphereFailureDomain et VSphereDeploymentZone.
```
tanzu mc az set -f vsphere-zones.yaml
```
Vous pouvez également exécuter kubectl apply -f vsphere-1-zone.yaml
Préparez un fichier de configuration pour le nouveau déploiement de machines. L'exemple ci-dessous, md-1.yaml, définit un nouveau déploiement de machines md-1 avec sa propriété az définie sur rack2 :
```
name: md-1
replicas: 1
az: rack2
nodeMachineType: t3.large
workerClass: tkg-worker
tkrResolver: os-name=ubuntu,os-arch=amd64
```
Créez un pool de nœuds à l'aide de la CLI Tanzu. Cet exemple utilise le cluster de charge de travail tkg-wc, mais il peut également s'agir d'un cluster de gestion :
```
tanzu cluster node-pool set wl-antrea -f md-1.yaml

Cluster update for node pool 'md-1' completed successfully
```

Obtenez le nom du déploiement de machines dans la valeur node-pool créée :

kubectl get machinedeployments -l
topology.cluster.x-k8s.io/deployment-name=md-1
-o=jsonpath='{.items[*].metadata.name}'

wl-antrea-md-1-pd9vj

Vérifiez que le déploiement de machines est mis à jour avec VSphereFailureDomain rack2 :

kubectl get machinedeployments wl-antrea-md-1-pd9vj -o json | \
jq -r '.spec.template.spec.failureDomain'

rack2

Vérifiez que le nœud worker de md-1 est déployé dans rack2.

Mettre à jour la CPI et la CSI pour les modifications de la zone de disponibilité

Lorsque vous modifiez la configuration de la zone de disponibilité d'un cluster de charge de travail, comme décrit dans l'une des sections ci-dessus, vous devez mettre à jour ses configurations de modules complémentaires CPI et CSI, puis recréer ces derniers pour appliquer les modifications. Les procédures ci-dessous expliquent la marche à suivre.

Limitations :

Avant d'activer plusieurs zones de disponibilité pour un cluster existant ou de déplacer ses nœuds worker ou de plan de contrôle vers une autre zone de disponibilité pour un cluster existant, vous devez vous assurer que les nouveaux nœuds de cluster peuvent accéder au volume persistant (PV) d'origine du cluster.
Tous les paramètres tagCategory dans différentes régions et zones dans VsphereFailureDomain doivent correspondre.
Avant d'activer plusieurs zones de disponibilité pour vSphere CSI, vous devez activer multi-az kcp/worker.

Mettre à jour la CPI après avoir modifié la zone de disponibilité

Pour mettre à jour la configuration du module complémentaire CPI d'un cluster afin d'appliquer une modification de la zone de disponibilité, puis supprimer le programme d'installation du module correspondant pour recréer le module complémentaire avec les modifications :

Récupérez le nom de la vsphereCPIConfig du cluster à l'aide de la référence cb. Par exemple, avec un cluster de charge de travail nommé wl :
```
kubectl -n default get cb wl -o json \| jq -r '.spec.cpi.valuesFrom.providerRef.name'
```

Modifiez la spécification vsphereCPIConfig du cluster pour définir sa region et sa zone sur les champs tagCategory que vous avez définis pour la région et la zone de la zone de disponibilité dans vSphere et dans la spécification vsphereFailuredomain. Par exemple :

apiVersion: cpi.tanzu.vmware.com/v1alpha1
kind: VSphereCPIConfig
metadata:
  name: wl
  namespace: default
spec:
  vsphereCPI:
    mode: vsphereCPI
    region: k8s-zone
    tlsCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  vmNetwork:
    excludeExternalSubnetCidr: 10.215.10.79/32
    excludeInternalSubnetCidr: 10.215.10.79/32
  zone: k8s-zone

Appliquez les modifications et attendez que Reconcile succeeded.
Vérifiez que le programme d'installation du module CPI (pkgi) a réinstallé les éléments suivants :
```
kubectl -n tkg-system get wl-vsphere-cpi pkgi --context wl-admin@wl
```

Mettre à jour la CSI après avoir modifié la zone de disponibilité

Pour mettre à jour la configuration du module complémentaire CSI d'un cluster afin d'appliquer une modification de la zone de disponibilité, puis supprimer la csinodetopology et le programme d'installation du module correspondant pour recréer le module complémentaire avec les modifications :

Récupérez le nom de la vsphereCPIConfig du cluster à l'aide de la référence cb. Par exemple, avec un cluster de charge de travail nommé wl :
```
kubectl -n default get cb wl  -o json  |jq  -r '.spec.csi.valuesFrom.providerRef.name')
```

Modifiez la spécification vsphereCSIConfig du cluster pour définir sa region et sa zone sur les champs tagCategory que vous avez définis pour la région et la zone de la zone de disponibilité dans vSphere et dans la spécification vsphereFailuredomain. Par exemple :

apiVersion: csi.tanzu.vmware.com/v1alpha1
kind: VSphereCSIConfig
metadata:
  name: wl
  namespace: default
spec:
  vsphereCSI:
    config:
      datacenter: /dc0
      httpProxy: ""
      httpsProxy: ""
    insecureFlag: true
    noProxy: ""
  region: k8s-region
  tlsThumbprint: ""
  useTopologyCategories: true
  zone: k8s-zone
mode: vsphereCSI

Appliquez les modifications.
Supprimez les objets csinode et csiNodeTopology afin de les recréer. csinodetopology ne se met pas à jour automatiquement :
```
kubectl -n delete csinode --all --context wl-admin@wl
kubectl -n delete csinodetopology --all --context wl-admin@wl
```
Supprimez le programme d'installation du module vsphere-csi du cluster et attendez que Reconcile succeeded.
```
kubectl delete pkgi -n tkg-system wl-vsphere-csi --context wl-admin@wl
```

Vérifiez que tous les objets csinodes incluent le paramètre topologyKeys, par exemple :

kubectl get csinodes -o jsonpath='{range .items[*]}{.metadata.name} {.spec}{"\n"}{end}'

k8s-control-1 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-control-1","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-control-2 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-control-2","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-control-3 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-control-3","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-node-1 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-node-1","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-node-2 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-node-2","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-node-3 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-node-3","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-node-4 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-node-4","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-node-5 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-node-5","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-node-6 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-node-6","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}

Vérifiez que les étiquettes de topologie de tous les nœuds reflètent les zones et les régions de la zone de disponibilité appropriée, par exemple :

kubectl get nodes --show-labels
NAME            STATUS   ROLES                  AGE  VERSION   LABELS
k8s-control-1   Ready    control-plane          1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-A
k8s-control-2   Ready    control-plane          1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-B
k8s-control-3   Ready    control-plane          1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-C
k8s-node-1      Ready    <none>                 1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-A
k8s-node-2      Ready    <none>                 1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-B
k8s-node-3      Ready    <none>                 1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-B
k8s-node-4      Ready    <none>                 1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-C
k8s-node-5      Ready    <none>                 1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-2,topology.csi.vmware.com/k8s-zone=zone-D
k8s-node-6      Ready    <none>                 1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-2,topology.csi.vmware.com/k8s-zone=zone-D

Répertorier les zones de disponibilité

Utilisez la commande tanzu mc az list pour répertorier les zones de disponibilité définies dans le cluster de gestion autonome ou utilisées par un cluster de charge de travail :

Pour répertorier les zones de disponibilité actuellement utilisées par un cluster de gestion et ses clusters de charge de travail :
```
tanzu management-cluster available-zone list
```
Pour répertorier toutes les zones de disponibilité définies dans le cluster de gestion et, par conséquent, disponibles pour les nœuds de cluster de charge de travail :
```
tanzu management-cluster available-zone list -a
```
Pour les zones de disponibilité actuellement utilisées par le cluster de charge de travail CLUSTER-NAME :
```
tanzu management-cluster available-zone list -c CLUSTER-NAME:
```

Les commandes tanzu mc az sont mises en alias à partir de tanzu management-cluster available-zone.

Exemple de sortie :

AZNAME   ZONENAME  ZONETYPE    REGIONNAME REGIONTYPE DATASTORE   NETWORK   OWNERCLUSTER STATUS
us-west-1a us-west-1a ComputeCluster us-west-1  Datacenter sharedVmfs-0 VM Network az-1     ready
us-west-1b us-west-1b ComputeCluster us-west-1  Datacenter sharedVmfs-0 VM Network az-1     ready
us-west-1c us-west-1c ComputeCluster us-west-1  Datacenter sharedVmfs-0 VM Network az-1     ready

La sortie répertorie les éléments suivants :

AZNAME, ZONENAME : nom de la zone de disponibilité
ZONETYPE : type d'objet vSphere étendu à la zone de disponibilité, ComputeCluster ou HostGroup
REGIONNAME : nom de la région qui contient la zone de disponibilité
REGIONTYPE : type d'objet vSphere étendu à la région, Datacenter ou ComputeCluster
DATASTORE : banque de données qui héberge les machines virtuelles dans la région
NETWORK : réseau servant les VM dans la région
OWNERCLUSTER : Cluster ou clusters TKG qui s'exécutent dans la zone de disponibilité
STATUS : état actuel de la zone de disponibilité

Le groupe de commandes tanzu mc az est mis en alias à partir de tanzu management-cluster available-zone.

Supprimer les zones de disponibilité

Utilisez la commande tanzu mc az delete pour supprimer une zone de disponibilité inutilisée, par exemple :

tanzu mc az delete AZNAME

Où AZNAME est le nom de la zone de disponibilité tel que répertorié par tanzu mc az list.

Vous pouvez uniquement supprimer une zone de disponibilité si elle n'héberge actuellement pas de nœuds de cluster TKG, comme indiqué par la tanzu mc az list ne répertoriant aucun OWNERCLUSTER pour la zone de disponibilité.

Exécution de clusters sur plusieurs zones de disponibilité

Présentation

Définition des zones de disponibilité

Configuration de clusters pour utiliser des zones de disponibilité

Conditions requises

Déployer des clusters de charge de travail sur plusieurs zones de disponibilité

Préparer des régions et des zones de disponibilité dans vSphere

Créer des objets FailureDomain et DeploymentZone dans Kubernetes

Déployer le cluster

Mettre à jour des clusters existants pour utiliser plusieurs zones de disponibilité ou différentes zones de disponibilité

Ajouter des zones de disponibilité pour les nœuds de plan de contrôle

Utiliser les étiquettes de sélecteur pour spécifier de nouvelles zones de disponibilité du plan de contrôle

Modifier les zones de disponibilité de déploiement de machines

Ajouter des zones de disponibilité pour les déploiements de machines

Ajouter des zones de disponibilité et de nouveaux déploiements de machines

Mettre à jour la CPI et la CSI pour les modifications de la zone de disponibilité

Mettre à jour la CPI après avoir modifié la zone de disponibilité

Mettre à jour la CSI après avoir modifié la zone de disponibilité

Répertorier les zones de disponibilité

Supprimer les zones de disponibilité

Créer des objets `FailureDomain` et `DeploymentZone` dans Kubernetes