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.
HinweisDieses 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.
In TKG auf vSphere können Sie optional Regionen und AZs in Kubernetes für das Hosten eigenständiger Verwaltungscluster und deren Arbeitslastcluster definieren und diese dann in vSphere kennzeichnen, um sie vSphere Clustern, Hostgruppen oder Datencentern zuzuordnen.
Mit diesem Setup unterstützt TKG die Verteilung und Redundanz von Arbeitslasten auf vSphere ähnlich wie bei Regionen und AZs in anderen Infrastrukturen.
Ohne diese Konstrukte können Sie TKG-Cluster auf der vSphere-Ebene platzieren, indem Sie vSphere Objekte direkt referenzieren, aber dann können TKG und Kubernetes ihre Platzierung nicht verwalten.
Um AZs in TKG auf vSphere zu definieren, erstellen Sie Kubernetes-Objekte und verknüpfen sie mit vSphere Objekten, je nachdem, wie der Geltungsbereich der AZs festgelegt ist:
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):
VSphereFailureDomain
-CRD erfasst die regions-/zonenspezifischen Tagging-Informationen und die Topologiedefinition, die die Informationen zum vSphere-Datencenter, -Cluster, -Host und -Datenspeicher enthält.VSphereDeploymentZone
-CRD erfasst die Zuordnung einer VSphereFailureDomain
mit Informationen zur Platzierungseinschränkung für den Kubernetes-Knoten.Um diese Objekte zu erstellen, definieren Sie sie in einer Objektspezifikation, z. B. in einer Datei vsphere-zones.yaml
, die Sie dann wie folgt verwenden können, um die Objekte zu unterschiedlichen Zeiten zu erstellen:
--az-file
von tanzu mc create
.
SKIP_MULTI_AZ_VERIFY=true
als env-Variable fest, um die vSphere-Validierung zu überspringen, wie in Validierungsprüfungen (Validation Checks) unter Ausführen des Befehls tanzu mc create
beschrieben, da für diese zusätzlichen AZs möglicherweise noch nicht alle vSphere Konfigurationen vorhanden sind.-f
des Befehls tanzu mc az set
oder kubectl apply
.--az-file
von tanzu cluster create
.Führen Sie folgenden Befehl aus, um AZ-Objekte aufzulisten, die bereits erstellt wurden:
kubectl get VSphereFailureDomain,VSphereDeploymentZone -a
Zuordnung von Kubernetes zu vSphere: Die Objektdefinitionen VSphereFailureDomain
und VSphereDeploymentZone
definieren Regionen und AZs mit den folgenden Einstellungen:
spec.region
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.
Wenn die Objekte VSphereFailureDomain
und VSphereDeploymentZone
für Verfügbarkeitszonen in Kubernetes definiert sind, können Sie konfigurieren, wie Cluster sie über Konfigurationsdateivariablen oder Cluster
-Objekteigenschaften verwenden.
Konfigurationsvariablen: Um Clusterkonfigurationsvariablen zu verwenden, legen Sie VSPHERE_AZ_0
, VSPHERE_AZ_1
, VSPHERE_AZ_2
, VSPHERE_AZ_CONTROL_PLANE_MATCHING_LABELS
, VSPHERE_REGION
und VSPHERE_ZONE
fest, wie unter vSphere in der Referenz für Konfigurationsdateivariablen beschrieben.
Objekteigenschaften: Für Cluster
-Objekteigenschaften konfiguriert die Objektspezifikation AZs für ihre Steuerungsebene und Worker-Knoten auf unterschiedliche Weise, um den verschiedenen Eigenschaften der VSphereDeploymentZone
-Objekte zu 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.
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:
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:
FailureDomain
- und DeploymentZone
-Objekten in KubernetesSo bereiten Sie vSphere zur Unterstützung von Regionen und AZs in TKG vor:
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:
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)…
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
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:
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 den Host in dieser Gruppe /dc1/host/room1-mgmt/esx-01a.corp.tanzu
usw. als AZ rack1
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
Identifizieren oder erstellen Sie die vSphere-Ressourcenpools und -Ordner, die zum Platzieren der VMs für jede der AZs verwendet werden sollen. In diesen Beispielen wird die govc
-CLI verwendet, Sie können jedoch auch den Fensterbereich Bestand (Inventory) in vCenter verwenden:
Cluster-AZs:
Verwenden Sie für jede Verfügbarkeitszone govc
, um resource-pool
-Objekte auf jedem vSphere Cluster zu erstellen, die mit jedem der 3 AZs- und 3 VM-Ordner übereinstimmen.
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
Hostgruppen-AZs:
Verwenden Sie für jede Verfügbarkeitszone govc
, um 3 resource-pool
-Objekte und 3 VM-Ordner zu erstellen.
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
FailureDomain
- und DeploymentZone
-Objekten in KubernetesBevor Sie einen Cluster in mehreren Verfügbarkeitszonen bereitstellen, müssen Sie die Kubernetes-Objekte FailureDomain
und DeploymentZone
für die Region und die Zonen definieren, wie oben unter Definieren von AZ (Defining AZs) beschrieben.
Jede Einstellung unter spec.region
, spec.zone
und spec.topology
muss mit den in vCenter konfigurierten Objektpfaden und Tags übereinstimmen:
VSphereDeploymentZone
-Objekte muss der Wert spec.failuredomain
mit einem der metadata.name
-Werte der VSphereFailureDomain
-Definitionen übereinstimmen.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 Objektdefinitionen FailureDomain
und DeploymentZone
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
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
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
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
Dabei ist VSPHERE_SERVER
die IP-Adresse oder der FQDN Ihres vCenter-Servers.
Nach dem Erstellen der Objektdefinitionen FailureDomain
und DeploymentZone
für Ihre AZs fahren Sie je nach dem Typ des bereitzustellenden Clusters fort:
Nachdem Sie die Schritte unter Vorbereiten von Regionen und AZs in vSphere und Erstellen von FailureDomain
- und DeploymentZone
-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 DeploymentZone
-Objektdefinitionen enthält.
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.
Überprüfen oder ändern Sie die Verfügbarkeitszonenvariablen in Ihrer Clusterkonfigurationsdatei, damit sie mit Ihren AZ-Objektdefinitionen übereinstimmen:
VSPHERE_REGION
und VSPHERE_ZONE
auf die Tag-Kategorien Region und Zone, k8s-region
und k8s-zone
.
VSPHERE_AZ_0
, VSPHERE_AZ_1
, VSPHERE_AZ_2
mit den Namen der VsphereDeploymentZone
-Objekte, in denen die Maschinen bereitgestellt werden müssen.
VSPHERE_AZ_0
verknüpfte VsphereDeploymentZone
ist die VSphereFailureDomain
, in der die Maschinenbereitstellung mit der Endung md-0
bereitgestellt wird, VSPHERE_AZ_1
ist die VSphereFailureDomain
, in der die Maschinenbereitstellung mit der Endung md-1
bereitgestellt wird, und VSPHERE_AZ_2
ist die VSphereFailureDomain
, in der die Maschinenbereitstellung mit der Endung md-2
bereitgestellt wirdVSphereFailureDomain
bereitgestellt.WORKER_MACHINE_COUNT
legt die Gesamtzahl der Worker für den Cluster fest. Die Gesamtzahl der Worker wird im Round-Robin-Verfahren auf die Anzahl der angegebenen AZs verteilt.VSPHERE_AZ_CONTROL_PLANE_MATCHING_LABELS
werden Schlüssel/Wert-Auswahlbezeichnungen für die Verfügbarkeitszonen festgelegt, in denen Clusterknoten auf Steuerungsebene bereitgestellt werden können.
VSPHERE_REGION
und VSPHERE_ZONE
festgelegt sind.VSphereDeploymentZone
-Ressourcen vorhanden sein."region=us-west-1,environment=staging"
.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.
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 cluster 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.
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.
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:
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
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
Dabei ist VSPHERE_SERVER
die IP-Adresse oder der FQDN Ihres vCenter-Servers.
Hinweise:
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.VSphereFailureDomain
-Objekte werden spec.region.autoConfigure
und spec.zone.autoConfigure
nicht mehr unterstützt.Erstellen Sie die Objekte vSphereFailureDomain
und VSphereDeploymentZone
. Beispiel:
tanzu mc az set -f vsphere-3-zones.yaml
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
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
Ü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'
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')\"}}"
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'
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:
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
Erstellen Sie die Objekte VSphereFailureDomain
und VSphereDeploymentZone
. Beispiel:
tanzu mc az set -f vsphere-labeled-zones.yaml
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
Ü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'
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')\"}}"
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'
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:
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'
Listen Sie alle verfügbaren Verfügbarkeitszonen auf.
kubectl get vspheredeploymentzones -o=jsonpath='{range .items[?(@.status.ready == true)]}{.metadata.name}{"\n"}{end}'
rack1
rack2
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
Ü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
Vergewissern Sie sich, dass die Worker-Knoten jetzt in VSphereFailureDomain
rack2
bereitgestellt sind.
So können Sie neue Verfügbarkeitszonen für TKG-Cluster konfigurieren und dann in einem vorhandenen Cluster verwenden:
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.
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.
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"}]'
Ü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}'
Vergewissern Sie sich, dass die zugehörigen Worker-Knoten jetzt in VSphereFailureDomain
rack1
, rack2
und rack3
bereitgestellt sind.
So können Sie neue Verfügbarkeitszonen und neue MachineDeployment
-Objekte für TKG-Cluster konfigurieren und dann in einem vorhandenen Cluster verwenden:
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
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.
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
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
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
Ü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
Vergewissern Sie sich, dass der Worker-Knoten von md-1
in rack2
bereitgestellt ist.
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:
tagCategory
-Einstellungen in verschiedenen Regionen und Zonen in VsphereFailureDomain
müssen übereinstimmen.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:
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'
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
Übernehmen Sie die Änderungen und warten Sie, bis der Status Reconcile succeeded
angezeigt wird.
Vergewissern Sie sich, dass das CPI-Paketinstallationsprogramm (pkgi
) neu installiert wurde:
kubectl -n tkg-system get wl-vsphere-cpi pkgi --context wl-admin@wl
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:
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')
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
Übernehmen Sie die Änderungen.
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
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
Ü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"]}]}
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
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ügbarkeitszoneZONETYPE
: Der vSphere-Objekttyp, der auf die Verfügbarkeitszone, ComputeCluster
oder HostGroup
, skaliert istREGIONNAME
: Der Name der Region, die die Verfügbarkeitszone enthältREGIONTYPE
: Der vSphere-Objekttyp, der auf die Region, Datacenter
oder ComputeCluster
, skaliert istDATASTORE
: Der Datenspeicher, der VMs in der Region hostenNETWORK
: Das Netzwerk, das VMs in der Region bedientOWNERCLUSTER
: TKG-Cluster oder Cluster, die im Verfügbarkeitsbereich ausgeführt werdenSTATUS
: Aktueller Status der VerfügbarkeitszoneDie tanzu mc az
-Befehlsgruppe ist ein Alias von tanzu management-cluster available-zone
.
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.