In diesem Thema wird erläutert, wie Sie eine flache Konfigurationsdatei oder eine Objektspezifikation im Kubernetes-Stil verwenden, um einen Tanzu Kubernetes Grid (TKG)-Arbeitslastcluster zu konfigurieren, bevor Sie ihn auf Amazon Web Services (AWS) mit einem eigenständigen Verwaltungscluster bereitstellen.
Allgemeine Informationen zur Konfiguration von Arbeitslastclustern mithilfe von Konfigurationsdateien und Objektspezifikationen finden Sie unter Konfigurationsdateien und Objektspezifikationen.
Informationen zur Verwendung von AWS-spezifischen Arbeitslastclusterfunktionen, die eine Konfiguration außerhalb der Konfigurationsdatei oder der Objektspezifikation des Clusters erfordern, finden Sie unter Cluster auf AWS.
WichtigTanzu Kubernetes Grid v2.4.x ist die letzte Version von TKG, die die Erstellung von TKG-Arbeitslastclustern auf AWS unterstützt. Die Möglichkeit, TKG-Arbeitslastcluster auf AWS zu erstellen, wird in Tanzu Kubernetes Grid v2.5 entfernt.
Ab sofort empfiehlt VMware die Verwendung von Tanzu Mission Control zur Erstellung nativer AWS EKS-Cluster anstelle neuer TKG-Arbeitslastcluster auf AWS. Informationen zum Erstellen nativer AWS EKS-Cluster mit Tanzu Mission Control finden Sie unter Verwalten des Lebenszyklus von AWS EKS-Clustern in der Dokumentation zu Tanzu Mission Control.
Weitere Informationen finden Sie unter Veraltete TKG-Verwaltungs- und -Arbeitslastcluster in AWS und Azure in den Versionshinweisen zu VMware Tanzu Kubernetes Grid v2.4.
Um einen Arbeitslastcluster vor der Bereitstellung in AWS zu konfigurieren, erstellen Sie eine Clusterkonfigurationsdatei oder eine Objektspezifikationsdatei im Kubernetes-Stil. Wenn Sie eine dieser Dateien an die Option -f
von tanzu cluster create
übergeben, verwendet die Tanzu CLI die in der Datei definierten Konfigurationsinformationen, um eine Verbindung zu Ihrem AWS-Konto herzustellen und die vom Cluster verwendeten Ressourcen zu erstellen. Sie können beispielsweise auch die Größen für die VMs von Steuerungsebenen- und Worker-Knoten angeben, Knoten über Verfügbarkeitszonen verteilen und VPCs von mehreren Clustern gemeinsam nutzen lassen.
Eine vollständige Liste der Optionen, die Sie bei der Bereitstellung von Arbeitslastclustern in AWS angeben müssen, finden Sie in der Referenz für die Variablen der Konfigurationsdatei.
HinweisUm die Sicherheit in einer Umgebung mit mehreren Mandanten zu verbessern, stellen Sie die Arbeitslastcluster in einem AWS-Konto bereit, das sich von dem für die Bereitstellung des Verwaltungsclusters verwendeten Konto unterscheidet. Informationen zum Bereitstellen von Arbeitslastclustern für mehrere AWS-Konten finden Sie unter Cluster auf verschiedenen AWS-Konten.
Um eine Clusterkonfigurationsdatei zu erstellen, können Sie die Vorlage in Workload-Clustervorlage unten verwenden. Fahren Sie nach dem Erstellen der Konfigurationsdatei mit Erstellen von Arbeitslastclustern fort.
Die folgende Vorlage enthält alle Optionen, die für die Bereitstellung von Arbeitslastclustern unter AWS relevant sind. Sie können diese Vorlage kopieren und aktualisieren, um Arbeitslastcluster unter AWS bereitzustellen.
Erforderliche Optionen sind unkommentiert. Optionale Einstellungen sind auskommentiert. Standardwerte sind, wenn erforderlich, enthalten.
Mit Ausnahme der in den Abschnitten unter der Vorlage beschriebenen Optionen ist die Art und Weise, wie Sie die Variablen für AWS-spezifische Arbeitslastcluster konfigurieren, für Verwaltungscluster und Arbeitslastcluster dieselbe. Informationen zum Konfigurieren der Variablen finden Sie unter Bereitstellen von Verwaltungsclustern über eine Konfigurationsdatei und Konfiguration eines Verwaltungsclusters für AWS.
#! ---------------------------------------------------------------------
#! Cluster creation basic configuration
#! ---------------------------------------------------------------------
#! CLUSTER_NAME:
CLUSTER_PLAN: dev
NAMESPACE: default
# CLUSTER_API_SERVER_PORT:
CNI: antrea
#! ---------------------------------------------------------------------
#! Node configuration
#! AWS-only MACHINE_TYPE settings override cloud-agnostic SIZE settings.
#! ---------------------------------------------------------------------
# SIZE:
# CONTROLPLANE_SIZE:
# WORKER_SIZE:
CONTROL_PLANE_MACHINE_TYPE: t3.large
NODE_MACHINE_TYPE: m5.large
# NODE_MACHINE_TYPE_1: ""
# NODE_MACHINE_TYPE_2: ""
# CONTROL_PLANE_MACHINE_COUNT: 1
# WORKER_MACHINE_COUNT: 1
# WORKER_MACHINE_COUNT_0:
# WORKER_MACHINE_COUNT_1:
# WORKER_MACHINE_COUNT_2:
#! ---------------------------------------------------------------------
#! AWS Configuration
#! ---------------------------------------------------------------------
AWS_REGION:
# AWS_LOAD_BALANCER_SCHEME_INTERNAL: false
AWS_NODE_AZ: ""
# AWS_NODE_AZ_1: ""
# AWS_NODE_AZ_2: ""
# AWS_VPC_ID: ""
# AWS_PRIVATE_SUBNET_ID: ""
# AWS_PUBLIC_SUBNET_ID: ""
# AWS_PUBLIC_SUBNET_ID_1: ""
# AWS_PRIVATE_SUBNET_ID_1: ""
# AWS_PUBLIC_SUBNET_ID_2: ""
# AWS_PRIVATE_SUBNET_ID_2: ""
# AWS_VPC_CIDR: 10.0.0.0/16
# AWS_PRIVATE_NODE_CIDR: 10.0.0.0/24
# AWS_PUBLIC_NODE_CIDR: 10.0.1.0/24
# AWS_PRIVATE_NODE_CIDR_1: 10.0.2.0/24
# AWS_PUBLIC_NODE_CIDR_1: 10.0.3.0/24
# AWS_PRIVATE_NODE_CIDR_2: 10.0.4.0/24
# AWS_PUBLIC_NODE_CIDR_2: 10.0.5.0/24
# AWS_SECURITY_GROUP_APISERVER_LB: ""
# AWS_SECURITY_GROUP_BASTION: ""
# AWS_SECURITY_GROUP_CONTROLPLANE: ""
# AWS_SECURITY_GROUP_LB: ""
# AWS_SECURITY_GROUP_NODE: ""
# AWS_IDENTITY_REF_KIND: ""
# AWS_IDENTITY_REF_NAME: ""
# AWS_CONTROL_PLANE_OS_DISK_SIZE_GIB: 80
# AWS_NODE_OS_DISK_SIZE_GIB: 80
AWS_SSH_KEY_NAME:
BASTION_HOST_ENABLED: true
#! ---------------------------------------------------------------------
#! Common configuration
#! ---------------------------------------------------------------------
# TKG_CUSTOM_IMAGE_REPOSITORY: ""
# TKG_CUSTOM_IMAGE_REPOSITORY_SKIP_TLS_VERIFY: false
# TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE: ""
# TKG_HTTP_PROXY: ""
# TKG_HTTPS_PROXY: ""
# TKG_NO_PROXY: ""
# TKG_PROXY_CA_CERT: ""
ENABLE_AUDIT_LOGGING: false
ENABLE_DEFAULT_STORAGE_CLASS: true
CLUSTER_CIDR: 100.96.0.0/11
SERVICE_CIDR: 100.64.0.0/13
# OS_NAME: ""
# OS_VERSION: ""
# OS_ARCH: ""
#! ---------------------------------------------------------------------
#! Autoscaler configuration
#! ---------------------------------------------------------------------
ENABLE_AUTOSCALER: false
# AUTOSCALER_MAX_NODES_TOTAL: "0"
# AUTOSCALER_SCALE_DOWN_DELAY_AFTER_ADD: "10m"
# AUTOSCALER_SCALE_DOWN_DELAY_AFTER_DELETE: "10s"
# AUTOSCALER_SCALE_DOWN_DELAY_AFTER_FAILURE: "3m"
# AUTOSCALER_SCALE_DOWN_UNNEEDED_TIME: "10m"
# AUTOSCALER_MAX_NODE_PROVISION_TIME: "15m"
# AUTOSCALER_MIN_SIZE_0:
# AUTOSCALER_MAX_SIZE_0:
# AUTOSCALER_MIN_SIZE_1:
# AUTOSCALER_MAX_SIZE_1:
# AUTOSCALER_MIN_SIZE_2:
# AUTOSCALER_MAX_SIZE_2:
#! ---------------------------------------------------------------------
#! Antrea CNI configuration
#! ---------------------------------------------------------------------
# ANTREA_NO_SNAT: false
# ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD: false
# ANTREA_TRAFFIC_ENCAP_MODE: "encap"
# ANTREA_EGRESS_EXCEPT_CIDRS: ""
# ANTREA_NODEPORTLOCAL_ENABLED: true
# ANTREA_NODEPORTLOCAL_PORTRANGE: 61000-62000
# ANTREA_PROXY_ALL: false
# ANTREA_PROXY_NODEPORT_ADDRS: ""
# ANTREA_PROXY_SKIP_SERVICES: ""
# ANTREA_PROXY_LOAD_BALANCER_IPS: false
# ANTREA_FLOWEXPORTER_COLLECTOR_ADDRESS: "flow-aggregator.flow-aggregator.svc:4739:tls"
# ANTREA_FLOWEXPORTER_POLL_INTERVAL: "5s"
# ANTREA_FLOWEXPORTER_ACTIVE_TIMEOUT: "30s"
# ANTREA_FLOWEXPORTER_IDLE_TIMEOUT: "15s"
# ANTREA_KUBE_APISERVER_OVERRIDE:
# ANTREA_TRANSPORT_INTERFACE:
# ANTREA_TRANSPORT_INTERFACE_CIDRS: ""
# ANTREA_MULTICAST_INTERFACES: ""
# ANTREA_MULTICAST_IGMPQUERY_INTERVAL: "125s"
# ANTREA_TUNNEL_TYPE: geneve
# ANTREA_ENABLE_USAGE_REPORTING: false
# ANTREA_ENABLE_BRIDGING_MODE: false
# ANTREA_DISABLE_TXCHECKSUM_OFFLOAD: false
# ANTREA_DNS_SERVER_OVERRIDE: ""
# ANTREA_MULTICLUSTER_ENABLE: false
# ANTREA_MULTICLUSTER_NAMESPACE: ""
Wenn Sie einen Cluster für AWS bereitstellen, legen Sie AWS_REGION
auf die Region fest, in der Sie den Cluster bereitstellen möchten. Sie können AWS_REGION
in der Clusterkonfigurationsdatei, eine lokalen Umgebungsvariablen oder einem Anmeldedatenprofil wie in Konfigurieren von AWS-Kontoanmeldedaten festlegen.
Wenn Sie einen prod
-Cluster mit mehreren AZs unter AWS erstellen, verteilt Tanzu Kubernetes Grid die Steuerungsebene und die Worker-Knoten gleichmäßig auf die Verfügbarkeitszonen (Availability Zones, AZs), die Sie in Ihrer Clusterkonfiguration angegeben haben. Dies gilt einschließlich für Arbeitslastcluster, deren Konfiguration eines der folgenden Elemente enthält:
CONTROL_PLANE_MACHINE_COUNT
, die größer als die Standardanzahl von Knoten der Steuerungsebene istWORKER_MACHINE_COUNT
, die größer als die Standardanzahl von Worker-Knoten istWenn Sie beispielsweise WORKER_MACHINE_COUNT: 5
angeben, stellt Tanzu Kubernetes Grid zwei Worker-Knoten im ersten Verfügbarkeitsbereich, zwei Worker-Knoten im zweiten Verfügbarkeitsbereich und einen Worker-Knoten im dritten Verfügbarkeitsbereich bereit. Sie können optional diesen Standardmechanismus für die Verteilung von Worker-Knoten auf die Verfügbarkeitszonen anzupassen. Beachten Sie dazu die Anweisungen unter Konfigurieren von Einstellungen für die Verteilung von Worker-Knoten auf Verfügbarkeitszonen (siehe unten). Den standardmäßigen Mechanismus für die Verteilung von Knoten der Steuerungsebene auf Verfügbarkeitsbereiche können Sie nicht anpassen.
Beim Erstellen eines prod
-Clusters mit mehreren AZs auf AWS können Sie optional angeben, wie viele Worker-Knoten der Befehl tanzu cluster create
in jedem der drei AZs erstellt.
Gehen Sie dazu wie vor:
Fügen Sie die folgenden Variablen in die Clusterkonfigurationsdatei ein:
WORKER_MACHINE_COUNT_0
: Legt die Anzahl der Worker-Knoten im ersten Verfügbarkeitsbereich fest, AWS_NODE_AZ
.WORKER_MACHINE_COUNT_1
: Legt die Anzahl der Worker-Knoten im zweiten Verfügbarkeitsbereich fest, AWS_NODE_AZ_1
.WORKER_MACHINE_COUNT_2
: Legt die Anzahl der Worker-Knoten im dritten Verfügbarkeitsbereich fest, AWS_NODE_AZ_2
.Sie legen diese Variablen zusätzlich zu anderen obligatorischen und optionalen Einstellungen fest, wie in Arbeitslastcluster-Vorlage oben beschrieben.
Erstellen Sie den Cluster. Beispiel:
tanzu cluster create my-prod-cluster -f my-prod-cluster-config.yaml
Wenn Sie einen prod
-Arbeitslastcluster aus einem dev
-Verwaltungscluster erstellen, der auf AWS ausgeführt wird, müssen Sie eine Reihe zusätzlicher Variablen in der Clusterkonfigurationsdatei definieren, bevor Sie den Befehl tanzu cluster create
ausführen. Auf diese Weise kann Tanzu Kubernetes Grid den Cluster erstellen und seine Steuerungsebenen- und Worker-Knoten auf die Verfügbarkeitsbereiche verteilen.
Um einen prod
-Arbeitslastcluster aus einem dev
-Verwaltungscluster unter AWS zu erstellen, führen Sie die folgenden Schritte aus:
Legen Sie die folgenden Variablen in der Clusterkonfigurationsdatei fest:
PLAN
den Wert prod
fest.AWS_NODE_AZ
-Variablen: AWS_NODE_AZ
wurde festgelegt, als Sie Ihren dev
-Verwaltungscluster bereitgestellt haben. Fügen Sie für den prod
-Arbeitslastcluster AWS_NODE_AZ_1
und AWS_NODE_AZ_2
hinzu.AWS_PUBLIC_SUBNET_ID
-Variablen (vorhandene VPC): AWS_PUBLIC_NODE_CIDR
oder AWS_PUBLIC_SUBNET_ID
wurde festgelegt, als Sie Ihren dev
-Verwaltungscluster bereitgestellt haben. Fügen Sie für den prod
-Arbeitslastcluster eine der folgenden Optionen hinzu:
AWS_PUBLIC_NODE_CIDR_1
und AWS_PUBLIC_NODE_CIDR_2
AWS_PUBLIC_SUBNET_ID_1
und AWS_PUBLIC_SUBNET_ID_2
AWS_PRIVATE_SUBNET_ID
-Variablen (vorhandene VPC): AWS_PRIVATE_NODE_CIDR
oder AWS_PRIVATE_SUBNET_ID
wurde festgelegt, als Sie Ihren dev
-Verwaltungscluster bereitgestellt haben. Fügen Sie für den prod
-Arbeitslastcluster eine der folgenden Optionen hinzu:
AWS_PRIVATE_NODE_CIDR_1
und AWS_PRIVATE_NODE_CIDR_2
AWS_PRIVATE_SUBNET_ID_1
und AWS_PRIVATE_SUBNET_ID_2
(Optional) Passen Sie den standardmäßigen Mechanismus zur Verteilung der Worker-Knoten, die Sie bereitstellen möchten, auf Verfügbarkeitszonen an und beachten Sie dabei die Anweisungen unter Konfigurieren von Einstellungen für die Verteilung von Worker-Knoten auf Verfügbarkeitszonen. Standardmäßig verteilt Tanzu Kubernetes Grid prod
-Worker-Knoten gleichmäßig auf die Verfügbarkeitsbereiche.
Stellen Sie den Cluster bereit, indem Sie den Befehl tanzu cluster create
ausführen. Beispiel:
tanzu cluster create my-cluster -f my-cluster-config.yaml
Mit der Tanzu CLI können Sie eine Clusterkonfigurationsdatei in eine Objektspezifikationsdatei im Kubernetes-Stil für einen klassenbasierten Arbeitslastcluster konvertieren, ohne den Cluster bereitzustellen:
Um eine Objektspezifikation für jeden klassenbasierten Cluster zu generieren, den Sie mit tanzu cluster create
erstellen, müssen Sie sicherstellen, dass die Funktion auto-apply-generated-clusterclass-based-configuration
in der Konfiguration der Tanzu CLI auf false
festgelegt ist. Diese Funktion ist standardmäßig auf false
gesetzt. Wenn auto-apply-generated-clusterclass-based-configuration
auf false
festgelegt ist und Sie tanzu cluster create
mit dem Flag --file
ausführen, konvertiert der Befehl Ihre Clusterkonfigurationsdatei in eine Objektspezifikationsdatei und wird beendet, ohne dass der Cluster erstellt wird. Nach der Überprüfung der Konfiguration führen Sie tanzu cluster create
erneut mit der Objektspezifikationsdatei aus, die von der Tanzu CLI generiert wurde. Wenn Sie die Standardkonfiguration aktualisiert haben, führen Sie folgenden Befehl aus, um sie auf false
zurückzusetzen:
tanzu config set features.cluster.auto-apply-generated-clusterclass-based-configuration false
Um eine Objektspezifikationsdatei für einen einzelnen Cluster zu generieren, übergeben Sie die Option --dry-run
an tanzu cluster create
und speichern die Ausgabe in einer Datei. Verwenden Sie dieselben Optionen und die gleiche Konfiguration --file
, die Sie bei Erstellung des Clusters verwenden würden, z. B.:
tanzu cluster create my-cluster --file my-cluster-config.yaml --dry-run > my-cluster-spec.yaml
Sie können diese Objektspezifikation dann verwenden, um einen Cluster wie unter Erstellen eines klassenbasierten Clusters anhand der Objektspezifikation unten beschrieben bereitzustellen.
Fahren Sie mit dem Abschnitt Erstellen von Arbeitslastclustern fort.