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

 

Ausführen von Clustern über mehrere Verfügbarkeitszonen hinweg

In diesem Thema wird beschrieben, wie Sie neue Tanzu Kubernetes Grid (TKG)-Arbeitslastcluster bereitstellen, die in mehreren Verfügbarkeitszonen (Availability Zones, AZs) ausgeführt werden, und wie Sie vorhandene Verwaltungs- und Arbeitslastcluster für die Ausführung in mehreren oder unterschiedlichen Verfügbarkeitszonen ändern.

Informationen zur Verwendung der Installationsprogramm-Schnittstelle zum Konfigurieren eines neuen eigenständigen Verwaltungsclusters, der in mehreren Verfügbarkeitszonen ausgeführt wird, finden Sie im Abschnitt Konfigurieren von vSphere-Ressourcen unter Bereitstellen von Verwaltungsclustern mithilfe der Schnittstelle des Installationsprogramms.

Hinweis

Dieses Thema gilt für TKG mit einem eigenständigen Verwaltungscluster. Informationen zum Ausführen von TKG mit einem Supervisor über Verfügbarkeitszonen hinweg finden Sie unter Erstellen von vSphere-Zonen für eine Supervisor-Bereitstellung mit mehreren Zonen in der Dokumentation zu vSphere 8.0.

Überblick

Kubernetes-Objekte: Zum Aktivieren mehrerer Verfügbarkeitszonen für Cluster auf vSphere verwendet Cluster API Provider vSphere (CAPV) zwei benutzerdefinierte Ressourcendefinitionen (Custom Resource Definitions, CRD):

  • Die VSphereFailureDomain-CRD erfasst die regions-/zonenspezifischen Tagging-Informationen und die Topologiedefinition, die die Informationen zum vSphere-Datencenter, -Cluster, -Host und -Datenspeicher enthält.
  • Die VSphereDeploymentZone-CRD erfasst die Zuordnung einer VSphereFailureDomain mit Informationen zur Platzierungseinschränkung für den Kubernetes-Knoten.

Zuordnung von Kubernetes zu vSphere: Die Objektdefinitionen VSphereFailureDomain und VSphereDeploymentZone definieren Regionen und AZs mit den folgenden Einstellungen:

  • Region: spec.region
  • Zone/AZ: spec.zone

Die vSphere-Tags k8s-region und k8s-zone ordnen Regionen und AZs in Kubernetes den ihnen zugrunde liegenden Objekten in vSphere zu.

AZ-Bereich: Sie können AZs und Regionen auf verschiedenen Ebenen in vSphere festlegen, indem Sie sie wie folgt vSphere-Objekten zuordnen:

AZ-Bereich Zone/AZ Region Verwendung mehrerer Verfügbarkeitszonen
Cluster-AZs vSphere-Cluster vSphere-Datencenter Verteilen von Knoten auf mehrere Cluster in einem Datencenter
Hostgruppen-AZs vSphere-Hostgruppe vSphere-Cluster Verteilen von Knoten auf mehrere Hosts in einem einzelnen Cluster

Die Konfigurationen in diesem Thema verteilen die Steuerungsebene des TKG-Clusters und die Worker-Knoten über vSphere-Objekte, d. h. vSphere-Datencenter, ‑Cluster und ‑Hosts, basierend darauf, wie die Objekte in vSphere getaggt sind und in den Definitionen VSphereFailureDomain und VSphereDeploymentZone in Kubernetes referenziert werden.

Cluster-Objektkonfiguration: Das Cluster-Objekt konfiguriert AZs für ihre Steuerungsebene und Worker-Knoten auf unterschiedliche Weise, die verschiedenen Eigenschaften der VSphereDeploymentZone-Objekte entsprechen, die die AZs definieren:

Knotentyp Eigenschaft unter spec.topology Um VSphereDeploymentZone-Eigenschaften zu entsprechen Beispiel
Knoten der Steuerungsebene variables.controlPlaneZoneMatchingLabels Liste von metadata.labels-Paaren {"environment": "staging", "region": "room1"}
Worker-Knoten machineDeployments.MD-INDEX.failureDomain für jede Maschinenbereitstellung Liste der metadata.name-Werte [rack1,rack2,rack3]

Da Knoten der Steuerungsebene AZs basierend auf dem Bezeichnungsabgleich zugewiesen werden, müssen Sie eine Bezeichnung erstellen, die jede Kombination von AZs unterscheidet, die Knoten von Cluster-Steuerungsebenen verwenden könnten.

Voraussetzungen

Die folgenden Voraussetzungen müssen erfüllt sein, um TKG-Cluster für die Ausführung in mehreren oder unterschiedlichen Verfügbarkeitszonen bereitstellen oder ändern zu können:

  • Ein Tanzu Kubernetes Grid-Verwaltungscluster mit Arbeitslastclustern, die auf vSphere ausgeführt werden.
  • Die folgende Berechtigung muss dem für TKG eingerichteten vSphere-Konto (wie unter Erforderliche Berechtigungen für das vSphere-Konto beschrieben) hinzugefügt werden:
    • Host > Bestandsliste (Inventory) > Cluster ändern (Modify cluster)

Bereitstellen von Arbeitslastclustern in mehreren Verfügbarkeitszonen

Sie können einen Arbeitslastcluster in drei grundlegenden Schritten bereitstellen, um seine Steuerungsebene oder Worker-Knoten in mehreren Verfügbarkeitszonen (AZs) auszuführen, wie in den folgenden Abschnitten beschrieben:

  1. Vorbereiten von Regionen und AZs in vSphere
  2. Erstellen von FailureDomain- und Deployment Zone-Objekten in Kubernetes
  3. Bereitstellen des Clusters

Vorbereiten von Regionen und AZs in vSphere

So bereiten Sie vSphere zur Unterstützung von Regionen und AZs in TKG vor:

  1. Identifizieren oder erstellen Sie die vSphere Objekte für die Regionen und AZs, in denen Ihre TKG-Clusterknoten gehostet werden.

    • Hostgruppen-AZs: Wenn Sie vSphere-Hostgruppen als Verfügbarkeitszonen verwenden, müssen Sie eine Hostgruppe und eine entsprechende VM-Gruppe für jede Verfügbarkeitszone erstellen, die Sie verwenden möchten:

      1. Erstellen Sie Hostgruppen- und VM-Gruppenobjekte mithilfe einer der folgenden Methoden:

        • Erstellen Sie in vCenter Host- und VM-Gruppen über Konfigurieren (Configure) > VM-/Hostgruppen (VM/Host Groups) > Hinzufügen (Add)…

          • Zum Erstellen einer Hostgruppe müssen Sie möglicherweise eine Dummy-VM erstellen, um sie als Gruppenmitglied hinzuzufügen.

        • Führen Sie mit govc CLI govc-Befehle wie die folgenden aus. Um beispielsweise eine Hostgruppe rack1 und eine VM-Gruppe rack1-vm-group zu erstellen:

          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. Fügen Sie Affinitätsregeln zwischen den erstellten VM- und Hostgruppen hinzu, sodass die VMs in der VM-Gruppe auf den Hosts in der erstellten Hostgruppe ausgeführt werden müssen:

        • Setzen Sie Typ (Type) auf Virtuelle Maschinen auf Hosts (Virtual Machines to Hosts) und schließen Sie die Regel Muss auf Hosts in Gruppe ausgeführt werden (Must run on hosts in group) ein.

  2. Taggen Sie die vSphere-Objekte wie folgt, je nachdem, ob Sie vSphere-Cluster-AZs oder Host-Gruppen-AZs konfigurieren. In diesen Beispielen wird die govc-CLI verwendet, Sie können jedoch auch den Fensterbereich Tags und benutzerdefinierte Attribute (Tags & Custom Attributes) in vCenter verwenden:

    • Cluster-AZs:

      Verwenden Sie govc, um für jede AZ ein Kategorie-Tag der Kategorie k8s-region zu erstellen und dem Datencenter zuzuordnen, und ein Kategorie-Tag der Kategorie k8s-zone für jeden vSphere-Cluster. Um zum Beispiel das Datencenter dc0 als Region us-west-1 und seine Cluster cluster1 usw. als AZs us-west-1a usw. zu kennzeichnen:

      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

    • Hostgruppen-AZs:

      Verwenden Sie govc, um für jede AZ ein Kategorie-Tag der Kategorie k8s-region zu erstellen und dem vSphere-Cluster zuzuordnen, und ein Kategorie-Tag der Kategorie k8s-zone für jede Hostgruppe. Um zum Beispiel den Cluster /dc1/host/room1-mgmt als Region room1 und seine Hostgruppe /dc1/host/room1-mgmt/esx-01a.corp.tanzu usw. als AZs rack1 usw. zu kennzeichnen:

      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

Erstellen von FailureDomain- und Deployment Zone-Objekten in Kubernetes

Bevor Sie einen Cluster in mehreren Verfügbarkeitszonen bereitstellen, müssen Sie die Kubernetes-Objekte FailureDomain und Deployment Zone, die die Region und die Zonen definieren, erstellen. Jede Einstellung unter spec.region, spec.zone und spec.topology muss mit den in vCenter konfigurierten Objektpfaden und Tags übereinstimmen:

  • Für VSphereDeploymentZone-Objekte muss der Wert spec.failuredomain mit einem der metadata.name-Werte der VSphereFailureDomain-Definitionen übereinstimmen.
  • Der Wert spec.server in den VSphereDeploymentZone-Objekten muss mit der vCenter-Serveradresse (IP oder FQDN) übereinstimmen, die für VCENTER SERVER im Fensterbereich IaaS-Anbieter der Installationsprogramm-Schnittstelle oder der VSPHERE_SERVER-Einstellung in der Konfigurationsdatei des Verwaltungsclusters eingegeben wurde.
  • metadata.name-Werte dürfen nur Kleinbuchstaben enthalten.

Erstellen Sie die Objekte FailureDomain und Deployment Zone wie folgt, je nachdem, ob Sie vSphere Cluster-AZs oder Hostgruppen-AZs konfigurieren.

  • Cluster-AZs:

    Als Beispiel für die Verteilung von Arbeitslastclustern auf mehrere vSphere-Clusterknoten innerhalb eines Datencenters definiert der folgende Code die Objekte, die für drei Bereitstellungszonen mit dem Namen us-west-1a, us-west-1b und us-west-1c benötigt werden, wobei es sich jeweils um einen vSphere-Cluster mit eigenen Netzwerk- und Speicherparametern handelt:

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

    Dabei ist VSPHERE_SERVER die IP-Adresse oder der FQDN Ihres vCenter-Servers.

    Wenn verschiedene vSphere-Cluster über Ressourcenpools mit identischem Namen verfügen, legen Sie spec.placementConstraint.resourcePool der VSphereDeploymentZone-Objekte auf einen vollständigen Ressourcenpfad und nicht nur auf den Namen fest.

  • Hostgruppen-AZs:

    Als Beispiel für die Verteilung von Arbeitslastcluster-Knoten auf drei Hostgruppen in einem einzelnen vSphere-Cluster definiert der folgende Code die Objekte, die für drei AZs, rack1, rack2 und rack3, benötigt werden, von denen jedes ein Rack mit Hosts innerhalb desselben vSphere-Clusters darstellt, das als Region room1 definiert ist

      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

    Dabei ist VSPHERE_SERVER die IP-Adresse oder der FQDN Ihres vCenter-Servers.

Die nächsten Schritte zumBereitstellen eines Arbeitslastclusters mit auf Verfügbarkeitsbereiche verteilten Knoten.

Bereitstellen des Clusters

Nachdem Sie die Schritte unter Vorbereiten von Regionen und AZs in vSphere und Erstellen von FailureDomain- und Deployment Zone-Objekten in Kubernetes ausgeführt haben, können Sie einen Arbeitslastcluster bereitstellen, dessen Knoten über mehrere AZs verteilt sind.

In den folgenden Schritten wird vsphere-zones.yaml als Datei verwendet, die FailureDomain- und Deployment Zone-Objektdefinitionen enthält.

  1. Befolgen Sie die Anweisungen unter vSphere mit Konfigurationsdateien für eigenständige Verwaltungscluster, um die Clusterkonfigurationsdatei für den von Ihnen bereitgestellten Arbeitslastcluster zu erstellen.

  2. Überprüfen oder ändern Sie Ihre Clusterkonfigurationsdatei, indem Sie den Anweisungen unter Mehrere Verfügbarkeitszonen konfigurieren folgen, um VSPHERE_REGION, VSPHERE_ZONE, VSPHERE_AZ_0 und andere Konfigurationsvariablen so einzustellen, dass sie mit Ihren AZ-Objektdefinitionen übereinstimmen.

    • Cluster-Konfigurationsvariablen für AZs funktionieren für eigenständige Verwaltungscluster und Arbeitslastcluster gleichermaßen.
    • Eine vollständige Liste der Optionen, die Sie bei der Bereitstellung von Arbeitslastclustern unter vSphere angeben müssen, finden Sie in der Referenz für die Variablen der Konfigurationsdatei.

  3. (Optional) Legen Sie in Ihrer lokalen Umgebung SKIP_MULTI_AZ_VERIFY auf "true" fest, um zu verhindern, dass der Clustererstellungsprozess überprüft, ob alle in der Konfiguration angegebenen vSphere-Zonen und -Regionen vorhanden sind, konsistent sind und auf derselben Ebene definiert sind:

    export SKIP_MULTI_AZ_VERIFY="true"

    Sie können diese Variable nicht in der Clusterkonfigurationsdatei festlegen.

  4. Führen Sie tanzu cluster create aus, um den Arbeitslastcluster zu erstellen. Weitere Informationen finden Sie unter Erstellen von Arbeitslastclustern.

    • Um die AZ-Objekte getrennt vom Cluster zu erstellen, melden Sie sich beim Verwaltungscluster mit tanzu login an und führen Sie Folgendes vor tanzu cluster create aus:

      tanzu mc az set -f vsphere-zones.yaml

      Alternativ können Sie kubectl apply -f vsphere-zones.yaml ausführen.

    • Zur Verwendung der AZ-Objektdefinitionen mit einer flachen Clusterkonfigurationsdatei und gemeinsamen Erstellung von AZ- und Clusterobjekten übergeben Sie die Datei vsphere-zones.yaml an die Option --az-file von tanzu cluster create:

      tanzu mc create --file cluster-config-file.yaml --az-file vsphere-zones.yaml

    • Zum Kombinieren der AZ-Objektdefinitionen in einem Clustermanifest erstellen Sie das Clustermanifest, indem Sie Schritt 1 des zweistufigen Prozesses ausführen, der unter Erstellen eines klassenbasierten Clusters beschrieben ist. Hängen Sie den Inhalt von vsphere-zones.yaml an das Manifest an und führen Sie dann tanzu cluster create aus (siehe Beschreibung in Schritt 2).

    • Während des Clustererstellungsvorgangs werden die zugehörigen VMs und andere Ressourcen in vCenter angezeigt.

    • Wenn Sie eine Dummy-VM in vCenter erstellt haben, um eine VM-Gruppe zu erstellen, können Sie die VM löschen oder aus den VM-Gruppen entfernen, sobald der Cluster ausgeführt wird.

Aktualisieren vorhandener Cluster zur Verwendung mehrerer oder unterschiedlicher Verfügbarkeitszonen

Sie können einen bereits bereitgestellten Verwaltungs- oder Arbeitslastcluster so aktualisieren, dass seine Steuerungsebenen- oder Worker-Knoten in mehreren Verfügbarkeitszonen ausgeführt werden oder die Verfügbarkeitszonen geändert werden, in denen die Knoten ausgeführt werden.

Sie können den Steuerungsebenen- oder Worker-Knoten eines Clusters als Ganzes Verfügbarkeitszonen zuweisen oder Verfügbarkeitszonen für zugrunde liegende Maschinenbereitstellungen festlegen, um die vSphere-Maschineneinstellungen zusammen mit den Verfügbarkeitszonen für die festgelegte Maschinenbereitstellung anzupassen.

Nachdem Sie die Verfügbarkeitszonen eines vorhandenen Arbeitslastclusters aktualisiert haben, müssen Sie die zugehörige Container-Speicherschnittstelle (Container Storage Interface, CSI) und die Cloud-Anbieterschnittstelle (Cloud Provider Interface, CPI) aktualisieren, um die Änderung widerzuspiegeln. Die entsprechende Vorgehensweise wird unter Aktualisieren der CPI und CSI bei AZ-Änderungen beschrieben.

In den folgenden Abschnitten wird erläutert, wie Sie vorhandene AZ-Konfigurationen von Clustern in verschiedenen Szenarien aktualisieren.

Hinzufügen von Verfügbarkeitszonen für Steuerungsebenenknoten

So erweitern Sie einen vorhandenen Cluster, dessen Steuerungsebenenknoten in einer einzigen Verfügbarkeitszone ausgeführt werden, damit die zugehörige Steuerungsebene in mehreren Verfügbarkeitszonen ausgeführt wird:

  1. Bereiten Sie eine Konfigurationsdatei vor, die ein VSphereFailureDomain-Objekt und ein VSphereDeploymentZone-Objekt für jede neue Verfügbarkeitszone definiert. Im folgenden Beispiel werden in der Datei vsphere-3-zones.yaml die Verfügbarkeitszonen rack1, rack2 und rack3 mit der Region room1 definiert:

    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

    Dabei ist VSPHERE_SERVER die IP-Adresse oder der FQDN Ihres vCenter-Servers.

    Hinweise:

    • Stellen Sie sicher, dass die Tags erstellt wurden und dass die Ressourcen in der vCenter Server-Bestandsliste ordnungsgemäß gekennzeichnet wurden, wie unter vSphere-Tags in der vSphere-Produktdokumentation beschrieben.
    • Sie müssen spec.placementConstraint.resourcePool in VSphereDeploymentZone festlegen. Wenn kein vom Benutzer erstellter Ressourcenpool für den Cluster vorhanden ist, legen Sie den Wert auf den Standardressourcenpool des Clusters fest, dessen Pfad /dc0/host/cluster1/Resources lautet.
    • Für VSphereFailureDomain-Objekte werden spec.region.autoConfigure und spec.zone.autoConfigure nicht mehr unterstützt.

  2. Erstellen Sie die Objekte vSphereFailureDomain und VSphereDeploymentZone. Beispiel:

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

  3. Rufen Sie das KubeAdmControlPlane-Objekt des Zielclusters ab. In unserem Beispiel ist das Ziel der Verwaltungscluster tkg-mgmt-vc, das Ziel kann aber auch ein Arbeitslastcluster sein:

    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. Aktualisieren Sie die AZ-Auswahl des Clusters, z. B. 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. Überprüfen Sie, ob die Fehlerdomäne des Clusters wie erwartet aktualisiert wurde:

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

  6. Patchen Sie die Ressource KubeAdmControlPlane mit rolloutAfter, um eine Aktualisierung der Steuerungsebenenknoten auszulösen.

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

  7. Stellen Sie sicher, dass die Steuerungsebenenknoten in die neuen Verfügbarkeitszonen verschoben wurden, indem Sie den Host und den Datenspeicher der Knoten in der vCenter-Instanz überprüfen oder den Befehl kubectl get node oder govc vm.info wie folgt ausführen:

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

Verwenden von Auswahlbezeichnungen zum Angeben neuer Verfügbarkeitszonen für die Steuerungsebene

Wenn Sie Verfügbarkeitszonen mit Auswahlbezeichnungen auswählen, geben Sie das VSphereDeploymentZone-Objekt anhand der metadata.labels und nicht anhand des metadata.name-Werts an. Dadurch können Sie beispielsweise die Steuerungsebenenknoten eines Clusters für die Ausführung in allen Verfügbarkeitszonen in einer angegebenen Region und Umgebung konfigurieren, ohne die Verfügbarkeitszonen einzeln auflisten zu müssen: "region=us-west-1,environment=staging". Dies bedeutet auch, dass Sie die Verfügbarkeitszonen der Steuerungsebene eines Clusters aktualisieren können, ohne die Namen der Verfügbarkeitszonen für die Steuerungsebenenknoten ändern zu müssen.

So verwenden Sie Auswahlbezeichnungen zum Angeben neuer Verfügbarkeitszonen für die Steuerungsebenenknoten eines vorhandenen Clusters:

  1. Bereiten Sie eine Konfigurationsdatei vor, die ein VSphereFailureDomain-Objekt und ein VSphereDeploymentZone-Objekt für jede neue Verfügbarkeitszone definiert. Im folgenden Beispiel wird in der Datei vsphere-labeled-zones.yaml die Verfügbarkeitszone rack4 mit Metadaten von Auswahlbezeichnungen definiert:

    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. Erstellen Sie die Objekte VSphereFailureDomain und VSphereDeploymentZone. Beispiel:

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

  3. Aktualisieren Sie den Cluster mit der AZ-Auswahlbezeichnung. Im folgenden Beispiel wird eine AZ-Auswahl vom Typ controlPlaneZoneMatchingLabels: {"environment": "staging", "region": "room1"} für den Verwaltungscluster tkg-mgmt-vc verwendet, Sie können aber auch einen Arbeitslastcluster verwenden:

    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. Überprüfen Sie den Clusterstatus, um sicherzustellen, dass die Fehlerdomäne wie erwartet aktualisiert wurde:

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

  5. Patchen Sie die Ressource KubeAdmControlPlane mit rolloutAfter, um eine Aktualisierung der Steuerungsebenenknoten auszulösen.

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

  6. Stellen Sie sicher, dass die Steuerungsebenenknoten in die neuen, anhand der Auswahl in controlPlaneZoneMatchingLabels ausgewählten Verfügbarkeitszonen verschoben wurden, indem Sie den Host und den Datenspeicher der Knoten in der vCenter-Instanz überprüfen oder den Befehl kubectl get node oder govc vm.info wie folgt ausführen. In unserem Beispiel heißt die neue Verfügbarkeitszone 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'

Ändern der Verfügbarkeitszonen für Maschinenbereitstellungen

Wenn Sie eine AZ-Konfiguration in einem vorhandenen Cluster ändern möchten, müssen Sie die zugrunde liegenden MachineDeployment-Konfigurationen der Knoten mit dem neuen AZ-Wert patchen.

Beispiel: Wenn in der Clusterkonfigurationsdatei die Variable VSPHERE_AZ_0 auf rack1 festgelegt wurde und Sie die zugehörigen Worker-Knoten in rack2 verschieben möchten, gehen Sie wie folgt vor:

  1. Fragen Sie die aktuell für den Cluster verwendeten Verfügbarkeitszonen ab. Im folgenden Beispiel wird ein Arbeitslastcluster namens tkg-wc verwendet, Sie können aber auch einen Verwaltungscluster verwenden:

    kubectl get cluster tkg-wc -o json \| jq -r '.spec.topology.workers.machineDeployments\[0\].failureDomain'

  2. Listen Sie alle verfügbaren Verfügbarkeitszonen auf.

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

rack1
rack2

  3. Patchen Sie für den Cluster tkg-wc die Konfiguration von spec.toplogy.workers.machineDeployments, um die Zone VSphereFailureDomain auf rack2 festzulegen. In diesem Beispiel wird davon ausgegangen, dass tkg-wc ein dev-Plancluster mit einem Einzelknoten ist. Bei einem prod-Plancluster müssten Sie alle drei MachineDeployment-Objektkonfigurationen im Cluster patchen.

    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. Überprüfen Sie, ob der Cluster so aktualisiert wurde, dass VSphereFailureDomain auf rack2 festgelegt ist.

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

rack2

  5. Vergewissern Sie sich, dass die Worker-Knoten jetzt in VSphereFailureDomain rack2 bereitgestellt sind.

Hinzufügen von Verfügbarkeitszonen für Maschinenbereitstellungen

So können Sie neue Verfügbarkeitszonen für TKG-Cluster konfigurieren und dann in einem vorhandenen Cluster verwenden:

  1. Bereiten Sie eine Konfigurationsdatei vor, die ein VSphereFailureDomain-Objekt und ein VSphereDeploymentZone-Objekt für jede neue Verfügbarkeitszone definiert. Verwenden Sie die obige Beispieldatei vsphere-3-zones.yaml im Abschnitt Hinzufügen von Verfügbarkeitszonen für Steuerungsebenenknoten, in der die Verfügbarkeitszonen rack1, rack2 und rack3 mit der Region room1 definiert wurden.

  2. Erstellen Sie die Objekte VSphereFailureDomain und VSphereDeploymentZone.

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

    Alternativ können Sie kubectl apply -f vsphere-3-zones.yaml ausführen.

  3. Patchen Sie den Cluster tkg-wc mit VSphereFailureDomain rack1, rack2 und rack3. Im folgenden Beispiel ist tkg-wc ein prod-Plancluster mit drei MachineDeployment-Konfigurationen. Bei einem dev-Plancluster müssen Sie nur ein MachineDeployment-Objekt in der spec.toplogy.workers.machineDeployments-Konfiguration des Clusters aktualisieren.

    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. Überprüfen Sie, ob der Cluster mit den neuen Verfügbarkeitszonen aktualisiert wurde.

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

  5. Vergewissern Sie sich, dass die zugehörigen Worker-Knoten jetzt in VSphereFailureDomain rack1, rack2 und rack3 bereitgestellt sind.

Hinzufügen von Verfügbarkeitszonen und neuen Maschinenbereitstellungen

So können Sie neue Verfügbarkeitszonen und neue MachineDeployment-Objekte für TKG-Cluster konfigurieren und dann in einem vorhandenen Cluster verwenden:

  1. Bereiten Sie eine Konfigurationsdatei vor, die ein VSphereFailureDomain-Objekt und ein VSphereDeploymentZone-Objekt für jede neue Verfügbarkeitszone definiert. Im folgenden Beispiel wird in der Datei vsphere-1-zone.yaml die neue Verfügbarkeitszone rack2 mit der Region room1 definiert:

    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. Erstellen Sie die Objekte VSphereFailureDomain und VSphereDeploymentZone.

    tanzu mc az set -f vsphere-zones.yaml

    Alternativ können Sie kubectl apply -f vsphere-1-zone.yaml ausführen.

  3. Bereiten Sie eine Konfigurationsdatei für die neue Maschinenbereitstellung vor. Im folgenden Beispiel wird in der Datei md-1.yaml die neue Maschinenbereitstellung md-1 definiert und deren Eigenschaft az auf rack2 festgelegt:

    name: md-1
replicas: 1
az: rack2
nodeMachineType: t3.large
workerClass: tkg-worker
tkrResolver: os-name=ubuntu,os-arch=amd64

  4. Erstellen Sie mithilfe der Tanzu CLI einen neuen Knotenpool. Im folgenden Beispiel wird der Arbeitslastcluster tkg-wc verwendet, Sie können aber auch einen Verwaltungscluster verwenden:

    tanzu cluster node-pool set wl-antrea -f md-1.yaml

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

  5. Rufen Sie den Namen der Maschinenbereitstellung im neu erstellten Knotenpool ab:

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

wl-antrea-md-1-pd9vj

  6. Überprüfen Sie, ob die Maschinenbereitstellung so aktualisiert wurde, dass VSphereFailureDomain auf rack2 festgelegt ist:

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

rack2

  7. Vergewissern Sie sich, dass der Worker-Knoten von md-1 in rack2 bereitgestellt ist.

Aktualisieren der CPI und CSI bei Änderungen der Verfügbarkeitszonen

Nachdem Sie die AZ-Konfiguration eines Arbeitslastclusters wie in einem der obigen Abschnitte beschrieben geändert haben, müssen Sie die CPI- und CSI-Add-On-Konfigurationen aktualisieren und dann die Add-Ons neu erstellen, um die Änderungen widerzuspiegeln. Im Folgenden wird erläutert, wie Sie dazu vorgehen müssen.

Beschränkungen:

  • Bevor Sie mehrere Verfügbarkeitszonen für einen vorhandenen Cluster aktivieren oder dessen Worker- oder Steuerungsebenenknoten in eine andere Verfügbarkeitszone für einen vorhandenen Cluster verschieben, müssen Sie sicherstellen, dass alle neuen Clusterknoten auf das ursprüngliche dauerhafte Volume (Persistent Volume, PV) des Clusters zugreifen können.
  • Alle tagCategory-Einstellungen in verschiedenen Regionen und Zonen in VsphereFailureDomain müssen übereinstimmen.
  • Bevor Sie mehrere Verfügbarkeitszonen für vSphere CSI aktivieren, müssen Sie „multi-az kcp/worker“ aktivieren.

Aktualisieren der CPI nach Änderungen der Verfügbarkeitszonen

So aktualisieren Sie die CPI-Add-On-Konfiguration eines Clusters, um eine AZ-Änderung widerzuspiegeln, und löschen dann das entsprechende Paketinstallationsprogramm, um das Add-On mit den Änderungen neu zu erstellen:

  1. Rufen Sie den Namen der vsphereCPIConfig des Clusters unter Verwendung des cb-Verweises ab. Beispielsweise mit einem Arbeitslastcluster mit dem Namen wl:

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

  2. Bearbeiten Sie die vsphereCPIConfig-Spezifikation des Clusters, indem Sie die region und die zone auf die tagCategory-Felder festlegen, die Sie in vSphere und in der Spezifikation von vsphereFailuredomain für die Region und die Zone der Verfügbarkeitszone festgelegt haben. Beispiel:

    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. Übernehmen Sie die Änderungen und warten Sie, bis der Status Reconcile succeeded angezeigt wird.

  4. Vergewissern Sie sich, dass das CPI-Paketinstallationsprogramm (pkgi) neu installiert wurde:

    kubectl -n tkg-system get wl-vsphere-cpi pkgi --context wl-admin@wl

Aktualisieren der CSI nach Änderungen der Verfügbarkeitszonen

So aktualisieren Sie die CSI-Add-On-Konfiguration eines Clusters, um eine Änderung der Verfügbarkeitszonen widerzuspiegeln, und löschen dann das Objekt csinodetopology und das entsprechende Paketinstallationsprogramm, um das Add-On mit den Änderungen neu zu erstellen:

  1. Rufen Sie den Namen der vsphereCPIConfig des Clusters unter Verwendung des cb-Verweises ab. Beispielsweise mit einem Arbeitslastcluster mit dem Namen wl:

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

  2. Bearbeiten Sie die vsphereCSIConfig-Spezifikation des Clusters, indem Sie die region und die zone auf die tagCategory-Felder festlegen, die Sie in vSphere und in der Spezifikation von vsphereFailuredomain für die Region und die Zone der Verfügbarkeitszone festgelegt haben. Beispiel:

    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. Übernehmen Sie die Änderungen.

  4. Löschen Sie die Objekte csinode und csiNodeTopology, damit sie neu erstellt werden. csinodetopology wird nicht automatisch aktualisiert:

    kubectl -n delete csinode --all --context wl-admin@wl
kubectl -n delete csinodetopology --all --context wl-admin@wl

  5. Löschen Sie das vsphere-csi-Paketinstallationsprogramm des Clusters und warten Sie, bis der Status Reconcile succeeded angezeigt wird.

    kubectl delete pkgi -n tkg-system wl-vsphere-csi --context wl-admin@wl

  6. Überprüfen Sie, ob alle csinodes-Objekte den Parameter topologyKeys enthalten. Beispiel:

    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. Vergewissern Sie sich, dass die Topologiebezeichnungen aller Knoten die richtigen AZ-Regionen und -Zonen widerspiegeln. Beispiel:

    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

Verfügbarkeitszonen auflisten

Verwenden Sie den Befehl tanzu mc az list, um die AZs aufzulisten, die im eigenständigen Verwaltungscluster definiert oder von einem Arbeitslastcluster verwendet werden:

  • So listen Sie Verfügbarkeitsbereiche auf, die derzeit von einem Verwaltungscluster und den zugehörigen Arbeitslastclustern verwendet werden:

    tanzu management-cluster available-zone list

  • So listen Sie alle Verfügbarkeitszonen auf, die im Verwaltungscluster definiert und daher für Arbeitslastcluster-Knoten verfügbar sind:

    tanzu management-cluster available-zone list -a

  • Zu den Verfügbarkeitszonen, die derzeit vom Arbeitslastcluster CLUSTER-NAME verwendet werden:

    tanzu management-cluster available-zone list -c CLUSTER-NAME:

tanzu mc az-Befehle sind Aliase von tanzu management-cluster available-zone.

Beispielausgabe:

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

Die Ausgabelisten:

  • AZNAME, ZONENAME: Der Name der Verfügbarkeitszone
  • ZONETYPE: Der vSphere-Objekttyp, der auf die Verfügbarkeitszone, ComputeCluster oder HostGroup, skaliert ist
  • REGIONNAME: Der Name der Region, die die Verfügbarkeitszone enthält
  • REGIONTYPE: Der vSphere-Objekttyp, der auf die Region, Datacenter oder ComputeCluster, skaliert ist
  • DATASTORE: Der Datenspeicher, der VMs in der Region hosten
  • NETWORK: Das Netzwerk, das VMs in der Region bedient
  • OWNERCLUSTER: TKG-Cluster oder Cluster, die im Verfügbarkeitsbereich ausgeführt werden
  • STATUS: Aktueller Status der Verfügbarkeitszone

Die tanzu mc az-Befehlsgruppe ist ein Alias von tanzu management-cluster available-zone.

Verfügbarkeitszonen löschen

Verwenden Sie den Befehl tanzu mc az delete, um eine nicht verwendete Verfügbarkeitszone zu löschen, z. B.:

tanzu mc az delete AZNAME

Wobei AZNAME der Name der Verfügbarkeitszone ist, wie er in tanzu mc az list aufgeführt ist.

Sie können eine Verfügbarkeitszone nur dann löschen, wenn sie derzeit keine TKG-Clusterknoten hostet, wie die Liste tanzu mc az list zeigt, die keinen OWNERCLUSTER für die Verfügbarkeitszone auflistet.

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