Esecuzione di cluster in più zone di disponibilità

In questo argomento viene descritto come distribuire nuovi cluster del carico di lavoro di Tanzu Kubernetes Grid (TKG) eseguiti in più zone di disponibilità (ZD) e come modificare i cluster di gestione e del carico di lavoro esistenti in modo che vengano eseguiti in più zone di disponibilità o in zone di disponibilità diverse.

Per utilizzare l'interfaccia del programma di installazione per configurare un nuovo cluster di gestione autonomo che viene eseguito su più ZD, vedere Configurazione delle risorse di vSphere in Distribuzione dei cluster di gestione con l'interfaccia del programma di installazione.

Nota
Questo argomento si applica a TKG con un cluster di gestione autonomo. Per l'esecuzione di TKG con un supervisore nelle zone di disponibilità, vedere Create vSphere zone per una distribuzione di un supervisore a più zone nella documentazione di vSphere 8.0.

Panoramica

In TKG su vSphere, è possibile definire facoltativamente regioni e ZD in Kubernetes per ospitare cluster di gestione autonomi e relativi cluster del carico di lavoro, contrassegnandoli quindi in vSphere per associarli a cluster vSphere, gruppi di host o data center.

Questa configurazione consente a TKG di supportare la distribuzione dei carichi di lavoro e la ridondanza su vSphere in modo simile a come funziona con regioni e ZD in altre infrastrutture.

Senza questi costrutti, è possibile posizionare i cluster TKG a livello di vSphere facendo riferimento direttamente agli oggetti vSphere, ma in questo caso TKG e Kubernetes non sono in grado di gestire il loro posizionamento.

Definizione delle ZD

Per definire le ZD in TKG su vSphere, si creano oggetti Kubernetes e si associano a oggetti vSphere in base al modo in cui viene definito l'ambito delle ZD:

Oggetti Kubernetes: Per abilitare più zone di disponibilità per i cluster in vSphere, Cluster API Provider vSphere (CAPV) utilizza due definizioni di risorse personalizzate (CRD):

Il CRD VSphereFailureDomain acquisisce le informazioni sull'assegnazione di tag specifici per regione/zona e la definizione della topologia che include le informazioni relative a data center, cluster, host e datastore vSphere.
Il CRD VSphereDeploymentZone acquisisce l'associazione di un VSphereFailureDomain con le informazioni sul vincolo di posizionamento per il nodo Kubernetes.

Per creare questi oggetti, si definiscono nelle specifiche di un oggetto, come ad esempio un file vsphere-zones.yaml, che sarà quindi possibile utilizzare per creare gli oggetti in momenti diversi, come indicato di seguito:

Quando si crea per la prima volta il cluster di gestione, passare il file all'opzione --az-file di tanzu mc create.
- Per eseguire il cluster di gestione all'interno delle ZD definite, è necessario creare gli oggetti ZD in questo momento secondo la modalità indicata.
- Se si prevede di aver bisogno di ulteriori oggetti ZD per i cluster del carico di lavoro e di mantenere tutte le definizioni della ZD in un'unica posizione, è possibile definire zone di disponibilità aggiuntive in questo stesso file. In tal caso, impostare SKIP_MULTI_AZ_VERIFY=true come variabile env per ignorare la convalida di vSphere, come descritto in Controlli convalida in Eseguire il comando tanzu mc create, perché le ZD aggiuntive potrebbero non avere ancora tutte le configurazioni vSphere.
Dopo aver creato il cluster di gestione, ma prima di creare i cluster del carico di lavoro che richiedono il posizionamento degli oggetti ZD, passare il file all'opzione -f del comando tanzu mc az set o kubectl apply.
Quando si creano cluster del carico di lavoro, passare il file all'opzione --az-file di tanzu cluster create.

Per elencare gli oggetti ZD già creati, eseguire:

kubectl get VSphereFailureDomain,VSphereDeploymentZone -a

Kubernetes all'associazione vSphere: Le definizioni degli oggetti VSphereFailureDomain e VSphereDeploymentZone definiscono regioni e ZD con le impostazioni seguenti:

Regione: spec.region
Zona/ZD: spec.zone

I tag vSphere k8s-region e k8s-zone associano le regioni e le ZD in Kubernetes ai rispettivi oggetti sottostanti nel vSphere.

Ambito ZD: È possibile creare l'ambito delle ZD e delle regioni a livelli diversi in vSphere associandoli a vSphere oggetti nel modo seguente:

Ambito ZD	Zona/ZD	Regione	Utilizzo più ZD
ZD cluster	Cluster vSphere	data center vSphere	Distribuire i nodi in più cluster in un data center
Zone di disponibilità del gruppo di host	vSphere gruppo di host	Cluster vSphere	Distribuire i nodi su più host in un singolo cluster

Le configurazioni in questo argomento si riferiscono ai nodi del piano di controllo e ai nodi worker del cluster TKG negli oggetti di vSphere, ovvero data center, cluster e host vSphere, in base al modo in cui gli oggetti vengono contrassegnati in vSphere e citati nelle definizioni VSphereFailureDomain e VSphereDeploymentZone in Kubernetes.

Configurazione dei cluster per l'utilizzo delle ZD

Con gli oggetti VSphereFailureDomain e VSphereDeploymentZone definiti per le ZD in Kubernetes, è possibile configurare il modo in cui i cluster li utilizzano tramite le variabili del file di configurazione o le proprietà degli oggetti Cluster.

Variabili di configurazione: Per utilizzare le variabili di configurazione del cluster, impostare VSPHERE_AZ_0, VSPHERE_AZ_1, VSPHERE_AZ_2, VSPHERE_AZ_CONTROL_PLANE_MATCHING_LABELS, VSPHERE_REGION e VSPHERE_ZONE come descritto in vSphere in Riferimento delle variabili del file di configurazione.

Proprietà oggetto: Per le proprietà dell'oggetto Cluster, la specifica dell'oggetto configura le ZD per il piano di controllo e i nodi worker in modi diversi, abbinando proprietà diverse degli oggetti VSphereDeploymentZone che definiscono le ZD:

Tipo di nodo	Proprietà in `spec.topology`	Per la corrispondenza con le proprietà `VSphereDeploymentZone`	Esempio
Nodi del piano di controllo	`variables.controlPlaneZoneMatchingLabels`	Elenco di coppie `metadata.labels`	`{"environment": "staging", "region": "room1"}`
Nodi worker	`machineDeployments.MD-INDEX.failureDomain` per ogni distribuzione di macchina	Elenco dei valori di `metadata.name`	`[rack1,rack2,rack3]`

Poiché i nodi del piano di controllo vengono assegnati alle ZD in base alla corrispondenza delle etichette, è necessario creare un'etichetta che distingua ogni combinazione di ZD che i nodi dei piani di controllo del cluster potrebbero utilizzare.

Prerequisiti

I prerequisiti per la distribuzione o la modifica dei cluster TKG in modo che vengano eseguiti in più ZD o in ZD diverse includono:

Un cluster di gestione Tanzu Kubernetes Grid con cluster del carico di lavoro in esecuzione in vSphere.
All'account vSphere configurato per TKG è stata aggiunta l'autorizzazione seguente, come descritto in Autorizzazioni necessarie per l'account vSphere:
- Host > Inventario > Modifica cluster

Distribuzione dei cluster del carico di lavoro in più ZD

È possibile distribuire un cluster del carico di lavoro in modo che esegua i nodi del piano di controllo o i nodi worker in più zone di disponibilità in tre passaggi, come descritto nelle sezioni seguenti:

Preparazione di regioni e ZD in vSphere
Creazione di oggetti FailureDomain e DeploymentZone in Kubernetes
Distribuzione del cluster

Preparazione di regioni e ZD in vSphere

Per preparare vSphere per supportare regioni e ZD in TKG:

Identificare o creare gli oggetti vSphere per le regioni e le ZD in cui saranno ospitati i nodi del cluster TKG.
- Zone di disponibilità del gruppo di host: Se si utilizzano gruppi di host vSphere come ZD, è necessario creare un gruppo di host e un gruppo di macchine virtuali corrispondente per ogni ZD che si intende utilizzare:
  1. Creare oggetti gruppo di host e gruppo di macchine virtuali in uno dei modi seguenti:
    - In vCenter creare un gruppo di host e un gruppo di macchine virtuali da Configura (Configure) > Gruppi di macchine virtuali/host (VM/Host Groups) > Aggiungi (Add)…
      - Per creare un gruppo di host, potrebbe essere necessario creare una macchina virtuale fittizia da aggiungere come membro del gruppo.
    - Con la CLI govc, eseguire i comandi di govc in modo simile a quanto segue. Ad esempio per creare un gruppo di host rack1 e un gruppo di macchine virtuali 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. Aggiungere regole di affinità tra i gruppi di macchine virtuali creati e i gruppi di host in modo che le macchine virtuali nel gruppo di macchine virtuali debbano essere eseguite negli host del gruppo di host creato:
    - Impostare Tipo (Type) su Da macchine virtuali a host (Virtual Machines to Hosts) e includere la regola Deve essere eseguita negli host del gruppo (Must run on hosts in group).

Contrassegnare gli oggetti vSphere nel modo seguente, a seconda che si stiano configurando vSphere ZD del cluster o dei gruppi di host. Questi esempi utilizzano la CLI govc ma è anche possibile utilizzare il riquadro Tags & Custom Attributes in vCenter:

Zone di disponibilità del cluster:

Per ogni ZD, utilizzare govc per creare e collegare un tag di categoria k8s-region al data center e un tag di categoria k8s-zone a ogni cluster di vSphere. Ad esempio, per contrassegnare data center dc0 come regione us-west-1 e i relativi cluster cluster1 ecc. come ZD us-west-1a ecc.:

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

Zone di disponibilità del gruppo di host:

Per ogni ZD, utilizzare govc per creare e collegare un tag di categoria k8s-region al cluster vSphere e un tag di categoria k8s-zone a ogni host. Ad esempio, per contrassegnare il cluster /dc1/host/room1-mgmt come regione room1 e l'host nel relativo gruppo /dc1/host/room1-mgmt/esx-01a.corp.tanzu come ZD rack1 ecc.:

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

Identificare o creare i pool di risorse e le cartelle vSphere da utilizzare per posizionare le macchine virtuali per ciascuna ZD. Questi esempi utilizzano la CLI govc, ma è possibile eseguire questa operazione anche nei riquadri Inventario in vCenter:
- Zone di disponibilità del cluster:
  
  Per ogni ZD, utilizzare govc per creare un oggetto resource-pool in ogni cluster vSphere corrispondente a ciascuna delle 3 ZD e delle 3 cartelle delle macchine virtuali
```
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
```
- Zone di disponibilità del gruppo di host:
  
  Per ogni ZD, utilizzare govc per creare 3 oggetti resource-pool e 3 cartelle di macchine virtuali
```
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
```

Creazione di oggetti `FailureDomain` e `DeploymentZone` in Kubernetes

Prima di distribuire un cluster in più zone di disponibilità, è necessario definire gli oggetti Kubernetes FailureDomain e DeploymentZone per la regione e le zone, come descritto precedentemente in Definizione delle ZD.

Ogni impostazione in spec.region, spec.zone e spec.topology deve corrispondere ai percorsi e ai tag degli oggetti configurati nel vCenter:

Per gli oggetti VSphereDeploymentZone, il valore di spec.failuredomain deve corrispondere a uno dei valori di metadata.name delle definizioni di VSphereFailureDomain.
Il valore spec.server negli oggetti VSphereDeploymentZone devono corrispondere all'indirizzo (IP o FQDN) del server vCenter immesso per SERVER VCENTER (VCENTER SERVER) nel riquadro dell'interfaccia del programma di installazione Provider IaaS (IaaS Provider) o nell'impostazione VSPHERE_SERVER nel file di configurazione del cluster di gestione.
I valori metadata.name devono essere tutti in minuscolo.

Creare le definizioni degli oggetti FailureDomain e DeploymentZonecome indicato di seguito, a seconda che si stiano configurando zone di disponibilità di cluster o di gruppi di host vSphere.

Zone di disponibilità del cluster:

Come esempio di come distribuire il cluster del carico di lavoro in più nodi del cluster vSphere all'interno di un data center, il codice seguente definisce gli oggetti necessari per tre zone di distribuzione denominate us-west-1a, us-west-1b e us-west-1c, ognuna delle quali è un cluster vSphere che dispone di parametri di rete e storage propri:

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

VSPHERE_SERVER è l'indirizzo IP o l'FQDN di vCenter Server.

Se cluster di vSphere diversi hanno pool di risorse con nome identico, impostare spec.placementConstraint.resourcePool degli oggetti di VSphereDeploymentZone su un percorso di risorsa completo, non solo sul nome.

Zone di disponibilità del gruppo di host:

Come esempio di come distribuire i nodi del cluster del carico di lavoro in tre gruppi di host in un singolo cluster vSphere, il codice seguente definisce gli oggetti necessari per tre ZD, rack1, rack2 e rack3, ciascuno dei quali rappresenta un rack di host all'interno dello stesso cluster vSphere, definito come regione 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

VSPHERE_SERVER è l'indirizzo IP o l'FQDN di vCenter Server.

Dopo aver creato le definizioni degli oggetti FailureDomain e DeploymentZone per le ZD, continuare in base al tipo di cluster che si sta distribuendo:

Cluster di gestione autonomo: Continuare con Configurare più zone di disponibilità come parte della Distribuzione di un cluster di gestione da un file di configurazione.
Cluster del carico di lavoro: Continuare con Distribuzione del cluster di seguito.

Distribuzione del cluster

Dopo aver eseguito i passaggi in Preparare regioni e ZD in vSphere e Creare oggetti FailureDomain e DeploymentZone in Kubernetes, è possibile distribuire un cluster del carico di lavoro con i relativi nodi distribuiti tra più zone di disponibilità.

I passaggi seguenti utilizzano vsphere-zones.yaml come file contenente FailureDomain e le definizioni di oggetti DeploymentZone.

Seguire vSphere con File di configurazione del cluster di gestione autonomo per creare il file di configurazione del cluster per il cluster del carico di lavoro che si sta distribuendo.
Controllare o modificare le variabili ZD nel file di configurazione del cluster in modo che corrispondano alle definizioni degli oggetti ZD:
- Impostare VSPHERE_REGION e VSPHERE_ZONE sulle categorie di tag di regione e zona, k8s-region e k8s-zone.
  - Queste variabili configurano anche la topologia CSI; vedere Distribuzione di un cluster con tag di regione e zona per CSI.
- Impostare VSPHERE_AZ_0, VSPHERE_AZ_1 e VSPHERE_AZ_2 con i nomi degli oggetti VsphereDeploymentZone in cui le macchine devono essere distribuite.
  - La VsphereDeploymentZone associata a VSPHERE_AZ_0 è il VSphereFailureDomain in cui viene distribuita la distribuzione della macchina che termina con md-0, analogamente VSPHERE_AZ_1 è il VSphereFailureDomain in cui viene distribuita la distribuzione della macchina che termina con md-1 e VSPHERE_AZ_2 è il VSphereFailureDomain in cui viene distribuita la distribuzione della macchina che termina con md-2
  - Se una qualsiasi delle configurazioni ZD non è definita, la distribuzione della macchina viene distribuita senza VSphereFailureDomain
- WORKER_MACHINE_COUNT imposta il numero totale di worker per il cluster. Il numero totale di worker viene distribuito in modalità round robin per il numero di ZD specificato
- VSPHERE_AZ_CONTROL_PLANE_MATCHING_LABELS imposta le etichette del selettore chiave/valore per le ZD in cui possono essere distribuiti i nodi del piano di controllo del cluster.
  - Impostare questa variabile se sono impostati VSPHERE_REGION e VSPHERE_ZONE.
  - Le etichette devono esistere nelle risorse VSphereDeploymentZone create.
  - Queste etichette consentono di specificare tutte le ZD in una regione e ambiente senza doverle elencare singolarmente, ad esempio: "region=us-west-1,environment=staging".
Le variabili di configurazione dei cluster per le zone di disponibilità funzionano nello stesso modo per i cluster di gestione autonomi e i cluster del carico di lavoro. Per l'elenco completo delle opzioni che è necessario specificare quando si distribuiscono cluster del carico di lavoro in vSphere, vedere Informazioni di riferimento sulle variabili del file di configurazione.
Eseguire tanzu cluster create per creare il cluster del carico di lavoro. Per ulteriori informazioni, vedere Creazione di cluster del carico di lavoro.
- Per creare gli oggetti ZD separatamente dalla creazione del cluster, accedere al cluster di gestione con tanzu login ed eseguire quanto segue prima di eseguire tanzu cluster create:
```
tanzu mc az set -f vsphere-zones.yaml
```
  In alternativa, è possibile eseguire kubectl apply -f vsphere-zones.yaml
- Per utilizzare le definizioni degli oggetti ZD con un file di configurazione del cluster flat e creare gli oggetti ZD e cluster insieme, passare il file vsphere-zones.yaml all'opzione --az-file di tanzu cluster create:
```
tanzu cluster create --file cluster-config-file.yaml --az-file vsphere-zones.yaml
```
- Per combinare le definizioni degli oggetti ZD nel manifesto di un cluster, creare il manifesto del cluster eseguendo il passaggio 1 del processo in due passaggi descritto in Creazione di un cluster basato sulla classe, aggiungere il contenuto di vsphere-zones.yaml nel manifesto e quindi eseguire tanzu cluster create come descritto nel passaggio 2.
- Durante il processo di creazione del cluster, è possibile visualizzare le macchine virtuali e le altre risorse in vCenter.
- Se è stata creata una macchina virtuale fittizia in vCenter per creare un gruppo di macchine virtuali, è possibile eliminare o rimuovere la macchina virtuale dai gruppi di macchine virtuali dopo che il cluster è in esecuzione.

Aggiornamento dei cluster esistenti per l'utilizzo di più zone di disponibilità o di zone di disponibilità diverse

È possibile aggiornare un cluster del carico di lavoro o di gestione già distribuito per eseguirne il piano di controllo o i nodi di lavoro in più zone di disponibilità o per modificare le ZD in cui vengono eseguiti i nodi.

È possibile assegnare le ZD al piano di controllo di un cluster o ai nodi di lavoro nel suo insieme oppure impostare le ZD per le distribuzioni delle macchine sottostanti per personalizzare le impostazioni delle macchine vSphere insieme alle ZD per il set di distribuzione delle macchine.

Dopo aver aggiornato le ZD di un cluster del carico di lavoro esistente, è necessario aggiornarne l'interfaccia CSI (Container Storage Interface) e CPI (Cloud Provider Interface) per riflettere la modifica, come descritto in Aggiornamento di CSI e CPI per le modifiche delle ZD.

Nelle sezioni seguenti viene illustrato come aggiornare le configurazioni delle ZD del cluster esistente per scenari differenti.

Aggiunta di ZD per i nodi del piano di controllo

Per espandere un cluster esistente i cui nodi del piano di controllo vengono eseguiti in una singola ZD in modo che il suo piano di controllo venga eseguito in più ZD:

Preparare un file di configurazione che definisca un oggetto VSphereFailureDomain e VSphereDeploymentZone per ogni nuova ZD. Nell'esempio seguente, vsphere-3-zones.yaml definisce le ZD rack1, rack2 e rack3 con regione 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

VSPHERE_SERVER è l'indirizzo IP o l'FQDN di vCenter Server.

Note:

Assicurarsi che i tag siano stati creati e che le risorse nell'inventario di vCenter Server siano state contrassegnate correttamente come descritto in Tag di vSphere nella documentazione del prodotto di vSphere.
È necessario impostare spec.placementConstraint.resourcePool in VSphereDeploymentZone. Se per il cluster non è presente alcun pool di risorse creato dall'utente, impostare il valore sul pool di risorse predefinito del cluster, il cui percorso è /dc0/host/cluster1/Resources.
Per gli oggetti VSphereFailureDomain, spec.region.autoConfigure e spec.zone.autoConfigure non sono più supportati.

Creare gli oggetti vSphereFailureDomain e VSphereDeploymentZone, ad esempio:
```
tanzu mc az set -f vsphere-3-zones.yaml
```
Ottenere KubeAdmControlPlane del cluster di destinazione. In questo esempio, la destinazione è il cluster di gestione tkg-mgmt-vc, ma può anche essere un cluster del carico di lavoro:
```
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
```

Aggiornare il selettore ZD del cluster, ad esempio 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

Verificare che il dominio di errore del cluster sia stato aggiornato come previsto:

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

Applicare una patch a KubeAdmControlPlane con rolloutAfter per attivare un aggiornamento dei nodi del piano di controllo.

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

Verificare che i nodi del piano di controllo siano stati spostati nelle nuove ZD controllando l'host e il datastore dei nodi nel vCenter oppure eseguendo comandi kubectl get node o govc vm.info come i seguenti:
- 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'

Utilizzo delle etichette del selettore per specificare le nuove ZD del piano di controllo

Se si selezionano le ZD con etichette del selettore, VSphereDeploymentZone viene specificato in base a metadata.labels anziché a metadata.name. In questo modo è possibile configurare i nodi del piano di controllo di un cluster, ad esempio in modo che vengano eseguiti in tutte le ZD in una regione e in un ambiente specificati senza elencare singolarmente le ZD: "region=us-west-1,environment=staging". Significa inoltre che è possibile aggiornare le ZD di un piano di controllo del cluster senza dover modificare i nomi delle ZD per i nodi del piano di controllo.

Per utilizzare le etichette del selettore per specificare nuove ZD per i nodi del piano di controllo di un cluster esistente:

Preparare un file di configurazione che definisca un oggetto VSphereFailureDomain e VSphereDeploymentZone per ogni nuova ZD. Nell'esempio seguente, vsphere-labeled-zones.yaml definisce una ZD rack4 con i metadati delle etichette del selettore:

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

Creare gli oggetti VSphereFailureDomain e VSphereDeploymentZone, ad esempio:
```
tanzu mc az set -f vsphere-labeled-zones.yaml
```
Aggiornare il cluster con l'etichetta del selettore ZD. Nell'esempio riportato di seguito viene utilizzato un selettore ZD controlPlaneZoneMatchingLabels: {"environment": "staging", "region": "room1"} per il cluster di gestione tkg-mgmt-vc, ma può anche essere un cluster del carico di lavoro:
```
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
```
Controllare lo stato del cluster per assicurarsi che il dominio di errore sia stato aggiornato come previsto:
```
kubectl get cluster tkg-mgmt-vc -n tkg-system -o json | jq -r '.status.failureDomains | to_entries[].key'
```

Applicare una patch a KubeAdmControlPlane con rolloutAfter per attivare un aggiornamento dei nodi del piano di controllo.

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

Verificare che i nodi del piano di controllo vengano spostati nelle nuove ZD selezionate dal selettore in controlPlaneZoneMatchingLabels controllando l'host e il datastore dei nodi nel vCenter oppure eseguendo comandi kubectl get node o govc vm.info come i seguenti. In questo esempio, la nuova zona di disponibilità è 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'

Modifica delle ZD di distribuzione delle macchine

Per modificare una configurazione ZD in un cluster esistente, applicare patch alle configurazioni MachineDeployment sottostanti dei nodi con il nuovo valore ZD.

Ad esempio, se il file di configurazione del cluster imposta VSPHERE_AZ_0 su rack1 e si desidera spostarne i nodi di lavoro in rack2:

Eseguire una query sulle ZD correnti utilizzate per il cluster. In questo esempio viene utilizzato un cluster del carico di lavoro tkg-wc, ma può anche essere un cluster di gestione:
```
kubectl get cluster tkg-wc -o json \| jq -r '.spec.topology.workers.machineDeployments\[0\].failureDomain'
```

Elencare tutte le ZD disponibili.

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

rack1
rack2

Applicare una patch alla configurazione di spec.toplogy.workers.machineDeployments del cluster tkg-wc per impostare la zona VSphereFailureDomain su rack2. In questo esempio si presuppone che tkg-wc sia un cluster del piano dev a nodo singolo. Per un cluster del piano prod, è necessario applicare una patch a tutte e tre le configurazioni degli oggetti MachineDeployment nel 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
```

Verificare che il cluster sia aggiornato con VSphereFailureDomain rack2.

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

rack2

Verificare che i nodi di lavoro siano ora distribuiti in VSphereFailureDomain rack2.

Aggiunta di ZD per le distribuzioni di macchine

Per configurare nuove ZD per l'uso da parte dei cluster TKG e quindi utilizzarle in un cluster esistente:

Preparare un file di configurazione che definisca un oggetto VSphereFailureDomain e VSphereDeploymentZone per ogni nuova ZD. Utilizzare l'esempio vsphere-3-zones.yaml in Aggiunta di ZD per i nodi del piano di controllo sopra, che definisce le ZD rack1, rack2 e rack3 con regione room1.
Creare gli oggetti VSphereFailureDomain e VSphereDeploymentZone.
```
tanzu mc az set -f vsphere-3-zones.yaml
```
In alternativa, è possibile eseguire kubectl apply -f vsphere-3-zones.yaml

Applicare una patch al cluster tkg-wc con VSphereFailureDomain rack1, rack2 e rack3. In questo esempio, tkg-wc è un piano del cluster prod con tre configurazioni MachineDeployment. Con un cluster dev è necessario aggiornare solo un MachineDeployment in spec.toplogy.workers.machineDeployments del 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"}]'

Verificare che il cluster venga aggiornato con le nuove ZD.

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

Verificare che i relativi nodi di lavoro siano ora distribuiti in VSphereFailureDomain rack1, rack2 e rack3.

Aggiunta di ZD e nuove distribuzioni di macchine

Per configurare sia nuove ZD che nuovi oggetti MachineDeployment per l'uso da parte dei cluster TKG e utilizzarli in un cluster esistente:

Preparare un file di configurazione che definisca un oggetto VSphereFailureDomain e VSphereDeploymentZone per ogni nuova ZD. Nell'esempio seguente, vsphere-1-zone.yaml definisce una nuova ZD rack2 con regione 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

Creare gli oggetti VSphereFailureDomain e VSphereDeploymentZone.
```
tanzu mc az set -f vsphere-zones.yaml
```
In alternativa, è possibile eseguire kubectl apply -f vsphere-1-zone.yaml
Preparare un file di configurazione per la distribuzione di nuove macchine. Nell'esempio seguente, md-1.yaml definisce una nuova distribuzione di macchine md-1 con la proprietà az impostata su rack2:
```
name: md-1
replicas: 1
az: rack2
nodeMachineType: t3.large
workerClass: tkg-worker
tkrResolver: os-name=ubuntu,os-arch=amd64
```
Utilizzare la CLI di Tanzu per creare un nuovo pool di nodi. In questo esempio viene utilizzato il cluster del carico di lavoro tkg-wc, ma può anche essere usato un cluster di gestione:
```
tanzu cluster node-pool set wl-antrea -f md-1.yaml

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

Recuperare il nome della distribuzione della macchina nel nuovo pool di nodi creato:

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

wl-antrea-md-1-pd9vj

Verificare che la distribuzione di macchine sia aggiornata con VSphereFailureDomain rack2:

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

rack2

Verificare che il nodo di lavoro di md-1 sia distribuito in rack2.

Aggiornamento di CPI e CSI per le modifiche delle ZD

Dopo aver modificato la configurazione delle ZD di un cluster del carico di lavoro come descritto in una delle sezioni precedenti, è necessario aggiornare le configurazioni dei componenti aggiuntivi CPI e CSI e quindi ricreare i componenti aggiuntivi per riflettere le modifiche. Le procedure seguenti descrivono come eseguire questa operazione.

Limiti:

Prima di abilitare più ZD per un cluster esistente o spostarne i nodi di lavoro o del piano di controllo in una ZD diversa per un cluster esistente, è necessario assicurarsi che tutti i nuovi nodi del cluster possano accedere al volume persistente (PV) originale del cluster.
Tutte le impostazioni tagCategory in regioni e zone diverse in VsphereFailureDomain devono corrispondere.
Prima di abilitare più ZD per vSphere CSI, è necessario abilitare multi-az kcp/worker.

Aggiornamento di CPI dopo la modifica delle ZD

Per aggiornare la configurazione del componente aggiuntivo CPI di un cluster in modo da riflettere una modifica delle ZD, quindi per eliminare il programma di installazione del pacchetto corrispondente per ricreare il componente aggiuntivo con le modifiche:

Recuperare il nome di vsphereCPIConfig del cluster utilizzando il riferimento cb. wl

kubectl -n default get cb wl -o json \| jq -r '.spec.cpi.valuesFrom.providerRef.name'

Modificare la specifica vsphereCPIConfig del cluster per impostarne region e zone nei campi tagCategory impostati per la regione e la zona delle ZD in vSphere e nella specifica vsphereFailuredomain. Ad esempio:

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

Applicare le modifiche e attendere Reconcile succeeded.
Verificare che il programma di installazione del pacchetto CPI (pkgi) sia stato reinstallato:
```
kubectl -n tkg-system get wl-vsphere-cpi pkgi --context wl-admin@wl
```

Aggiornamento di CSI dopo la modifica delle ZD

Per aggiornare la configurazione del componente aggiuntivo CSI di un cluster in modo da riflettere una modifica delle ZD, quindi per eliminare csinodetopology e il programma di installazione del pacchetto corrispondente per ricreare il componente aggiuntivo con le modifiche:

Recuperare il nome di vsphereCPIConfig del cluster utilizzando il riferimento cb. wl

kubectl -n default get cb wl  -o json  |jq  -r '.spec.csi.valuesFrom.providerRef.name')

Modificare la specifica vsphereCSIConfig del cluster per impostarne region e zone nei campi tagCategory impostati per la regione e la zona delle ZD in vSphere e nella specifica vsphereFailuredomain. Ad esempio:

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

Applicare le modifiche.
Eliminare gli oggetti csinode e csiNodeTopology in modo che vengano ricreati. csinodetopology non viene aggiornato automaticamente:
```
kubectl -n delete csinode --all --context wl-admin@wl
kubectl -n delete csinodetopology --all --context wl-admin@wl
```
Eliminare il programma di installazione del pacchetto vsphere-csi del cluster e attendere Reconcile succeeded.
```
kubectl delete pkgi -n tkg-system wl-vsphere-csi --context wl-admin@wl
```

Verificare che tutti gli oggetti csinodes includano il parametro topologyKeys, ad esempio:

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"]}]}

Verificare che le etichette di topologia di tutti i nodi riflettano le regioni e le zone ZD corrette, ad esempio:

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

Elenca zone di disponibilità

Utilizzare il comando tanzu mc az list per elencare le ZD definite nel cluster di gestione autonomo o utilizzate da un cluster del carico di lavoro:

Per elencare le zone di disponibilità attualmente utilizzate da un cluster di gestione e dai relativi cluster del carico di lavoro:
```
tanzu management-cluster available-zone list
```
Per elencare tutte le zone di disponibilità definite nel cluster di gestione e quindi disponibili per i nodi del cluster del carico di lavoro:
```
tanzu management-cluster available-zone list -a
```
Alle zone di disponibilità attualmente utilizzate dal cluster del carico di lavoro CLUSTER-NAME:
```
tanzu management-cluster available-zone list -c CLUSTER-NAME:
```

tanzu mc az i comandi vengono visualizzati con alias da tanzu management-cluster available-zone.

Output di esempio:

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

L'output elenca:

AZNAME, ZONENAME: Nome della ZD
ZONETYPE: Il tipo di oggetto vSphere ha come ambito ZD, ComputeCluster o HostGroup
REGIONNAME: Nome della regione che contiene la ZD
REGIONTYPE: L'ambito del tipo di oggetto vSphere è Datacenter o ComputeCluster
DATASTORE: Datastore che ospita le macchine virtuali nella regione
NETWORK: Rete delle macchine virtuali nella regione
OWNERCLUSTER: Cluster TKG o cluster eseguiti nella ZD
STATUS: Stato attuale della zona di disponibilità

Il gruppo di comandi tanzu mc az viene sottoposto ad aliasing da tanzu management-cluster available-zone.

Eliminazione di zone di disponibilità

Utilizzare il comando tanzu mc az delete per eliminare una ZD inutilizzata, ad esempio:

tanzu mc az delete AZNAME

Dove AZNAME è il nome della ZD come indicato da tanzu mc az list.

È possibile eliminare una ZD solo se al momento non ospita nodi del cluster TKG, come mostrato da tanzu mc az list che non include OWNERCLUSTER per la ZD.

Esecuzione di cluster in più zone di disponibilità

Panoramica

Definizione delle ZD

Configurazione dei cluster per l'utilizzo delle ZD

Prerequisiti

Distribuzione dei cluster del carico di lavoro in più ZD

Preparazione di regioni e ZD in vSphere

Creazione di oggetti FailureDomain e DeploymentZone in Kubernetes

Distribuzione del cluster

Aggiornamento dei cluster esistenti per l'utilizzo di più zone di disponibilità o di zone di disponibilità diverse

Aggiunta di ZD per i nodi del piano di controllo

Utilizzo delle etichette del selettore per specificare le nuove ZD del piano di controllo

Modifica delle ZD di distribuzione delle macchine

Aggiunta di ZD per le distribuzioni di macchine

Aggiunta di ZD e nuove distribuzioni di macchine

Aggiornamento di CPI e CSI per le modifiche delle ZD

Aggiornamento di CPI dopo la modifica delle ZD

Aggiornamento di CSI dopo la modifica delle ZD

Elenca zone di disponibilità

Eliminazione di zone di disponibilità

Creazione di oggetti `FailureDomain` e `DeploymentZone` in Kubernetes