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

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.

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 dell'oggetto Cluster: La specifica dell'oggetto Cluster 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:

  1. Preparazione di regioni e ZD in vSphere
  2. Creazione degli oggetti FailureDomain e Deployment Zone in Kubernetes
  3. Distribuzione del cluster

Preparazione di regioni e ZD in vSphere

Per preparare vSphere per supportare regioni e ZD in TKG:

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

  2. 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 gruppo di host. Ad esempio, per contrassegnare il cluster /dc1/host/room1-mgmt come regione room1 e il relativo gruppo di host /dc1/host/room1-mgmt/esx-01a.corp.tanzu e così via come zona di disponibilità rack1 e così via:

      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

Creazione di oggetti FailureDomain e Deployment Zone in Kubernetes

Prima di distribuire un cluster in più zone di disponibilità, è necessario creare gli oggetti Kubernetes FailureDomain e Deployment Zone che definiscono la regione e le zone. 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 FailureDomain e gli oggetti Deployment Zone come indicato di seguito, a seconda che si stia configurando vSphere zone di disponibilità del cluster o dei gruppi di host.

  • 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
  spec:
   server: VSPHERE_SERVER
   failureDomain: us-west-1a
   placementConstraint:
     resourcePool: pool1
     folder: foo
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
   name: us-west-1b
  spec:
   server: VSPHERE_SERVER
   failureDomain: us-west-1b
   placementConstraint:
     resourcePool: pool2
     folder: bar
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
   name: us-west-1c
  spec:
   server: VSPHERE_SERVER
   failureDomain: us-west-1c
   placementConstraint:
     resourcePool: pool3
     folder: baz

    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
  spec:
   server: VSPHERE_SERVER
   failureDomain: rack1
   placementConstraint:
     resourcePool: pool1
     folder: foo
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
   name: rack2
  spec:
   server: VSPHERE_SERVER
   failureDomain: rack2
   placementConstraint:
     resourcePool: pool2
     folder: bar
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
   name: rack3
  spec:
   server: VSPHERE_SERVER
   failureDomain: rack3
   placementConstraint:
     resourcePool: pool3
   folder: baz

    In cui VSPHERE_SERVER è l'indirizzo IP o il nome di dominio completo (FQDN) di vCenter Server.

Per i passaggi successivi di distribuzione del cluster, vedere Diffusione di un cluster del carico di lavoro con nodi distribuiti nelle zone di disponibilità.

Distribuzione del cluster

Dopo aver eseguito i passaggi in Prepare regioni e ZD in vSphere e Create FailureDomain e Deployment Zone Oggetti 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 Deployment Zone.

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

  2. Controllare o modificare il file di configurazione del cluster seguendo Configurazione di più zone di disponibilità per impostare VSPHERE_REGION, VSPHERE_ZONE, VSPHERE_AZ_0 e altre variabili di configurazione in modo che corrispondano alle definizioni degli oggetti ZD.

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

  3. (Facoltativo) Per impedire al processo di creazione del cluster di verificare che le zone e le regioni vSphere specificate nella configurazione esistano tutte, siano coerenti e siano definite allo stesso livello, impostare SKIP_MULTI_AZ_VERIFY su "true" nell'ambiente locale:

    export SKIP_MULTI_AZ_VERIFY="true"

    Non è possibile impostare questa variabile nel file di configurazione del cluster.

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

  1. 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
spec:
 server: VSPHERE_SERVER
 failureDomain: rack1
 placementConstraint:
 resourcePool: rp0
 folder: folder0
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
 name: rack2
spec:
 server: VSPHERE_SERVER
 failureDomain: rack2
 placementConstraint:
 resourcePool: rp0
 folder: folder0
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
 name: rack3
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.

  2. Creare gli oggetti vSphereFailureDomain e VSphereDeploymentZone, ad esempio:

    tanzu mc az set -f vsphere-3-zones.yaml

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

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

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

  6. 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')\"}}"

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

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

  2. Creare gli oggetti VSphereFailureDomain e VSphereDeploymentZone, ad esempio:

    tanzu mc az set -f vsphere-labeled-zones.yaml

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

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

  5. 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')\"}}"

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

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

  2. Elencare tutte le ZD disponibili.

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

rack1
rack2

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

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

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

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

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

  3. 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"}]'

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

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

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

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

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

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

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

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

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

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

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

  3. Applicare le modifiche e attendere Reconcile succeeded.

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

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

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

  3. Applicare le modifiche.

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

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

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

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

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