Konfiguration des Verwaltungsclusters für AWS

Um eine Clusterkonfigurationsdatei zu erstellen, können Sie eine vorhandene Konfigurationsdatei für eine vorherige Bereitstellung in Amazon Web Services (AWS) kopieren und aktualisieren. Alternativ können Sie eine Datei mithilfe einer leeren Vorlage von Grund auf neu erstellen.

Wichtig
Tanzu Kubernetes Grid v2.4.x ist die letzte Version von TKG, die die Erstellung eigenständiger TKG-Verwaltungscluster auf AWS unterstützt. Die Möglichkeit, eigenständige TKG-Verwaltungscluster 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-Verwaltungscluster 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.

Verwaltungscluster-Konfigurationsvorlage

Die folgende Vorlage enthält alle relevanten Optionen für die Bereitstellung von Verwaltungsclustern in AWS. Sie können diese Vorlage kopieren und für die Bereitstellung von Verwaltungsclustern in AWS verwenden.

Informationen zum Aktualisieren der Einstellungen, die für alle Zielplattformen gelten, finden Sie unter Erstellen einer Verwaltungscluster-Konfigurationsdatei
Informationen zu allen Variablen der Konfigurationsdatei finden Sie in der Konfigurationsdatei-Variablenreferenz der Tanzu CLI.
Beispiele für die Konfiguration der vSphere-Einstellungen finden Sie in den Abschnitten unterhalb der Vorlage.

Erforderliche Optionen sind unkommentiert. Optionale Einstellungen sind auskommentiert. Standardwerte sind, wenn erforderlich, enthalten.

#! ---------------------------------------------------------------------
#! Basic cluster creation configuration
#! ---------------------------------------------------------------------

CLUSTER_NAME:
CLUSTER_PLAN: dev
INFRASTRUCTURE_PROVIDER: aws
# CLUSTER_API_SERVER_PORT:
ENABLE_CEIP_PARTICIPATION: true
ENABLE_AUDIT_LOGGING: true
CLUSTER_CIDR: 100.96.0.0/11
SERVICE_CIDR: 100.64.0.0/13
# CAPBK_BOOTSTRAP_TOKEN_TTL: 30m

#! ---------------------------------------------------------------------
#! 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
# OS_NAME: ""
# OS_VERSION: ""
# OS_ARCH: ""

#! ---------------------------------------------------------------------
#! AWS configuration
#! ---------------------------------------------------------------------

AWS_REGION:
AWS_NODE_AZ: ""
AWS_ACCESS_KEY_ID:
AWS_SECRET_ACCESS_KEY:
AWS_SSH_KEY_NAME:
BASTION_HOST_ENABLED: true
# 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_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_BASTION: sg-12345
# AWS_SECURITY_GROUP_CONTROLPLANE: sg-12346
# AWS_SECURITY_GROUP_APISERVER_LB: sg-12347
# AWS_SECURITY_GROUP_NODE: sg-12348
# AWS_SECURITY_GROUP_LB: sg-12349
# DISABLE_TMC_CLOUD_PERMISSIONS: false # Deactivates IAM permissions required for TMC enablement

#! ---------------------------------------------------------------------
#! Image repository configuration
#! ---------------------------------------------------------------------

# TKG_CUSTOM_IMAGE_REPOSITORY: ""
# TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE: ""

#! ---------------------------------------------------------------------
#! Proxy configuration
#! ---------------------------------------------------------------------

# TKG_HTTP_PROXY: ""
# TKG_HTTPS_PROXY: ""
# TKG_NO_PROXY: ""

#! ---------------------------------------------------------------------
#! Machine Health Check configuration
#! ---------------------------------------------------------------------

ENABLE_MHC:
ENABLE_MHC_CONTROL_PLANE: true
ENABLE_MHC_WORKER_NODE: true
MHC_UNKNOWN_STATUS_TIMEOUT: 5m
MHC_FALSE_STATUS_TIMEOUT: 12m

#! ---------------------------------------------------------------------
#! Identity management configuration
#! ---------------------------------------------------------------------

IDENTITY_MANAGEMENT_TYPE: "none"

#! Settings for IDENTITY_MANAGEMENT_TYPE: "oidc"
# CERT_DURATION: 2160h
# CERT_RENEW_BEFORE: 360h
# OIDC_IDENTITY_PROVIDER_CLIENT_ID:
# OIDC_IDENTITY_PROVIDER_CLIENT_SECRET:
# OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM: groups
# OIDC_IDENTITY_PROVIDER_ISSUER_URL:
# OIDC_IDENTITY_PROVIDER_SCOPES: "email,profile,groups,offline_access"
# OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM: email

#! The following two variables are used to configure Pinniped JWTAuthenticator for workload clusters
# SUPERVISOR_ISSUER_URL:
# SUPERVISOR_ISSUER_CA_BUNDLE_DATA:

#! Settings for IDENTITY_MANAGEMENT_TYPE: "ldap"
# LDAP_BIND_DN:
# LDAP_BIND_PASSWORD:
# LDAP_HOST:
# LDAP_USER_SEARCH_BASE_DN:
# LDAP_USER_SEARCH_FILTER:
# LDAP_USER_SEARCH_ID_ATTRIBUTE: dn
# LDAP_USER_SEARCH_NAME_ATTRIBUTE:
# LDAP_GROUP_SEARCH_BASE_DN:
# LDAP_GROUP_SEARCH_FILTER:
# LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: dn
# LDAP_GROUP_SEARCH_USER_ATTRIBUTE: dn
# LDAP_ROOT_CA_DATA_B64:

#! ---------------------------------------------------------------------
#! Antrea CNI configuration
#! ---------------------------------------------------------------------

# ANTREA_NO_SNAT: true
# ANTREA_NODEPORTLOCAL: true
# ANTREA_NODEPORTLOCAL_ENABLED: true
# ANTREA_NODEPORTLOCAL_PORTRANGE: 61000-62000
# ANTREA_TRAFFIC_ENCAP_MODE: "encap"
# ANTREA_PROXY: true
# ANTREA_PROXY_ALL: true
# ANTREA_PROXY_LOAD_BALANCER_IPS: false
# ANTREA_PROXY_NODEPORT_ADDRS:
# ANTREA_PROXY_SKIP_SERVICES: ""
# ANTREA_POLICY: true
# ANTREA_TRACEFLOW: true
# ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD: false
# ANTREA_ENABLE_USAGE_REPORTING: false
# ANTREA_EGRESS: true
# ANTREA_EGRESS_EXCEPT_CIDRS: ""
# ANTREA_FLOWEXPORTER: false
# ANTREA_FLOWEXPORTER_COLLECTOR_ADDRESS: "flow-aggregator.flow-aggregator.svc:4739:tls"
# ANTREA_FLOWEXPORTER_POLL_INTERVAL: "5s"
# ANTREA_FLOWEXPORTER_ACTIVE_TIMEOUT: "5s"
# ANTREA_FLOWEXPORTER_IDLE_TIMEOUT: "15s"
# ANTREA_IPAM: false
# ANTREA_KUBE_APISERVER_OVERRIDE: ""
# ANTREA_MULTICAST: false
# ANTREA_MULTICAST_INTERFACES: ""
# ANTREA_NETWORKPOLICY_STATS: true
# ANTREA_SERVICE_EXTERNALIP: true
# ANTREA_TRANSPORT_INTERFACE: ""
# ANTREA_TRANSPORT_INTERFACE_CIDRS: ""

AWS-Verbindungseinstellungen

Um Informationen zu Ihrem AWS-Konto, der Region und dem Verfügbarkeitsbereich bereitzustellen, in dem Sie den Cluster bereitstellen möchten, führen Sie einen der folgenden Schritte aus:

(Empfohlen) Konfigurieren Sie ein AWS-Anmeldedatenprofil mit der AWS-CLI und legen Sie eine Umgebungsvariable mit dem Namen AWS_PROFILE auf den Profilnamen Ihrer Bootstrap-Maschine fest.

Die Clusterkonfigurationsdatei sollte die Kontoanmeldedaten und andere Informationen enthalten. Beispiel:

AWS_REGION: eu-west-1
AWS_NODE_AZ: "eu-west-1a"
# Only use AWS_PROFILE OR combination of AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, but not both.
AWS_PROFILE: tkg
# AWS_ACCESS_KEY_ID:  <encoded:QUtJQVQ[...]SU82TTM=>
# AWS_SECRET_ACCESS_KEY: <encoded:eGN4RHJmLzZ[...]SR08yY2ticQ==>
AWS_SSH_KEY_NAME: default
BASTION_HOST_ENABLED: true

Verwenden Sie nur AWS_PROFILE oder eine Kombination aus AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY, aber nicht beides.
Die Werte für AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY müssen base64-codiert sein.

Verwenden eines internen Lastausgleichsdiensts für API-Server

Standardmäßig erstellt Tanzu Kubernetes Grid on AWS einen öffentlichen Lastausgleichsdienst für den Kubernetes-API-Server des Verwaltungsclusters.

In Umgebungen mit Internetbeschränkungen, z. B. mit Airgap oder Proxy, ist der öffentliche Lastausgleichsdienst nicht erforderlich, wenn Sie AWS_LOAD_BALANCER_SCHEME_INTERNAL in der Clusterkonfigurationsdatei auf true festlegen:

AWS_LOAD_BALANCER_SCHEME_INTERNAL: true

Diese Einstellung passt den Lastausgleichsdienst des Verwaltungsclusters dahingehend an, dass ein internes Schema verwendet wird, wodurch der Kubernetes-API-Server nicht für Zugriff und Weiterleitung über das Internet bereitsteht.

Knotengrößen konfigurieren

Die Tanzu CLI erstellt die einzelnen Knoten von Arbeitslastclustern gemäß den Einstellungen, die Sie in der Konfigurationsdatei angeben. In AWS können Sie alle Knoten-VMs so konfigurieren, dass sie dieselben vordefinierten Konfigurationen aufweisen, oder Sie können unterschiedliche vordefinierte Konfigurationen für die Steuerungsebenen- und Worker-Knoten festlegen. Mithilfe dieser Einstellungen können Sie Tanzu Kubernetes-Cluster erstellen, die Knoten mit anderen Konfigurationen als die Verwaltungsclusterknoten aufweisen. Sie können auch Cluster erstellen, in denen Steuerungsebenen- und Worker-Knoten jeweils unterschiedliche Konfigurationen aufweisen.

Wenn Sie den Verwaltungscluster erstellt haben, werden die Instanztypen für die Knotenmaschinen über die Optionen CONTROL_PLANE_MACHINE_TYPE und NODE_MACHINE_TYPE festgelegt. Standardmäßig werden diese Einstellungen auch für Arbeitslastcluster verwendet. Die Mindestkonfiguration umfasst 2 CPUs und 8 GB Arbeitsspeicher. Die Liste der kompatiblen Instanztypen variiert je nach Region.

CONTROL_PLANE_MACHINE_TYPE: "t3.large"
NODE_MACHINE_TYPE: "m5.large"

Sie können diese Einstellungen mit den Optionen SIZE, CONTROLPLANE_SIZE und WORKER_SIZE überschreiben. Um einen Tanzu Kubernetes-Cluster zu erstellen, in dem alle Steuerungsebenen- und Worker-Knoten-VMs dieselbe Größe aufweisen, geben Sie die Variable SIZE an. Wenn Sie die Variable SIZE festlegen, werden alle Knoten mit der von Ihnen festgelegten Konfiguration erstellt. Informationen zu den Konfigurationen der verschiedenen Knoteninstanzen für Amazon EC2 finden Sie unter Amazon EC2-Instanztypen.

SIZE: "t3.large"

Um einen Arbeitslastcluster zu erstellen, in dem die Steuerungsebenen- und Worker-Knoten-VMs unterschiedliche Größen aufweisen, geben Sie die Optionen CONTROLPLANE_SIZE und WORKER_SIZE an.

CONTROLPLANE_SIZE: "t3.large"
WORKER_SIZE: "m5.xlarge"

Sie können die Optionen CONTROLPLANE_SIZE und WORKER_SIZE mit der Option SIZE kombinieren. Wenn Sie beispielsweise SIZE: "t3.large" mit WORKER_SIZE: "m5.xlarge" angeben, werden die Knoten der Steuerungsebene auf t3.large und die Worker-Knoten auf m5.xlarge festgelegt.

SIZE: "t3.large"
WORKER_SIZE: "m5.xlarge"

VPC konfigurieren

Heben Sie die Kommentierung der folgenden Zeilen auf und aktualisieren Sie sie, um die VPC und andere AWS-Infrastruktur anzugeben, die den eigenständigen Verwaltungscluster hosten und von ihm verwendet werden soll

AWS_REGION:
AWS_NODE_AZ:
AWS_PRIVATE_SUBNET_ID:
AWS_PUBLIC_SUBNET_ID:
AWS_SSH_KEY_NAME:
AWS_VPC_ID:
BASTION_HOST_ENABLED:
CONTROL_PLANE_MACHINE_TYPE:
NODE_MACHINE_TYPE:
SERVICE_CIDR:
CLUSTER_CIDR:

Wenn Sie einen Produktionsverwaltungscluster bereitstellen, heben Sie auch die Kommentierung auf und geben Sie Folgendes für die beiden zusätzlichen Knoten der Steuerungsebene ein:

AWS_NODE_AZ_1:
AWS_NODE_AZ_2:
AWS_PRIVATE_SUBNET_ID_1:
AWS_PRIVATE_SUBNET_ID_2:
AWS_PUBLIC_SUBNET_ID_1:
AWS_PUBLIC_SUBNET_ID_2:

Die Konfiguration eines Produktionsverwaltungsclusters auf einer vorhandenen VPC könnte z. B. wie folgt aussehen:

AWS_REGION: us-west-2
AWS_NODE_AZ: us-west-2a
AWS_NODE_AZ_1: us-west-2b
AWS_NODE_AZ_2: us-west-2c
AWS_PRIVATE_SUBNET_ID: subnet-ID
AWS_PRIVATE_SUBNET_ID_1: subnet-ID
AWS_PRIVATE_SUBNET_ID_2: subnet-ID
AWS_PUBLIC_SUBNET_ID: subnet-ID
AWS_PUBLIC_SUBNET_ID_1: subnet-ID
AWS_PUBLIC_SUBNET_ID_2: subnet-ID
AWS_SSH_KEY_NAME: tkg
AWS_VPC_ID: vpc-ID
BASTION_HOST_ENABLED: "true"
CONTROL_PLANE_MACHINE_TYPE: m5.large
NODE_MACHINE_TYPE: m5.large
SERVICE_CIDR: 100.64.0.0/13
CLUSTER_CIDR: 100.96.0.0/11

Standardmäßig erstellt Tanzu Kubernetes Grid neue Sicherheitsgruppen, um Steuerungsebene, Worker-Knoten und Lastausgleichsdienste zu verbinden. Wenn benutzerdefinierte Regeln erforderlich sind, können Sie wie nachfolgend beschrieben Sicherheitsgruppen vorab bereitstellen, Regelsätze hinzufügen und Cluster so konfigurieren, dass die benutzerdefinierten Sicherheitsgruppen verwendet werden.

Benutzerdefinierte Sicherheitsgruppen konfigurieren

Standardmäßig erstellt Tanzu Kubernetes Grid fünf Sicherheitsgruppen innerhalb einer VPC.

Damit Tanzu Kubernetes Grid keine neuen Sicherheitsgruppen erstellt und stattdessen vorhandene, vorab bereitgestellte Sicherheitsgruppen mit benutzerdefinierten Regelsätzen verwendet, gehen Sie wie folgt vor:

Erstellen Sie Sicherheitsgruppen mit benutzerdefinierten Regelsätzen, die den Standardregelsätzen so gut wie möglich entsprechen.
Geben Sie die benutzerdefinierten Sicherheitsgruppen in der Clusterkonfigurationsdatei an, indem Sie die AWS_SECURITY_GROUP_*-Variablen auf die Namen der Sicherheitsgruppen festlegen. Beispiel:
```
AWS_SECURITY_GROUP_BASTION: sg-12345
```

Die fünf Sicherheitsgruppen, ihre Standardregeln und die entsprechenden Clusterkonfigurationsvariablen sind nachfolgend aufgeführt:

Gruppe: CLUSTER-NAME-bastion

Mithilfe der Clusterkonfigurationsvariable AWS_SECURITY_GROUP_BASTION festlegen.

Regeln:

Beschreibung	Protokoll	Von Port	An Port	Eingehenden Datenverkehr zulassen von	Erforderlich
SSH	TCP	22	22	0.0.0.0/0	Nein

Gruppe: CLUSTER-NAME-node

Mithilfe der Clusterkonfigurationsvariable AWS_SECURITY_GROUP_NODE festlegen.

Regeln:

Beschreibung	Protokoll	Von Port	An Port	Eingehenden Datenverkehr zulassen von	Erforderlich
SSH	TCP	22	22	Sicherheitsgruppe <cluster-name>-bastion	Nein
Knotenportdienste	TCP	30000	32767	0.0.0.0/0	Nein (siehe Anmerkung unten)
Kubelet-API	TCP	10250	10250	Sicherheitsgruppen <cluster-name>-controlplane und <cluster-name>-node	Ja
Antrea-CNI	TCP	10349-10351	10349-10351	Sicherheitsgruppe <cluster-name>-node	Ja
GENEVE	UDP	6081	6081	Sicherheitsgruppe <cluster-name>-node	Ja

Hinweis
0.0.0.0/0 wird nur eingehend von VPC, VPC mit Peers und allen über VPN oder DirectConnect verbundenen Netzwerken genutzt. 0.0.0.0/0 sollte nicht als über das Internet erreichbar interpretiert werden. Es ist möglich, sowohl den Portbereich als auch die Ingress-Regel für Knotenportdienste zu ändern, solange Administratoren vorhanden sind und sie nicht für die Funktion des Clusters verwendet werden.

Gruppe: CLUSTER-NAME-controlplane

Mithilfe der Clusterkonfigurationsvariable AWS_SECURITY_GROUP_CONTROLPLANE festlegen.

Regeln:

Beschreibung	Protokoll	Von Port	An Port	Eingehenden Datenverkehr zulassen von	Erforderlich
SSH	TCP	22	22	Sicherheitsgruppe <cluster-name>-bastion	Nein
Kubernetes-API	TCP	6443*	6443*	Sicherheitsgruppen <cluster-name>-apiserver-lb, <cluster-name>-apiserver-controlplane und <cluster-name>-apiserver-node	Ja
etcd	TCP	2379	2379	Sicherheitsgruppe <cluster-name>-controlplane	Ja
etcd peer	TCP	2380	2380	Sicherheitsgruppe <cluster-name>-controlplane	Ja
addons-manager	TCP	9865	9865	Sicherheitsgruppen <cluster-name>-controlplane	Ja
kapp-controller	TCP	10100	10100	Sicherheitsgruppen <cluster-name>-controlplane	Ja

* Ersetzen Sie beim Festlegen von CLUSTER_API_SERVER_PORT die Zahl 6443 durch die Portnummer, die Sie in der Variable festgelegt haben.

Gruppe: CLUSTER-NAME-apiserver-lb

Mithilfe der Clusterkonfigurationsvariable AWS_SECURITY_GROUP_APISERVER_LB festlegen.

Regeln:

Beschreibung	Protokoll	Von Port	An Port	Eingehenden Datenverkehr zulassen von	Erforderlich
Kubernetes-API	TCP	6443*	6443*	0.0.0.0/0	Nein (siehe Anmerkung unten)

* Ersetzen Sie beim Festlegen von CLUSTER_API_SERVER_PORT die Zahl 6443 durch die Portnummer, die Sie in der Variable festgelegt haben.

Hinweis
Die Regel 0.0.0.0/0 ist standardmäßig über das Internet zugänglich, wenn sie nicht für die interne Bereitstellung des Lastausgleichsdiensts festgelegt ist. Ist der Lastausgleichsdienst intern, muss er über den Verwaltungscluster (für Arbeitslastcluster) oder die Bootstrap-Maschine (für den Verwaltungscluster) zugänglich sein. Diese Regel kann gesperrt werden, jedoch MUSS dann die folgende Regel hinzugefügt werden:

Beschreibung	Protokoll	Von Port	An Port	Eingehenden Datenverkehr zulassen von	Erforderlich
Kubernetes-API im Cluster	TCP	6443*	6443*	Sicherheitsgruppen <cluster-name>-controlplane und <cluster-name>-node	Ja

* Ersetzen Sie beim Festlegen von CLUSTER_API_SERVER_PORT die Zahl 6443 durch die Portnummer, die Sie in der Variable festgelegt haben.

Gruppe: CLUSTER-NAME-lb

Mithilfe der Clusterkonfigurationsvariable AWS_SECURITY_GROUP_LB festlegen.

Diese Sicherheitsgruppe wird für Arbeitslastausgleichsdienste verwendet. Dieser Sicherheitsgruppe werden keine Regeln hinzugefügt. AWS-Administratoren sollten den Regelsatz nach Bedarf für die Anwendungsarbeitslast anpassen.

Nächste Schritte

Erstellen Sie nach Aktualisierung der Konfigurationsdatei des Verwaltungsclusters den Verwaltungscluster. Befolgen Sie dazu die unter Bereitstellen von Verwaltungsclustern über eine Konfigurationsdatei beschriebenen Schritte.