Variablenreferenz für Konfigurationsdatei

Diese Referenz listet alle Variablen auf, die Sie angeben können, um Clusterkonfigurationsoptionen für die Tanzu CLI bereitzustellen.

Für diese Variablen in einer YAML-Konfigurationsdatei setzen Sie zwischen dem Doppelpunkt (:) und dem Variablenwert ein Leerzeichen. Beispiel:

CLUSTER_NAME: my-cluster

Die Zeilenreihenfolge in der Konfigurationsdatei spielt keine Rolle. Optionen werden hier in alphabetischer Reihenfolge dargestellt. Weitere Informationen finden Sie auch im Abschnitt Vorrang für Konfigurationswerte unten.

Gemeinsame Variablen für alle Zielplattformen

In diesem Abschnitt werden Variablen aufgelistet, die allen Zielplattformen gemeinsam sind. Die Variablen können auf Verwaltungscluster, Arbeitslastcluster oder beides angewendet werden. Weitere Informationen finden Sie in Erstellen einer Konfigurationsdatei für den Verwaltungscluster unter Konfigurieren von allgemeinen Informationen zum Erstellen eines Verwaltungsclusters.

Variable	Kann festgelegt werden in…		Beschreibung
	Verwaltungscluster-YAML	Arbeitslastcluster-YAML
APISERVER_EVENT_RATE_LIMIT_CONF_BASE64	✔	✔	Nur klassenbasierte Cluster. Aktiviert und konfiguriert einen EventRateLimit-Zugangscontroller, um den Datenverkehr zum Kubernetes-API-Server zu leiten. Legen Sie diese Eigenschaft fest, indem Sie eine EventRateLimit-Konfigurationsdatei config.yaml erstellen, wie in der Kubernetes-Dokumentation beschrieben, und sie dann in einen Zeichenfolgenwert konvertieren, indem Sie base64 -w 0 config.yaml ausführen
CAPBK_BOOTSTRAP_TOKEN_TTL	✔	✖	Optional; standardmäßig 15m, 15 Minuten. Der TTL-Wert des von kubeadm bei Cluster-Initialisierungsvorgängen verwendeten Bootstrap-Tokens.
CLUSTER_API_SERVER_PORT	✔	✔	Optional; standardmäßig 6443. Diese Variable wird ignoriert, wenn Sie NSX Advanced Load Balancer (vSphere) aktivieren. Um den standardmäßigen Kubernetes-API-Serverport für Bereitstellungen mit NSX Advanced Load Balancer außer Kraft zu setzen, legen Sie VSPHERE_CONTROL_PLANE_ENDPOINT_PORT fest.
CLUSTER_CIDR	✔	✔	Optional; standardmäßig 100.96.0.0/11. Der für Pods zu verwendende CIDR-Bereich. Ändern Sie den Standardwert nur, wenn der empfohlene Standardbereich nicht verfügbar ist.
CLUSTER_NAME	✔	✔	Dieser Name muss den DNS-Hostnamenanforderungen entsprechen, wie in RFC 952 beschrieben und in RFC 1123 geändert, und darf höchstens 42 Zeichen lang sein. Für Arbeitslastcluster wird diese Einstellung durch das Argument CLUSTER_NAME überschrieben, das an tanzu cluster create übergeben wird. Wenn Sie für Verwaltungscluster keinen CLUSTER_NAME angeben, wird ein eindeutiger Name generiert.
CLUSTER_PLAN	✔	✔	Erforderlich. Legen Sie diese Variable auf dev, prod oder einen benutzerdefinierten Plan fest, wie in Neuer Plan nginx beschrieben. Der dev-Plan stellt einen Cluster mit einem einzelnen Knoten der Steuerungsebene bereit. Der prod-Plan stellt einen hochverfügbaren Cluster mit drei Knoten der Steuerungsebene bereit.
CNI	✖	✔	Optional; standardmäßig antrea. Container-Netzwerkschnittstelle. Überschreiben Sie den Standardwert für Verwaltungscluster nicht. Für Arbeitslastcluster können Sie als CNI entweder antrea, calico oder none festlegen. Die Option calico wird unter Windows nicht unterstützt. Weitere Informationen finden Sie unter Bereitstellen eines Clusters mit einem nicht standardmäßigen CNI. Wenn Sie die Antrea-Konfiguration anpassen möchten, finden Sie weitere Informationen unter Antrea-CNI-Konfiguration (siehe unten).
CONTROLPLANE_CERTIFICATE_ROTATION_ENABLED	✔	✔	Optional; standardmäßig false. Legen Sie diese Option auf true fest, wenn VM-Zertifikate des Steuerungsebenenknotens vor dem Ablauf automatisch verlängert werden sollen. Weitere Informationen finden Sie unter Automatische Verlängerung des Zertifikats von Steuerungsebenen-Knoten.
CONTROLPLANE_CERTIFICATE_ROTATION_DAYS_BEFORE	✔	✔	Optional; standardmäßig 90. Wenn CONTROLPLANE_CERTIFICATE_ROTATION_ENABLED true ist, legen Sie die Anzahl der Tage vor dem Ablaufdatum des Zertifikats fest, um die Clusterknotenzertifikate automatisch zu verlängern. Weitere Informationen finden Sie unter Automatische Verlängerung des Zertifikats von Steuerungsebenen-Knoten.
ENABLE_AUDIT_LOGGING	✔	✔	Optional; standardmäßig false. Überwachungsprotokollierung für den Kubernetes-API-Server. Um die Überwachungsprotokollierung zu aktivieren, legen Sie für die Variable den Wert true fest. Tanzu Kubernetes Grid schreibt diese Protokolle in die Datei /var/log/kubernetes/audit.log. Weitere Informationen finden Sie unter Überwachungsprotokollierung. Die Aktivierung der Kubernetes-Überwachung kann zu sehr hohen Protokollvolumen führen. Um diese Menge zu bewältigen, empfiehlt VMware die Verwendung eines Protokoll-Forwarders wie Fluent Bit.
ENABLE_AUTOSCALER	✖	✔	Optional; standardmäßig false. Wenn der Wert true festgelegt ist, müssen Sie in der Tabelle Automatische Clusterskalierung unten zusätzliche Variablen festlegen.
ENABLE_CEIP_PARTICIPATION	✔	✖	Optional; standardmäßig true. Mit false wird die Teilnahme am VMware-Programm zur Verbesserung der Benutzerfreundlichkeit deaktiviert. Sie können die Teilnahme am Programm auch nach der Bereitstellung des Verwaltungsclusters aktivieren oder deaktivieren. Weitere Informationen finden Sie unter An- oder Abmelden beim VMware CEIP in Verwalten der Teilnahme am CEIP und Programm zur Verbesserung der Benutzerfreundlichkeit („CEIP“).
ENABLE_DEFAULT_STORAGE_CLASS	✖	✔	Optional; standardmäßig true. Informationen zu Speicherklassen finden Sie unter Dynamischer Speicher.
ENABLE_MHC usw.	✔	✔	Optional. Den vollständigen Satz von MHC-Variablen und ihre Funktionsweise finden Sie unten unter Maschinenintegritätsprüfungen. Legen Sie für von vSphere with Tanzu erstellte Arbeitslastcluster ENABLE_MHC auf false fest.
IDENTITY_MANAGEMENT_TYPE	✔	✖	Optional; standardmäßig none. Für Verwaltungscluster: Legen Sie zum Aktivieren oidc oder ldap fest. Dabei sind zusätzliche OIDC- oder LDAP-Einstellungen erforderlich. Diese sind in den Tabellen für Identitätsanbieter – OIDC und LDAP – aufgeführt (siehe unten). Sie können diese Variable auslassen oder auf none setzen, um die Identitätsverwaltung zu deaktivieren. Es wird dringend empfohlen, die Identitätsverwaltung für Produktionsbereitstellungen zu aktivieren. Hinweis Sie müssen OIDC- oder LDAP-Einstellungen in der Konfigurationsdatei für Arbeitslastcluster konfigurieren.
INFRASTRUCTURE_PROVIDER	✔	✔	Erforderlich. Legen Sie als Einstellung vsphere, aws, azure oder tkg-service-vsphere fest.
NAMESPACE	✖	✔	Optional; ist standardmäßig default, um Arbeitslastcluster in einem Namespace mit dem Namen default bereitzustellen.
SERVICE_CIDR	✔	✔	Optional; standardmäßig 100.64.0.0/13. Der für die Kubernetes-Dienste zu verwendende CIDR-Bereich. Ändern Sie diesen Wert nur, wenn der empfohlene Standardbereich nicht verfügbar ist.

Identitätsanbieter – OIDC

Wenn Sie die Einstellung IDENTITY_MANAGEMENT_TYPE: oidc angeben, legen Sie die folgenden Variablen fest, um einen OIDC-Identitätsanbieter zu konfigurieren. Weitere Informationen finden Sie in Konfigurieren der Identitätsverwaltung unter Erstellen einer Konfigurationsdatei für den Verwaltungscluster.

Tanzu Kubernetes Grid wird mithilfe von Pinniped in OIDC integriert (wie unter Informationen zur Identitäts- und Zugriffsverwaltung beschrieben).

Variable	Kann festgelegt werden in…		Beschreibung
	Verwaltungscluster-YAML	Arbeitslastcluster-YAML
CERT_DURATION	✔	✖	Optional; standardmäßig 2160h. Legen Sie diese Variable fest, wenn Sie Pinniped so konfigurieren, dass von cert-manager verwaltete selbstsignierte Zertifikate verwendet werden.
CERT_RENEW_BEFORE	✔	✖	Optional; standardmäßig 360h. Legen Sie diese Variable fest, wenn Sie Pinniped so konfigurieren, dass von cert-manager verwaltete selbstsignierte Zertifikate verwendet werden.
OIDC_IDENTITY_PROVIDER_CLIENT_ID	✔	✖	Erforderlich. Der client_id-Wert, den Sie von Ihrem OIDC-Anbieter erhalten. Ist Ihr Anbieter beispielsweise Okta, melden Sie sich bei Okta an, erstellen Sie eine Web-Anwendung und wählen Sie die Option „Client-Anmeldedaten (Client Credentials)“ aus, um Werte für client_id und secret zu erhalten. Diese Einstellung wird in einem geheimen Schlüssel gespeichert, das von OIDCIdentityProvider.spec.client.secretName in der benutzerdefinierten Ressource OIDCIdentityProvider von Pinniped referenziert wird.
OIDC_IDENTITY_PROVIDER_CLIENT_SECRET	✔	✖	Erforderlich. Der secret-Wert, den Sie von Ihrem OIDC-Anbieter erhalten. Dieser Wert darf nicht Base64-codiert werden.
OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM	✔	✖	Optional. Der Name Ihres Gruppenanspruchs. Hierdurch wird die Gruppe eines Benutzers im JSON Web Token (JWT)-Anspruch verwendet. Der Standardwert ist groups. Diese Einstellung entspricht OIDCIdentityProvider.spec.claims.groups in der benutzerdefinierten Ressource OIDCIdentityProvider von Pinniped.
OIDC_IDENTITY_PROVIDER_ISSUER_URL	✔	✖	Erforderlich. Die IP- oder DNS-Adresse Ihres OIDC-Servers. Diese Einstellung entspricht OIDCIdentityProvider.spec.issuer in der custom resource von Pinniped.
OIDC_IDENTITY_PROVIDER_SCOPES	✔	✖	Erforderlich. Eine kommagetrennte Liste mit zusätzlichen Geltungsbereichen, die in der Token-Antwort angefordert werden sollen. Beispiel: "email,offline_access". Diese Einstellung entspricht OIDCIdentityProvider.spec.authorizationConfig.additionalScopes in der benutzerdefinierten Ressource OIDCIdentityProvider von Pinniped.
OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM	✔	✖	Erforderlich. Der Name Ihres Benutzernamensanspruchs. Dieser wird verwendet, um den Benutzernamen eines Benutzers im JWT-Anspruch festzulegen. Geben Sie je nach Anbieter Ansprüche wie user_name, email oder code ein. Diese Einstellung entspricht OIDCIdentityProvider.spec.claims.username in der benutzerdefinierten Ressource OIDCIdentityProvider von Pinniped.
OIDC_IDENTITY_PROVIDER_ADDITIONAL_AUTHORIZE_PARAMS	✔	✖	Optional. Fügen Sie benutzerdefinierte Parameter hinzu, die an den OIDC-Identitätsanbieter gesendet werden sollen. Je nach Anbieter können diese Angaben erforderlich sein, um ein Aktualisierungstoken vom Anbieter zu erhalten. Beispiel: prompt=consent. Trennen Sie mehrere Werte durch Kommas. Diese Einstellung entspricht OIDCIdentityProvider.spec.authorizationConfig.additionalAuthorizeParameters in der benutzerdefinierten Ressource OIDCIdentityProvider von Pinniped.
OIDC_IDENTITY_PROVIDER_CA_BUNDLE_DATA_B64	✔	✖	Optional. Ein Base64-codiertes CA-Paket zum Einrichten von TLS mit OIDC-Identitätsanbietern. Diese Einstellung entspricht OIDCIdentityProvider.spec.tls.certificateAuthorityData in der benutzerdefinierten Ressource OIDCIdentityProvider von Pinniped.
SUPERVISOR_ISSUER_URL	✔	✖	Nicht ändern. Diese Variable wird automatisch in der Konfigurationsdatei aktualisiert, wenn Sie den Befehl tanzu cluster create command ausführen. Diese Einstellung entspricht JWTAuthenticator.spec.audience in der benutzerdefinierten Ressource JWTAuthenticator und FederationDomain.spec.issuer von Pinniped in der benutzerdefinierten Ressource FederationDomain von Pinniped.
SUPERVISOR_ISSUER_CA_BUNDLE_DATA_B64	✔	✖	Nicht ändern. Diese Variable wird automatisch in der Konfigurationsdatei aktualisiert, wenn Sie den Befehl tanzu cluster create command ausführen. Diese Einstellung entspricht JWTAuthenticator.spec.tls.certificateAuthorityData in der benutzerdefinierten Ressource JWTAuthenticator von Pinniped.

Identitätsanbieter – LDAP

Wenn Sie die Einstellung IDENTITY_MANAGEMENT_TYPE: ldap angeben, legen Sie die folgenden Variablen fest, um einen LDAP-Identitätsanbieter zu konfigurieren. Weitere Informationen finden Sie in Konfiguration der Identitätsverwaltung unter Erstellen einer Konfigurationsdatei für den Verwaltungscluster.

Tanzu Kubernetes Grid wird mithilfe von Pinniped in LDAP integriert (wie unter Informationen zur Identitäts- und Zugriffsverwaltung beschrieben). Jede der folgenden Variablen entspricht einer Konfigurationseinstellung in der benutzerdefinierten Ressource LDAPIdentityProvider von Pinniped. Eine vollständige Beschreibung dieser Einstellungen und Informationen zur Konfiguration finden Sie unter LDAPIdentityProvider in der Pinniped-Dokumentation.

Variable	Kann festgelegt werden in…		Beschreibung
	Verwaltungscluster-YAML	Arbeitslastcluster-YAML
Für die Verbindung mit dem LDAP-Server:
LDAP_HOST	✔	✖	Erforderlich. Die IP- oder DNS-Adresse Ihres LDAP-Servers. Wenn der LDAP-Server den Standardport 636 überwacht, der die geschützte Konfiguration darstellt, müssen Sie den Port nicht angeben. Wenn der LDAP-Server einen anderen Port überwacht, geben Sie die Adresse und den Port des LDAP-Servers im Format “host:port” an. Diese Einstellung entspricht LDAPIdentityProvider.spec.host in der benutzerdefinierten Ressource LDAPIdentityProvider von Pinniped.
LDAP_ROOT_CA_DATA_B64	✔	✖	Optional. Wenn Sie einen LDAPS-Endpoint verwenden, fügen Sie den Base64-codierten Inhalt des LDAP-Serverzertifikats ein. Diese Einstellung entspricht LDAPIdentityProvider.spec.tls.certificateAuthorityData in der benutzerdefinierten Ressource LDAPIdentityProvider von Pinniped.
LDAP_BIND_DN	✔	✖	Erforderlich. Der DN für ein vorhandenes Anwendungsdienstkonto. Beispiel: “cn=bind-user,ou=people,dc=example,dc=com”. Der Connector verwendet diese Anmeldedaten, um nach Benutzern und Gruppen zu suchen. Dieses Dienstkonto muss mindestens über Leseberechtigungen verfügen, um die durch die anderen LDAP_*-Konfigurationsoptionen konfigurierten Abfragen durchzuführen. Einbezogen in den geheimen Schlüssel für spec.bind.secretName in der benutzerdefinierten Ressource LDAPIdentityProvider von Pinniped.
LDAP_BIND_PASSWORD	✔	✖	Erforderlich. Das Kennwort für das in LDAP_BIND_DN festgelegte Anwendungsdienstkonto. Einbezogen in den geheimen Schlüssel für spec.bind.secretName in der benutzerdefinierten Ressource LDAPIdentityProvider von Pinniped.
Für die Benutzersuche:
LDAP_USER_SEARCH_BASE_DN	✔	✖	Erforderlich. Der Punkt, von dem aus die LDAP-Suche gestartet werden soll. Beispiel: OU=Users,OU=domain,DC=io. Diese Einstellung entspricht LDAPIdentityProvider.spec.userSearch.base in der benutzerdefinierten Ressource LDAPIdentityProvider von Pinniped.
LDAP_USER_SEARCH_FILTER	✔	✖	Optional. Ein optionaler Filter, der von der LDAP-Suche verwendet werden soll. Diese Einstellung entspricht LDAPIdentityProvider.spec.userSearch.filter in der benutzerdefinierten Ressource LDAPIdentityProvider von Pinniped. Ab TKG v2.3 müssen Sie beim Erstellen eines Verwaltungsclusters oder beim Aktualisieren des geheimen Schlüssels des Pinniped-Pakets für einen bestehenden Verwaltungscluster das Pinniped-Format für diesen Wert verwenden. Beispiel: &(objectClass=posixAccount)(uid={}).
LDAP_USER_SEARCH_ID_ATTRIBUTE	✔	✖	Optional. Das LDAP-Attribut, das die Benutzer-ID enthält. dn ist die Standardeinstellung. Diese Einstellung entspricht LDAPIdentityProvider.spec.userSearch.attributes.uid in der benutzerdefinierten Ressource LDAPIdentityProvider von Pinniped.
LDAP_USER_SEARCH_NAME_ATTRIBUTE	✔	✖	Erforderlich. Das LDAP-Attribut, das den Benutzernamen des Benutzers enthält. Beispiel: mail. Diese Einstellung entspricht LDAPIdentityProvider.spec.userSearch.attributes.username in der benutzerdefinierten Ressource LDAPIdentityProvider von Pinniped.
Für die Gruppensuche:
LDAP_GROUP_SEARCH_BASE_DN	✔	✖	Optional. Der Punkt, von dem aus die LDAP-Suche gestartet werden soll. Beispiel: OU=Groups,OU=domain,DC=io. Wenn nicht festgelegt, wird die Gruppensuche übersprungen. Diese Einstellung entspricht LDAPIdentityProvider.spec.groupSearch.base in der benutzerdefinierten Ressource LDAPIdentityProvider von Pinniped.
LDAP_GROUP_SEARCH_FILTER	✔	✖	Optional. Ein optionaler Filter, der von der LDAP-Suche verwendet werden soll. Diese Einstellung entspricht LDAPIdentityProvider.spec.groupSearch.filer in der benutzerdefinierten Ressource LDAPIdentityProvider von Pinniped. Ab TKG v2.3 müssen Sie beim Erstellen eines Verwaltungsclusters oder beim Aktualisieren des geheimen Schlüssels des Pinniped-Pakets für einen bestehenden Verwaltungscluster das Pinniped-Format für diesen Wert verwenden. Beispiel: &(objectClass=posixGroup)(memberUid={}).
LDAP_GROUP_SEARCH_NAME_ATTRIBUTE	✔	✖	Optional. Das LDAP-Attribut, das den Namen der Gruppe enthält. dn ist die Standardeinstellung. Diese Einstellung entspricht LDAPIdentityProvider.spec.groupSearch.attributes.groupName in der benutzerdefinierten Ressource LDAPIdentityProvider von Pinniped.
LDAP_GROUP_SEARCH_USER_ATTRIBUTE	✔	✖	Optional. Das Attribut des Benutzerdatensatzes, das als Wert des Mitgliedschaftsattributs des Gruppendatensatzes verwendet wird. dn ist die Standardeinstellung. Diese Einstellung entspricht LDAPIdentityProvider.spec.groupSearch.userAttributeForFilter in der benutzerdefinierten Ressource LDAPIdentityProvider von Pinniped.
LDAP_GROUP_SEARCH_SKIP_ON_REFRESH	✔	✖	Optional. false ist die Standardeinstellung. Wenn diese Option auf true gesetzt ist, werden die Gruppenmitgliedschaften eines Benutzers nur zu Beginn der täglichen Sitzung des Benutzers aktualisiert. Die Festlegung von LDAP_GROUP_SEARCH_SKIP_ON_REFRESH auf true wird nicht empfohlen und sollte nur dann vorgenommen werden, wenn es andernfalls nicht möglich ist, die Gruppenabfrage schnell genug zu machen, um sie während der Sitzungsaktualisierung durchzuführen. Diese Einstellung entspricht LDAPIdentityProvider.spec.groupSearch.skipGroupRefresh in der benutzerdefinierten LDAPIdentityProvider-Ressource von Pinniped.

Knoten-Konfiguration

Konfigurieren Sie die Steuerungsebenen- und Worker-Knoten sowie das Betriebssystem, auf dem die Knoteninstanzen ausgeführt werden. Weitere Informationen finden Sie in Konfigurieren der Knoteneinstellungen unter Erstellen einer Konfigurationsdatei für den Verwaltungscluster.

Variable	Kann festgelegt werden in…		Beschreibung
	Verwaltungscluster-YAML	Arbeitslastcluster-YAML
CONTROL_PLANE_MACHINE_COUNT	✔	✔	Optional. Stellen Sie einen Arbeitslastcluster mit einer höheren Anzahl von Knoten der Steuerungsebene bereit als im dev- und im prod-Plan standardmäßig vorgesehen. Sie müssen eine ungerade Anzahl von Knoten der Steuerungsebene angeben.
CONTROL_PLANE_NODE_LABELS	✔	✔	Nur klassenbasierte Cluster. Weisen Sie den Knoten der Steuerungsebene benutzerdefinierte dauerhafte Bezeichnungen zu, zum Beispiel CONTROL_PLANE_NODE_LABELS: ‘key1=value1,key2=value2’. Um dies in einem planbasierten Legacy-Cluster zu konfigurieren, verwenden Sie ein ytt-Overlay, wie in Benutzerdefinierte Knotenbezeichnungen beschrieben. Worker-Knotenbezeichnungen werden in ihrem Knotenpool wie unter Verwalten von Knotenpools verschiedener VM-Typen beschrieben festgelegt.
CONTROL_PLANE_NODE_NAMESERVERS	✔	✔	Nur vSphere. Dadurch kann der Benutzer eine kommagetrennte Liste der DNS-Server angeben, die auf Knoten der Steuerungsebene konfiguriert werden sollen, zum Beispiel, CONTROL_PLANE_NODE_NAMESERVERS: 10.132.7.1, 10.142.7.1. Unterstützt unter Ubuntu und Photon. Nicht unterstützt unter Windows. Ein Beispiel für einen Anwendungsfall finden Sie unter Knoten-IPAM unten.
CONTROL_PLANE_NODE_SEARCH_DOMAINS	✔	✔	Nur klassenbasierte Cluster. Konfiguriert die .local-Suchdomänen für Clusterknoten, z. B. CONTROL_PLANE_NODE_SEARCH_DOMAINS: corp.local. Um dies in einem planbasierten Legacy-Cluster auf vSphere zu konfigurieren, verwenden Sie ein ytt-Overlay, wie in Auflösen der Domäne .local beschrieben.
CONTROLPLANE_SIZE	✔	✔	Optional. Größe für Knoten-VMs der Steuerungsebene. Setzt die Parameter SIZE und VSPHERE_CONTROL_PLANE_ außer Kraft. Mögliche Werte finden Sie unter SIZE.
OS_ARCH	✔	✔	Optional. Architektur für das Betriebssystem der Knoten-VM Die standardmäßige und einzige aktuelle Option ist amd64.
OS_NAME	✔	✔	Optional. Betriebssystem der Knoten-VM. Wird für Ubuntu LTS standardmäßig auf ubuntu gesetzt. Dies kann auch photon für Photon OS unter vSphere oder amazon für Amazon Linux unter AWS sein.
OS_VERSION	✔	✔	Optional. Version für das Betriebssystem OS_NAME (siehe oben). Wird für Ubuntu standardmäßig auf 20.04 gesetzt. Dies kann 3 für Photon unter vSphere und 2 für Amazon Linux unter AWS sein.
SIZE	✔	✔	Optional. Größe für VMs von Steuerungsebenen- und Worker-Knoten. Setzt die Parameter VSPHERE_CONTROL_PLANE_* und VSPHERE_WORKER_* außer Kraft. Legen Sie für vSphere small, medium, large oder extra-large fest, wie in Vordefinierte Knotengrößen beschrieben. Legen Sie für AWS einen Instanztyp fest, z. B. t3.small. Legen Sie für Azure einen Instanztyp fest, z. B. Standard_D2s_v3.
WORKER_MACHINE_COUNT	✔	✔	Optional. Stellen Sie einen Arbeitslastcluster mit einer höheren Anzahl von Worker-Knoten bereit, als im dev- und im prod-Plan standardmäßig vorgesehen.
WORKER_NODE_NAMESERVERS	✔	✔	Nur vSphere. Dadurch kann der Benutzer eine kommagetrennte Liste der DNS-Server angeben, die auf Worker-Knoten konfiguriert werden sollen, zum Beispiel, WORKER_NODE_NAMESERVERS: 10.132.7.1, 10.142.7.1. Unterstützt unter Ubuntu und Photon. Nicht unterstützt unter Windows. Ein Beispiel für einen Anwendungsfall finden Sie unter Knoten-IPAM unten.
WORKER_NODE_SEARCH_DOMAINS	✔	✔	Nur klassenbasierte Cluster. Konfiguriert die .local-Suchdomänen für Clusterknoten, z. B. CONTROL_PLANE_NODE_SEARCH_DOMAINS: corp.local. Um dies in einem planbasierten Legacy-Cluster auf vSphere zu konfigurieren, verwenden Sie ein ytt-Overlay, wie in Auflösen der Domäne .local beschrieben.
WORKER_SIZE	✔	✔	Optional. Größe für Worker-Knoten-VMs. Setzt die Parameter SIZEVSPHERE_WORKER_ und außer Kraft. Mögliche Werte finden Sie unter SIZE.
CUSTOM_TDNF_REPOSITORY_CERTIFICATE	✔	✔	(Tech Preview) Optional. Mit dieser Variablen können Sie festlegen, ob Sie einen angepassten tdnf-Repository-Server mit einem selbstsignierten Zertifikat anstelle des Photon-Standard-tdnf-Repository-Servers verwenden. Geben Sie den Inhalt des Base64-codierten Zertifikats des tdnf-Repository-Servers ein. Löscht alle Repositorys unter /etc/yum.repos.d/ und veranlasst, dass der TKG-Knoten dem Zertifikat vertraut.

Pod-Sicherheitsstandards für Zugangscontroller für Pod-Sicherheit

Konfigurieren Sie die Pod-Sicherheitsstandards für einen clusterweiten Zugangscontroller für Pod-Sicherheit (Pod Security Admission, PSA), die Steuerungsebene und die Worker-Knoten sowie das Betriebssystem, auf dem die Knoteninstanzen ausgeführt werden. Weitere Informationen finden Sie unter Zugangscontroller für Pod-Sicherheit.

Variable	Kann festgelegt werden in…		Beschreibung
	Verwaltungscluster-YAML	Arbeitslastcluster-YAML
POD_SECURITY_STANDARD_AUDIT	✖	✔	Optional, standardmäßig restricted. Legt die Sicherheitsrichtlinie für den Modus audit des clusterweiten PSA-Controllers fest. Mögliche Werte: restricted, baseline und privileged.
POD_SECURITY_STANDARD_DEACTIVATED	✖	✔	Optional, standardmäßig false. Legen Sie diese Option auf true fest, um die clusterweite PSA zu deaktivieren.
POD_SECURITY_STANDARD_ENFORCE	✖	✔	Optional, standardmäßig kein Wert. Legt die Sicherheitsrichtlinie für den Modus enforce des clusterweiten PSA-Controllers fest. Mögliche Werte: restricted, baseline und privileged.
POD_SECURITY_STANDARD_WARN	✖	✔	Optional, standardmäßig restricted. Legt die Sicherheitsrichtlinie für den Modus warn des clusterweiten PSA-Controllers fest. Mögliche Werte: restricted, baseline und privileged.

Kubernetes-Optimierung (nur klassenbasierte Cluster)

Kubernetes-API-Server, Kubelets und andere Komponenten stellen verschiedene Konfigurations-Flags für die Optimierung zur Verfügung, z. B. das Flag --tls-cipher-suites zum Konfigurieren von Verschlüsselungs-Suites für die Sicherheitshärtung, das Flag --election-timeout, um die etcd-Zeitüberschreitung in einem großen Cluster zu erhöhen usw.

Wichtig

Diese Kubernetes-Konfigurationsvariablen sind für fortgeschrittene Benutzer vorgesehen. VMware übernimmt keine Garantie für die Funktionalität von Clustern, die mit beliebigen Kombinationen dieser Einstellungen konfiguriert wurden.

Variable	Kann festgelegt werden in…		Beschreibung
	Verwaltungscluster-YAML	Arbeitslastcluster-YAML
APISERVER_EXTRA_ARGS	✔	✔	Nur klassenbasierte Cluster. Geben Sie kube-apiserver-Flags im Format „key1=value1;key2=value2“ an. Legen Sie beispielsweise Verschlüsselungs-Suites mit APISERVER_EXTRA_ARGS: “tls-min-version=VersionTLS12;tls-cipher-suites=TLS_RSA_WITH_AES_256_GCM_SHA384” fest.
CONTROLPLANE_KUBELET_EXTRA_ARGS	✔	✔	Nur klassenbasierte Cluster. Geben Sie kubelet-Flags der Steuerungsebene im Format „key1=value1;key2=value2“ an. Begrenzen Sie die Anzahl der Pods der Steuerungsebene beispielsweise mit CONTROLPLANE_KUBELET_EXTRA_ARGS: “max-pods=50”
ETCD_EXTRA_ARGS	✔	✔	Nur klassenbasierte Cluster. Geben Sie etcd-Flags im Format „key1=value1;key2=value2“ an. Wenn der Cluster beispielsweise mehr als 500 Knoten aufweist oder die Leistung des Speichers schlecht ist, können Sie heartbeat-interval und election-timeout mit ETCD_EXTRA_ARGS: “heartbeat-interval=300;election-timeout=2000” erhöhen.
KUBE_CONTROLLER_MANAGER_EXTRA_ARGS	✔	✔	Nur klassenbasierte Cluster. Geben Sie kube-controller-manager-Flags im Format „key1=value1;key2=value2“ an. Deaktivieren Sie die Leistungsprofilerstellung beispielsweise mit KUBE_CONTROLLER_MANAGER_EXTRA_ARGS: “profiling=false”
KUBE_SCHEDULER_EXTRA_ARGS	✔	✔	Nur klassenbasierte Cluster. Geben Sie kube-scheduler-Flags im Format „key1=value1;key2=value2“ an. Aktivieren Sie beispielsweise den Zugriffsmodus für einzelne Pods mit KUBE_SCHEDULER_EXTRA_ARGS: “feature-gates=ReadWriteOncePod=true”
WORKER_KUBELET_EXTRA_ARGS	✔	✔	Nur klassenbasierte Cluster. Geben Sie Worker-kubelet-Flags im Format „key1=value1;key2=value2“ an. Begrenzen Sie die Anzahl der Worker-Pods mit WORKER_KUBELET_EXTRA_ARGS: “max-pods=50”

Automatische Clusterskalierung

Die folgenden zusätzlichen Variablen können konfiguriert werden, wenn ENABLE_AUTOSCALER auf true gesetzt ist. Weitere Informationen zur automatischen Clusterskalierung finden Sie unter Skalieren von Arbeitslastclustern.

Variable	Kann festgelegt werden in…		Beschreibung
	Verwaltungscluster-YAML	Arbeitslastcluster-YAML
AUTOSCALER_MAX_NODES_TOTAL	✖	✔	Optional; standardmäßig 0. Maximale Gesamtanzahl der Knoten im Cluster (Worker-Knoten plus Knoten der Steuerungsebene). Legt den Wert für den automatischen Clusterskalierungsparameter max-nodes-total fest. Die automatische Clusterskalierung versucht nicht, Ihren Cluster über seinen Grenzwert hinaus zu skalieren. Wenn als Wert 0 angegeben wurde, trifft die automatische Clusterskalierung Entscheidungen auf der Grundlage der von Ihnen konfigurierten Mindest- und Höchsteinstellungen für die SIZE.
AUTOSCALER_SCALE_DOWN_DELAY_AFTER_ADD	✖	✔	Optional; standardmäßig 10m. Legt den Wert für den automatischen Clusterskalierungsparameter scale-down-delay-after-add fest. Gibt an, wie lange die automatische Clusterskalierung nach einer vertikalen Hochskalierung wartet, bis die Prüfungen für die vertikale Herabskalierung fortgesetzt werden.
AUTOSCALER_SCALE_DOWN_DELAY_AFTER_DELETE	✖	✔	Optional; standardmäßig 10s. Legt den Wert für den automatischen Clusterskalierungsparameter scale-down-delay-after-delete fest. Gibt an, wie lange die automatische Clusterskalierung nach dem Löschen eines Knotens wartet, bis die Prüfungen für die vertikale Herabskalierung fortgesetzt werden.
AUTOSCALER_SCALE_DOWN_DELAY_AFTER_FAILURE	✖	✔	Optional; standardmäßig 3m. Legt den Wert für den automatischen Clusterskalierungsparameter scale-down-delay-after-failure fest. Gibt an, wie lange die automatische Clusterskalierung nach einer fehlgeschlagenen vertikalen Herabskalierung wartet, bis die Prüfungen für die vertikale Herabskalierung fortgesetzt werden.
AUTOSCALER_SCALE_DOWN_UNNEEDED_TIME	✖	✔	Optional; standardmäßig 10m. Legt den Wert für den automatischen Clusterskalierungsparameter scale-down-unneeded-time fest. Gibt an, wie lange die automatische Clusterskalierung warten muss, bis ein geeigneter Knoten herabskaliert wird.
AUTOSCALER_MAX_NODE_PROVISION_TIME	✖	✔	Optional; standardmäßig 15m. Legt den Wert für den automatischen Clusterskalierungsparameter max-node-provision-time fest. Gibt an, wie lange die automatische Clusterskalierung wartet, bis ein Knoten bereitgestellt wird.
AUTOSCALER_MIN_SIZE_0	✖	✔	Erforderlich, alle IaaS-Instanzen. Mindestanzahl der Worker-Knoten. Die automatische Clusterskalierung versucht nicht, die Knoten über diesen Grenzwert hinaus herabzuskalieren. Für prod-Cluster unter AWS legt AUTOSCALER_MIN_SIZE_0 die Mindestanzahl der Worker-Knoten in der ersten Verfügbarkeitszone fest. Wenn diese Variable nicht festgelegt wurde, wird der Standardwert WORKER_MACHINE_COUNT für Cluster mit einem einzigen Worker-Knoten bzw. WORKER_MACHINE_COUNT_0 für Cluster mit mehreren Worker-Knoten festgelegt.
AUTOSCALER_MAX_SIZE_0	✖	✔	Erforderlich, alle IaaS-Instanzen. Maximale Anzahl der Worker-Knoten. Die automatische Clusterskalierung versucht nicht, die Knoten über ihren Grenzwert hinaus vertikal hochzuskalieren. Für prod-Cluster unter AWS legt AUTOSCALER_MAX_SIZE_0 die Höchstzahl der Worker-Knoten in der ersten Verfügbarkeitszone fest. Wenn diese Variable nicht festgelegt wurde, wird der Standardwert WORKER_MACHINE_COUNT für Cluster mit einem einzigen Worker-Knoten bzw. WORKER_MACHINE_COUNT_0 für Cluster mit mehreren Worker-Knoten festgelegt.
AUTOSCALER_MIN_SIZE_1	✖	✔	Erforderlich, nur für prod-Cluster unter AWS verwenden. Die Mindestanzahl der Worker-Knoten im zweiten Verfügbarkeitsbereich. Die automatische Clusterskalierung versucht nicht, die Knoten über diesen Grenzwert hinaus herabzuskalieren. Wenn diese Variable nicht festgelegt wird, lautet der Standardwert WORKER_MACHINE_COUNT_1.
AUTOSCALER_MAX_SIZE_1	✖	✔	Erforderlich, nur für prod-Cluster unter AWS verwenden. Maximale Anzahl der Worker-Knoten im zweiten Verfügbarkeitsbereich. Die automatische Clusterskalierung versucht nicht, die Knoten über ihren Grenzwert hinaus vertikal hochzuskalieren. Wenn diese Variable nicht festgelegt wird, lautet der Standardwert WORKER_MACHINE_COUNT_1.
AUTOSCALER_MIN_SIZE_2	✖	✔	Erforderlich, nur für prod-Cluster unter AWS verwenden. Mindestanzahl der Worker-Knoten im dritten Verfügbarkeitsbereich. Die automatische Clusterskalierung versucht nicht, die Knoten über diesen Grenzwert hinaus herabzuskalieren. Wenn diese Variable nicht festgelegt wird, lautet der Standardwert WORKER_MACHINE_COUNT_2.
AUTOSCALER_MAX_SIZE_2	✖	✔	Erforderlich, nur für prod-Cluster unter AWS verwenden. Maximale Anzahl der Worker-Knoten im dritten Verfügbarkeitsbereich. Die automatische Clusterskalierung versucht nicht, die Knoten über ihren Grenzwert hinaus vertikal hochzuskalieren. Wenn diese Variable nicht festgelegt wird, lautet der Standardwert WORKER_MACHINE_COUNT_2.

Proxy-Konfiguration

Wenn Ihre Umgebung auf das Internet beschränkt ist oder anderweitig Proxys umfasst, können Sie Tanzu Kubernetes Grid optional so konfigurieren, dass ausgehender HTTP- und HTTPS-Datenverkehr von kubelet, containerd und der Steuerungsebene an Ihre Proxys gesendet wird.

Mit Tanzu Kubernetes Grid können Sie Proxys für Folgendes aktivieren:

• Sowohl für den Verwaltungscluster als auch für einen oder mehrere Arbeitslastcluster
• Nur für den Verwaltungscluster
• Für einen oder mehrere Arbeitslastcluster

Weitere Informationen finden Sie in Erstellen einer Konfigurationsdatei für den Verwaltungscluster unter Konfigurieren von Proxys.

Variable	Kann festgelegt werden in…		Beschreibung
	Verwaltungscluster-YAML	Arbeitslastcluster-YAML
TKG_HTTP_PROXY_ENABLED	✔	✔	Optional. Um ausgehenden HTTP(S)-Datenverkehr vom Verwaltungscluster an einen Proxy zu senden, z. B. in einer Umgebung mit Internetbeschränkungen, setzen Sie diese Variable auf true.
TKG_HTTP_PROXY	✔	✔	Optional. Legen Sie diese Variable fest, wenn Sie einen Proxy konfigurieren möchten. Setzen Sie sie auf "“, um die Proxy-Konfiguration für einen einzelnen Cluster zu deaktivieren. Nur anwendbar, wenn TKG_HTTP_PROXY_ENABLED = true. Die URL des HTTP-Proxys im folgenden Format: PROTOCOL://USERNAME:PASSWORD@FQDN-OR-IP:PORT. Dabei gilt: Erforderlich. PROTOCOL ist http. Optional. USERNAME und PASSWORD sind Benutzername und Ihr Kennwort für den HTTP-Proxy. Geben Sie diese mit an, wenn der Proxy eine Authentifizierung erfordert. Erforderlich. FQDN-OR-IP und PORT sind der FQDN bzw. die IP-Adresse und die Portnummer des HTTP-Proxys. Beispiel: http://user:[email protected]:1234 oder http://myproxy.com:1234. Wenn Sie TKG_HTTP_PROXY festlegen, müssen Sie TKG_HTTPS_PROXY ebenfalls festlegen.
TKG_HTTPS_PROXY	✔	✔	Optional. Legen Sie diese Variable fest, wenn Sie einen Proxy konfigurieren möchten. Nur anwendbar, wenn TKG_HTTP_PROXY_ENABLED = true. Die URL des HTTPS-Proxys. Sie können diese Variable auf denselben Wert festlegen wie TKG_HTTP_PROXY oder einen anderen Wert angeben. Die URL muss mit http:// beginnen. Wenn Sie TKG_HTTPS_PROXY festlegen, müssen Sie TKG_HTTP_PROXY ebenfalls festlegen.
TKG_NO_PROXY	✔	✔	Optional. Nur anwendbar, wenn TKG_HTTP_PROXY_ENABLED = true. Ein oder mehrere Netzwerk-CIDRs oder Hostnamen, die den HTTP(S)-Proxy umgehen müssen, sind durch Kommas getrennt und ohne Leerzeichen oder Platzhalterzeichen (*) aufgelistet. Listet die Hostnamensuffixe als .example.com und nicht als *.example.com auf. Beispiel: .noproxy.example.com,noproxy.example.com,192.168.0.0/24. Intern hängt Tanzu Kubernetes Grid localhost, 127.0.0.1, die Werte von CLUSTER_CIDR und SERVICE_CIDR, .svc und .svc.cluster.local an den Wert an, der in TKG_NO_PROXY festgelegt wurde. Azure VNET CIDR, 169.254.0.0/16 und 168.63.129.16 werden auch für Bereitstellungen in Azure angehängt. Für vSphere müssen Sie das CIDR von VSPHERE_NETWORK, das die IP-Adresse Ihres Steuerungsebenen-Endpoints enthält, manuell zu TKG_NO_PROXY hinzufügen. Wenn Sie VSPHERE_CONTROL_PLANE_ENDPOINT auf einen FQDN festlegen, fügen Sie sowohl den FQDN als auch VSPHERE_NETWORK zu TKG_NO_PROXY hinzu. Wichtiger Hinweis: In Umgebungen, in denen Tanzu Kubernetes Grid hinter einem Proxy ausgeführt wird, ermöglicht TKG_NO_PROXY den VMs im Cluster die direkte Kommunikation mit der Infrastruktur, die dasselbe Netzwerk ausführt, hinter demselben Proxy. Dazu gehören unter anderem Ihre Infrastruktur, OIDC- oder LDAP-Server, Harbor, VMware NSX und NSX Advanced Load Balancer (vSphere). Legen Sie TKG_NO_PROXY fest, um alle Endpoints einzubeziehen, auf die Cluster zugreifen müssen, die aber für Ihre Proxys nicht erreichbar sind.
TKG_PROXY_CA_CERT	✔	✔	Optional. Legen Sie fest, ob Ihr Proxyserver ein selbstsigniertes Zertifikat verwendet. Geben Sie das CA-Zertifikat im base64-codierten Format an, z. B. …TKG_PROXY_CA_CERT: “LS0t[]tLS0tLQ==””.
TKG_NODE_SYSTEM_WIDE_PROXY	✔	✔	(Tech Preview) Optional. Übernimmt die folgenden Einstellungen in /etc/environment und /etc/profile: export HTTP_PROXY=$TKG_HTTP_PROXY export HTTPS_PROXY=$TKG_HTTPS_PROXY export NO_PROXY=$TKG_NO_PROXY Wenn Benutzer per SSH eine Verbindung zum TKG-Knoten herstellen und Befehle ausführen, werden in den Befehlen standardmäßig die definierten Variablen verwendet. Systemd-Prozesse sind davon nicht betroffen.

Antrea-CNI-Konfiguration

Optionale zusätzliche Variablen, um anzugeben, ob als CNI antrea festgelegt ist. Weitere Informationen finden Sie in Erstellen einer Konfigurationsdatei für den Verwaltungscluster unter Konfigurieren von Antrea als CNI.

Variable	Kann festgelegt werden in…		Beschreibung
	Verwaltungscluster-YAML	Arbeitslastcluster-YAML
ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD	✔	✔	Optional; standardmäßig false. Setzen Sie diese Variable auf true, um die Auslagerung der UDP-Prüfsumme von Antrea zu deaktivieren. Wenn Sie diese Variable auf true setzen, werden bekannte Probleme mit Underlay-Netzwerk- und physischen Netzwerkkartentreibern vermieden.
ANTREA_EGRESS	✔	✔	Optional; standardmäßig true. Aktivieren Sie diese Variable, um die SNAT-IP zu definieren, die für den ausgehenden Pod-Datenverkehr im Cluster verwendet wird. Weitere Informationen finden Sie in der Antrea-Dokumentation unter Egress.
ANTREA_EGRESS_EXCEPT_CIDRS	✔	✔	Optional. Die CIDR-Bereiche, deren Egresse keine Quellen-Netzwerkadressübersetzung (SNAT) für ausgehenden Pod-Datenverkehr aufweisen. Geben Sie die Anführungszeichen (““) mit an. Beispiel: “10.0.0.0/6”.
ANTREA_ENABLE_USAGE_REPORTING	✔	✔	Optional; standardmäßig false. Aktiviert bzw. deaktiviert Nutzungsberichte (Telemetrie).
ANTREA_FLOWEXPORTER	✔	✔	Optional; standardmäßig false. Setzen Sie diese Variable auf true, um den Netzwerk-Flow sichtbar zu machen. Die Flow-Exportfunktion fragt die Conntrack-Flows regelmäßig ab und exportiert die Flows als IPFIX-Flow-Datensätze. Weitere Informationen finden Sie in der Antrea-Dokumentation unter Sichtbarkeit des Netzwerkflusses in Antrea in der Antrea-Dokumentation.
ANTREA_FLOWEXPORTER_ACTIVE_TIMEOUT	✔	✔	Optional; standardmäßig “60s”. Diese Variable gibt das Zeitlimit für den aktiven Flow-Export an, d. h. wann eine Zeitüberschreitung eintritt und ein Flow-Datensatz für aktive Flows an den Collector gesendet wird. Geben Sie die Anführungszeichen (””) mit an. Hinweis: Die gültigen Zeiteinheiten lauten ns, us (oder s), ms, s, m, h.
ANTREA_FLOWEXPORTER_COLLECTOR_ADDRESS	✔	✔	Optional. Diese Variable gibt die IPFIX-Collector-Adresse an. Geben Sie die Anführungszeichen (““) mit an. Der Standardwert ist “flow-aggregator.flow-aggregator.svc:4739:tls”. Weitere Informationen finden Sie in der Antrea-Dokumentation unter Sichtbarkeit des Netzwerkflusses in Antrea in der Antrea-Dokumentation.
ANTREA_FLOWEXPORTER_IDLE_TIMEOUT	✔	✔	Optional; standardmäßig “15s”. Diese Variable gibt das Zeitlimit für den inaktiven Flow-Export an, d. h. wann eine Zeitüberschreitung eintritt und ein Flow-Datensatz für inaktive Flows an den Collector gesendet wird. Geben Sie die Anführungszeichen (””) mit an. Hinweis: Die gültigen Zeiteinheiten lauten ns, us (oder s), ms, s, m, h.
ANTREA_FLOWEXPORTER_POLL_INTERVAL	✔	✔	Optional; standardmäßig “5s”. Diese Variable legt die Häufigkeit der gesicherten Verbindungen aus dem Conntrack-Modul durch den Flow-Exporter fest. Geben Sie die Anführungszeichen (““) mit an. Hinweis: Die gültigen Zeiteinheiten lauten ns, us (oder s), ms, s, m, h.
ANTREA_IPAM	✔	✔	Optional; standardmäßig false. Setzen Sie diese Variable auf true, um IP-Adressen aus IPPools zuzuteilen. Der gewünschte Satz von IP-Bereichen, optional bei VLANs, wird mit der CRD IPPool definiert. Weitere Informationen finden Sie in der Antrea-Dokumentation unter Antrea-IPAM-Funktionen.
ANTREA_KUBE_APISERVER_OVERRIDE	✔	✔	Optional. Geben Sie die Adresse des Kubernetes-API-Servers an. Weitere Informationen finden Sie in der Antrea-Dokumentation unter Entfernen von kube-proxy.
ANTREA_MULTICAST	✔	✔	Optional; standardmäßig false. Setzen Sie diese Variable auf true, um Multicast-Datenverkehr innerhalb des Clusternetzwerks (zwischen Pods) und zwischen dem externen Netzwerk und dem Clusternetzwerk zu ermöglichen.
ANTREA_MULTICAST_INTERFACES	✔	✔	Optional. Die Namen der Schnittstelle auf Knoten, die zur Weiterleitung von Multicast-Datenverkehr verwendet werden. Geben Sie die Anführungszeichen (””) mit an. Beispiel: “eth0”.
ANTREA_NETWORKPOLICY_STATS	✔	✔	Optional; standardmäßig true. Aktivieren Sie diese Variable, um NetworkPolicy-Statistiken zu erfassen. Die statistischen Daten enthalten die Gesamtzahl der Sitzungen, Pakete und Bytes, die von einer NetworkPolicy zugelassen oder verweigert werden.
ANTREA_NO_SNAT	✔	✔	Optional; standardmäßig false. Setzen Sie diese Variable auf true, um die Quell-Netzwerkadressübersetzung (Source Network Address Translation, SNAT) zu deaktivieren.
ANTREA_NODEPORTLOCAL	✔	✔	Optional; standardmäßig true. Setzen Sie diese Variable auf false, um den NodePortLocal-Modus zu deaktivieren. Weitere Informationen finden Sie in der Antrea-Dokumentation unter NodePortLocal (NPL).
ANTREA_NODEPORTLOCAL_ENABLED	✔	✔	Optional. Setzen Sie diese Variable auf true, um den NodePortLocal-Modus zu aktivieren, wie in der Antrea-Dokumentation unter NodePortLocal (NPL) beschrieben.
ANTREA_NODEPORTLOCAL_PORTRANGE	✔	✔	Optional; standardmäßig 61000-62000. Weitere Informationen finden Sie in der Antrea-Dokumentation unter NodePortLocal (NPL).
ANTREA_POLICY	✔	✔	Optional; standardmäßig true. Aktiviert bzw. deaktiviert die Antrea-native Richtlinien-API, bei der es sich um Antrea-spezifische Richtlinien-CRDs handelt. Darüber hinaus bleibt die Implementierung von Kubernetes-Netzwerkrichtlinien aktiv, wenn diese Variable aktiviert ist. Informationen zur Verwendung von Netzwerkrichtlinien finden Sie in der Antrea-Dokumentation unter Antrea-Netzwerkrichtlinien-CRDs.
ANTREA_PROXY	✔	✔	Optional; standardmäßig false. Aktiviert bzw. deaktiviert AntreaProxy, um kube-proxy für den Pod-zu-ClusterIP-Dienstdatenverkehr zu ersetzen. Dies verbessert die Leistung und verringert die Latenz. Beachten Sie, dass kube-proxy weiterhin für andere Arten von Dienstdatenverkehr verwendet wird. Weitere Informationen zur Verwendung von Proxys finden Sie in der Antrea-Dokumentation unter AntreaProxy.
ANTREA_PROXY_ALL	✔	✔	Optional; standardmäßig false. Aktiviert bzw. deaktiviert AntreaProxy, um den gesamten Dienstdatenverkehr einschließlich NodePort-, LoadBalancer- und ClusterIP-Datenverkehr zu verarbeiten. Um kube-proxy durch AntreaProxy zu ersetzen, muss ANTREA_PROXY_ALL aktiviert sein. Weitere Informationen zur Verwendung von Proxys finden Sie in der Antrea-Dokumentation unter AntreaProxy.
ANTREA_PROXY_LOAD_BALANCER_IPS	✔	✔	Optional; standardmäßig true. Setzen Sie diese Variable auf false, um den Datenverkehr für den Lastausgleich an den externen Lastausgleichsdienst weiterzuleiten.
ANTREA_PROXY_NODEPORT_ADDRS	✔	✔	Optional. Die IPv4- oder IPv6-Adresse für NodePort. Geben Sie die Anführungszeichen (““) mit an.
ANTREA_PROXY_SKIP_SERVICES	✔	✔	Optional. Ein Array von Zeichenfolgenwerten, mit denen eine Liste der Dienste angegeben werden kann, die AntreaProxy ignorieren soll. Für den Datenverkehr zu diesen Diensten wird kein Lastausgleich durchgeführt. Geben Sie die Anführungszeichen (””) mit an. Gültige Werte sind beispielsweise eine gültige ClusterIP (z. B. 10.11.1.2) oder ein Dienstname mit einem Namespace (z. B. kube-system/kube-dns). Weitere Informationen finden Sie in der Antrea-Dokumentation unter Besondere Anwendungsfälle.
ANTREA_SERVICE_EXTERNALIP	✔	✔	Optional; standardmäßig false. Setzen Sie diese Variable auf true, damit ein Controller externe IPs aus einer ExternalIPPool-Ressource für Dienste des Typs LoadBalancer zuteilt. Weitere Informationen zum Implementieren von Diensten des Tys LoadBalancer finden Sie in der Antrea-Dokumentation unter Dienst vom Typ „LoadBalancer“.
ANTREA_TRACEFLOW	✔	✔	Optional; standardmäßig true. Informationen zur Verwendung von Traceflow finden Sie in der Antrea-Dokumentation im Traceflow-Benutzerhandbuch.
ANTREA_TRAFFIC_ENCAP_MODE	✔	✔	Optional; standardmäßig “encap”. Legen Sie als Einstellung noEncap, hybrid oder NetworkPolicyOnly fest. Informationen zur Verwendung der Datenverkehrsmodi NoEncap und Hybrid finden Sie in der Antrea-Dokumentation unter NoEncap- und Hybrid-Datenverkehrsmodi von Antrea. Hinweis: Für die Modi noEncap und hybrid ist eine spezielle Konfiguration des Knotennetzwerks erforderlich, um zu verhindern, dass sie die Pod-Kommunikation zwischen Knoten deaktivieren. Der noEncap-Modus wird nur unter vSphere unterstützt und kann die Pod-Kommunikation zwischen Knoten deaktivieren. Legen Sie für ANTREA_TRAFFIC_ENCAP_MODE in Clustern, in denen Pods knotenübergreifend kommunizieren müssen, nicht die Einstellung noEncap fest.
ANTREA_TRANSPORT_INTERFACE	✔	✔	Optional. Der Name der Schnittstelle auf dem Knoten, der für das Tunneling oder Routing des Datenverkehrs verwendet wird. Geben Sie die Anführungszeichen (““) mit an. Beispiel: “eth0”.
ANTREA_TRANSPORT_INTERFACE_CIDRS	✔	✔	Optional. Die Netzwerk-CIDRs der Schnittstelle auf dem Knoten, die für das Tunneling oder Routing des Datenverkehrs verwendet wird. Geben Sie die Anführungszeichen (””) mit an. Beispiel: “10.0.0.2/24”.

Maschinenintegritätsprüfungen

Wenn Sie Maschinenintegritätsprüfungen für Verwaltungs- und Arbeitslastcluster konfigurieren möchten, legen Sie die folgenden Variablen fest. Weitere Informationen finden Sie in Erstellen einer Konfigurationsdatei für den Verwaltungscluster unter Konfigurieren von Maschinenintegritätsprüfungen. Informationen zur Durchführung von Vorgängen zur Maschinenintegritätsprüfung nach der Clusterbereitstellung finden Sie unter Konfigurieren von Maschinenintegritätsprüfungen für Arbeitslastcluster.

Variable	Kann festgelegt werden in…		Beschreibung
	Verwaltungscluster-YAML	Arbeitslastcluster-YAML
ENABLE_MHC	✔	klassenbasiert: ✖ planbasiert: ✔	Optional. Setzen Sie diese Variable auf true oder false, um den MachineHealthCheck-Controller sowohl für Knoten der Steuerungsebene als auch für Worker-Knoten des Zielverwaltungs- oder -arbeitslastclusters zu aktivieren bzw. zu deaktivieren. Stattdessen können Sie das Feld auch leer lassen und ENABLE_MHC_CONTROL_PLANE und ENABLE_MHC_WORKER_NODE für Knoten der Steuerungsebene und Worker-Knoten getrennt festlegen. Standardmäßig wird das Feld leer gelassen. Der Controller ermöglicht die Maschinenintegritätsüberwachung und automatische Reparatur. Legen Sie für Arbeitslastcluster, die von vSphere with Tanzu erstellt wurden, die Variable auf false fest.
ENABLE_MHC_CONTROL_PLANE	✔		Optional; standardmäßig true. Weitere Informationen finden Sie in der Tabelle unten.
ENABLE_MHC_WORKER_NODE	✔		Optional; standardmäßig true. Weitere Informationen finden Sie in der Tabelle unten.
MHC_MAX_UNHEALTHY_CONTROL_PLANE	✔	✖	Optional, nur klassenbasierte Cluster. 100% ist die Standardeinstellung. Wenn die Anzahl der fehlerhaften Maschinen den von Ihnen festgelegten Wert überschreitet, führt der Controller MachineHealthCheck keine Standardisierung durch.
MHC_MAX_UNHEALTHY_WORKER_NODE	✔	✖	Optional, nur klassenbasierte Cluster. 100% ist die Standardeinstellung. Wenn die Anzahl der fehlerhaften Maschinen den von Ihnen festgelegten Wert überschreitet, führt der Controller MachineHealthCheck keine Standardisierung durch.
MHC_FALSE_STATUS_TIMEOUT	✔	klassenbasiert: ✖ planbasiert: ✔	Optional; standardmäßig 12m. Gibt an, wie lange der MachineHealthCheck-Controller zulässt, dass die Ready-Bedingung eines Knotens False bleibt, bevor die Maschine als fehlerhaft betrachtet wird und neu erstellt wird.
MHC_UNKNOWN_STATUS_TIMEOUT	✔		Optional; standardmäßig 5m. Gibt an, wie lange der MachineHealthCheck-Controller zulässt, dass die Ready-Bedingung eines Knotens Unknown bleibt, bevor die Maschine als fehlerhaft betrachtet wird und neu erstellt wird.
NODE_STARTUP_TIMEOUT	✔		Optional; standardmäßig 20m. Gibt an, wie lange der Controller MachineHealthCheck auf den Beitritt eines Knotens zu einem Cluster wartet, bevor die Maschine als fehlerhaft betrachtet wird und neu erstellt wird.

Anhand der folgenden Tabelle können Sie feststellen, wie die Variablen ENABLE_MHC, ENABLE_MHC_CONTROL_PLANE und ENABLE_MHC_WORKER_NODE zu konfigurieren sind.

Wert von ENABLE_MHC	Wert von ENABLE_MHC_CONTROL_PLANE	Wert von ENABLE_MHC_WORKER_NODE	Wartung der Steuerungsebene aktiviert?	Wartung von Worker-Knoten aktiviert?
true / Emptytrue / Emptytrue / Empty	true / false / leer	true / false / leer	Ja	Ja
false	true / leer	true / leer	Ja	Ja
false	true / leer	false	Ja	Nein
false	false	true / leer	Nein	Ja

Konfiguration von privaten Image-Registrierungen

Wenn Sie Tanzu Kubernetes Grid-Verwaltungscluster und Kubernetes-Cluster in Umgebungen bereitstellen, die nicht mit dem Internet verbunden sind, müssen Sie ein privates Image-Repository innerhalb Ihrer Firewall einrichten und mit den Tanzu Kubernetes Grid-Images auffüllen. Informationen zum Einrichten eines privaten Image-Repositorys finden Sie unter Vorbereiten einer Umgebung mit Internetbeschränkungen.

Variable	Kann festgelegt werden in…		Beschreibung
	Verwaltungscluster-YAML	Arbeitslastcluster-YAML
ADDITIONAL_IMAGE_REGISTRY_1, ADDITIONAL_IMAGE_REGISTRY_2, ADDITIONAL_IMAGE_REGISTRY_3	✔	✔	Nur klassenbasierte Arbeitslastcluster und eigenständige Verwaltungscluster. Die IP-Adressen oder FQDNs von bis zu drei vertrauenswürdigen privaten Registrierungen zusätzlich zu der von TKG_CUSTOM_IMAGE_REPOSITORY festgelegten primären Image-Registrierung, auf die Arbeitslastclusterknoten zugreifen können. Weitere Informationen finden Sie unter Vertrauenswürdige Registrierungen für einen klassenbasierten Cluster.
ADDITIONAL_IMAGE_REGISTRY_1_CA_CERTIFICATE, ADDITIONAL_IMAGE_REGISTRY_2_CA_CERTIFICATE, ADDITIONAL_IMAGE_REGISTRY_3_CA_CERTIFICATE	✔	✔	Nur klassenbasierte Arbeitslastcluster und eigenständige Verwaltungscluster. Mit Base64 codierte CA-Zertifikate privater Image-Registrierungen, die mit ADDITIONAL_IMAGE_REGISTRY- oben konfiguriert sind. Beispiel: …ADDITIONAL_IMAGE_REGISTRY_1_CA_CERTIFICATE: “LS0t[]tLS0tLQ==”..
ADDITIONAL_IMAGE_REGISTRY_1_SKIP_TLS_VERIFY, ADDITIONAL_IMAGE_REGISTRY_2_SKIP_TLS_VERIFY, ADDITIONAL_IMAGE_REGISTRY_3_SKIP_TLS_VERIFY	✔	✔	Nur klassenbasierte Arbeitslastcluster und eigenständige Verwaltungscluster. Legen Sie den Wert für alle privaten Image-Registrierungen auf true fest, die oben mit registriert sind und ein selbstsigniertes Zertifikat verwenden, nicht aber ADDITIONAL_IMAGE_REGISTRY_CA_CERTIFICATE. ADDITIONAL_IMAGE_REGISTRYDa der Tanzu-Konnektivitäts-Webhook das Harbor-CA-Zertifikat in Clusterknoten injiziert, sollte _SKIP_TLS_VERIFY should always be set to false festgelegt werden.
TKG_CUSTOM_IMAGE_REPOSITORY	✔	✔	Erforderlich, wenn Sie Tanzu Kubernetes Grid in einer Umgebung mit Internetbeschränkungen bereitstellen. Geben Sie die IP-Adresse oder den FQDN der privaten Registrierung mit TKG-System-Images an, für die Cluster ein Bootstrap ausführen. Dies wird im Folgenden als primäre Image-Registrierung bezeichnet. Beispiel: custom-image-repository.io/yourproject.
TKG_CUSTOM_IMAGE_REPOSITORY_SKIP_TLS_VERIFY	✔	✔	Optional. Legen Sie diese Variable auf true fest, wenn Ihre private primäre Image-Registrierung ein selbstsigniertes Zertifikat verwendet und Sie TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE nicht verwenden. Da der Tanzu-Konnektivitäts-Webhook das Harbor-CA-Zertifikat in Clusterknoten injiziert, sollte TKG_CUSTOM_IMAGE_REPOSITORY_SKIP_TLS_VERIFY bei Verwendung von Harbor immer auf false gesetzt werden.
TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE	✔	✔	Optional. Legen Sie fest, ob die private primäre Image-Registrierung ein selbstsigniertes Zertifikat verwendet. Geben Sie das CA-Zertifikat im base64-codierten Format an, z. B. …TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE: “LS0t[]tLS0tLQ==”.

vSphere

Die Optionen in der folgenden Tabelle sind die Mindestoptionen, die Sie in der Clusterkonfigurationsdatei angeben, wenn Sie Arbeitslastcluster unter vSphere bereitstellen. Die meisten dieser Optionen sind für den Arbeitslastcluster und für den zu dessen Bereitstellung verwendeten Verwaltungscluster identisch.

Weitere Informationen zu den Konfigurationsdateien für vSphere finden Sie unter Konfiguration eines Verwaltungsclusters für vSphere and Bereitstellen von Arbeitslastclustern unter vSphere.

Variable	Kann festgelegt werden in…		Beschreibung
	Verwaltungscluster-YAML	Arbeitslastcluster-YAML
DEPLOY_TKG_ON_VSPHERE7	✔	✔	Optional. Wenn Sie die Bereitstellung unter vSphere 7 oder 8 vornehmen, legen Sie diese Option auf true fest, um die Eingabeaufforderung zur Bereitstellung unter vSphere 7 oder 8 zu überspringen, oder auf false. Weitere Informationen finden Sie unter Verwaltungscluster in vSphere with Tanzu.
ENABLE_TKGS_ON_VSPHERE7	✔	✔	Optional können Sie bei der Bereitstellung unter vSphere 7 oder 8 die Einstellung true wählen, um zur Seite der Benutzeroberfläche für die Aktivierung von vSphere with Tanzu umgeleitet zu werden, oder die Einstellung false. Weitere Informationen finden Sie unter Verwaltungscluster in vSphere with Tanzu.
NTP_SERVERS	✔	✔	Nur klassenbasierte Cluster. Konfiguriert den NTP-Server des Clusters, wenn Sie Cluster in einer vSphere-Umgebung ohne DHCP-Option 42 bereitstellen, z. B. NTP_SERVERS: time.google.com. Um dies in einem planbasierten Legacy-Cluster zu konfigurieren, verwenden Sie ein ytt-Overlay, wie unter Konfigurieren von NTP ohne DHCP-Option 42 (vSphere) beschrieben.
TKG_IP_FAMILY	✔	✔	Optional. Um einen Cluster unter vSphere 7 oder 8 mit reinem IPv6 bereitzustellen, legen Sie für diese Variable die Einstellung ipv6 fest. Informationen zu Dual-Stack-Netzwerken (experimentell) finden Sie unter Dual-Stack-Cluster.
VIP_NETWORK_INTERFACE	✔	✔	Optional. Setzen Sie diese Variable auf eth0, eth1 usw. als Name der Netzwerkschnittstelle, z. B. einer Ethernet-Schnittstelle. eth0 ist die Standardeinstellung.
VSPHERE_AZ_CONTROL_PLANE_MATCHING_LABELS	✔	✔	Legt für Cluster, die in mehreren AZs bereitgestellt werden, Schlüssel/Wert-Selektorbezeichnungen zur Angabe von AZs fest, in denen Knoten der Cluster-Steuerungsebene bereitgestellt werden können. Auf diese Weise können Sie die Knoten beispielsweise so konfigurieren, dass sie in allen AZs in einer bestimmten Region und Umgebung ausgeführt werden, ohne die AZs einzeln aufzulisten: “region=us-west-1,environment=staging”. Weitere Informationen finden Sie unter Ausführen von Clustern über mehrere Verfügbarkeitszonen hinweg
VSPHERE_AZ_0, VSPHERE_AZ_1, VSPHERE_AZ_2	✔	✔	Optional. Die Bereitstellungszonen, in denen Maschinenbereitstellungen in einem Cluster bereitgestellt werden. Weitere Informationen finden Sie unter Ausführen von Clustern über mehrere Verfügbarkeitszonen hinweg
VSPHERE_CONTROL_PLANE_DISK_GIB	✔	✔	Optional. Die Größe der Festplatte für die Knoten-VMs der Steuerungsebene in Gigabyte. Geben Sie die Anführungszeichen (““) mit an. Beispiel: "30".
VSPHERE_CONTROL_PLANE_ENDPOINT	✔	✔	Für Kube-VIP erforderlich. Statische virtuelle IP-Adresse oder vollqualifizierter Domänenname (FQDN), der der statischen Adresse zugeordnet ist, für API-Anforderungen an den Cluster. Diese Einstellung ist erforderlich, wenn Sie Kube-Vip für Ihren API-Server-Endpoint verwenden, wie durch die Einstellung von AVI_CONTROL_PLANE_HA_PROVIDER auf false . Wenn Sie NSX Advanced Load Balancer verwenden, AVI_CONTROL_PLANE_HA_PROVIDER: true, haben Sie folgende Möglichkeiten: Lassen Sie dieses Feld leer, wenn Sie keine bestimmte Adresse als Endpoint der Steuerungsebene benötigen. Legen Sie in diesem Feld eine bestimmte Adresse innerhalb des VIP-Netzwerkbereichs des IPAM-Profils fest und fügen Sie die Adresse manuell zum statischen IP-Pool hinzu. Legen Sie für dieses Feld einen FQDN fest.
VSPHERE_CONTROL_PLANE_ENDPOINT_PORT	✔	✔	Optional können Sie festlegen, wenn Sie den Kubernetes-API-Serverport für Bereitstellungen unter vSphere mit NSX Advanced Load Balancer außer Kraft setzen möchten. Der Standardport ist 6443. Um den Kubernetes-API-Serverport für Bereitstellungen unter vSphere ohne NSX Advanced Load Balancer außer Kraft zu setzen, legen Sie CLUSTER_API_SERVER_PORT fest.
VSPHERE_CONTROL_PLANE_MEM_MIB	✔	✔	Optional. Die Größe des Arbeitsspeichers für die Knoten-VMs der Steuerungsebene in Megabyte. Geben Sie die Anführungszeichen (””) mit an. Beispiel: "2048".
VSPHERE_CONTROL_PLANE_NUM_CPUS	✔	✔	Optional. Die Anzahl der CPUs für die Knoten-VMs der Steuerungsebene. Geben Sie die Anführungszeichen (““) mit an. Muss mindestens 2 sein. Beispiel: "2".
VSPHERE_DATACENTER	✔	✔	Erforderlich. Der Name des Datencenters, in dem der Cluster bereitgestellt werden soll, wie in der vSphere-Bestandsliste angegeben. Beispiel: /MY-DATACENTER.
VSPHERE_DATASTORE	✔	✔	Erforderlich. Der Name des vSphere-Datenspeichers, der vom Cluster verwendet werden soll, wie in der vSphere-Bestandsliste angegeben. Beispiel: /MY-DATACENTER/datastore/MyDatastore.
VSPHERE_FOLDER	✔	✔	Erforderlich. Der Name eines vorhandenen VM-Ordners, in dem Tanzu Kubernetes Grid-VMs platziert werden sollen, wie in der vSphere-Bestandsliste angegeben. Wenn Sie beispielsweise einen Ordner mit dem Namen TKG erstellt haben, lautet der Pfad /MY-DATACENTER/vm/TKG.
VSPHERE_INSECURE	✔	✔	Optional. Setzen Sie diese Variable auf true, um die Fingerabdrucküberprüfung zu umgehen. Legen Sie im Falle von „false“ VSPHERE_TLS_THUMBPRINT fest.
VSPHERE_MTU	✔	✔	Optional. Legt die Größe der maximalen Übertragungseinheit (MTU) für Verwaltungs- und Arbeitslastcluster-Knoten auf einem vSphere Standard Switch fest. Falls nicht festgelegt, ist der Standardwert 1500. Der Maximalwert ist 9000. Weitere Informationen finden Sie unter Konfigurieren der Clusterknoten-MTU.
VSPHERE_NETWORK	✔	✔	Erforderlich. Der Name eines vorhandenen vSphere-Netzwerks, das als Kubernetes-Dienstnetzwerk verwendet werden soll, wie in der vSphere-Bestandsliste angegeben. Beispiel: VM Network.
VSPHERE_PASSWORD	✔	✔	Erforderlich. Das Kennwort für das vSphere-Benutzerkonto. Dieser Wert ist base64-codiert, wenn Sie tanzu cluster create ausführen.
VSPHERE_REGION	✔	✔	Optional. Tag für Region in vCenter, Verwendung: Zuweisen von CSI-Speicher in einer Umgebung mit mehreren Datencentern oder Hostclustern. Siehe Bereitstellen eines Clusters mit Regions- und Zonen-Tags für CSI Definieren von Regionen für Cluster mit mehreren Verfügbarkeitszonen. Siehe Ausführen von Clustern über mehrere Verfügbarkeitszonen hinweg
VSPHERE_RESOURCE_POOL	✔	✔	Erforderlich. Der Name eines vorhandenen Ressourcenpools, in dem diese Tanzu Kubernetes Grid-Instanz platziert werden soll, wie in der vSphere-Bestandsliste angegeben. Um den Root-Ressourcenpool für einen Cluster zu verwenden, geben Sie den vollständigen Pfad ein. Beispielsweise lautet der vollständige Pfad für einen Cluster mit dem Namen cluster0 im Datencenter MY-DATACENTER: /MY-DATACENTER/host/cluster0/Resources.
VSPHERE_SERVER	✔	✔	Erforderlich. Die IP-Adresse oder der FQDN der vCenter Server-Instanz, auf der Sie die Arbeitslastcluster bereitstellen möchten.
VSPHERE_SSH_AUTHORIZED_KEY	✔	✔	Erforderlich. Fügen Sie den Inhalt des öffentlichen SSH-Schlüssels ein, den Sie im Schritt Bereitstellen eines Verwaltungsclusters in vSphere erstellt haben. Beispiel: …"ssh-rsa NzaC1yc2EA [] hnng2OYYSl+8ZyNz3fmRGX8uPYqw== [email protected]".
VSPHERE_STORAGE_POLICY_ID	✔	✔	Optional. Der Name einer VM-Speicherrichtlinie für den Verwaltungscluster, wie in Richtlinien und Profile (Policies and Profiles) > VM-Speicherrichtlinien (VM Storage Policies) angegeben. Wenn VSPHERE_DATASTORE festgelegt ist, muss dieser Datenspeicher in der Speicherrichtlinie enthalten sein. Andernfalls wählt der Clustererstellungsprozess einen Datenspeicher aus, der mit der Richtlinie kompatibel ist.
VSPHERE_TEMPLATE	✖	✔	Optional. Geben Sie den Pfad zu einer OVA-Datei im Format /MY-DC/vm/MY-FOLDER-PATH/MY-IMAGE an, wenn Sie mehrere benutzerdefinierte OVA-Images für dieselbe Kubernetes-Version verwenden. Weitere Informationen finden Sie unter Bereitstellen eines Clusters mit einem benutzerdefinierten OVA-Image.
VSPHERE_TLS_THUMBPRINT	✔	✔	Erforderlich, wenn für VSPHERE_INSECURE die Einstellung false gewählt wurde. Der Fingerabdruck des vCenter Server-Zertifikats. Informationen zum Abrufen des Fingerabdrucks des vCenter Server-Zertifikats finden Sie unter Abrufen von Fingerabdrücken des vSphere-Zertifikats. Dieser Wert kann ausgelassen werden, wenn der Benutzer eine unsichere Verbindung verwenden möchte. Hierzu wird VSPHERE_INSECURE auf true gesetzt.
VSPHERE_USERNAME	✔	✔	Erforderlich. Ein vSphere-Benutzerkonto, einschließlich des Domänennamens, mit den erforderlichen Berechtigungen für Tanzu Kubernetes Grid-Vorgänge. Beispiel: [email protected].
VSPHERE_WORKER_DISK_GIB	✔	✔	Optional. Die Größe der Festplatte für die Worker-Knoten-VMs in Gigabyte. Geben Sie die Anführungszeichen (””) mit an. Beispiel: "50".
VSPHERE_WORKER_MEM_MIB	✔	✔	Optional. Die Größe des Arbeitsspeichers für die Worker-Knoten-VMs in Megabyte. Geben Sie die Anführungszeichen (““) mit an. Beispiel: "4096".
VSPHERE_WORKER_NUM_CPUS	✔	✔	Optional. Die Anzahl der CPUs für die Worker-Knoten-VMs. Geben Sie die Anführungszeichen (””) mit an. Muss mindestens 2 sein. Beispiel: "2".
VSPHERE_ZONE	✔	✔	Optional. Tag für Zone in vCenter, Verwendung: Zuweisen von CSI-Speicher in einer Umgebung mit mehreren Datencentern oder Hostclustern. Siehe Bereitstellen eines Clusters mit Regions- und Zonen-Tags für CSI Definieren von Zonen für Cluster mit mehreren Verfügbarkeitszonen. Siehe Ausführen von Clustern über mehrere Verfügbarkeitszonen hinweg

Kube-VIP-Lastausgleichsdienst (Tech Preview)

Informationen zum Konfigurieren von Kube-VIP als L4-Lastausgleichsdienst finden Sie unter Kube-VIP-Lastausgleichsdienst.

Variable	Kann festgelegt werden in…		Beschreibung
	Verwaltungscluster-YAML	Arbeitslastcluster-YAML
KUBEVIP_LOADBALANCER_ENABLE	✖	✔	Optional; standardmäßig false. Setzen Sie die Variable auf true oder false. Aktiviert Kube-VIP als Lastausgleichsdienst für Arbeitslasten. Wenn true müssen Sie eine der folgenden Variablen festlegen.
KUBEVIP_LOADBALANCER_IP_RANGES	✖	✔	Eine Liste nicht überlappender IP-Bereiche zur Zuteilung der IP für den Diensttyp LoadBalancer. Beispiel: 10.0.0.1-10.0.0.23,10.0.2.1-10.0.2.24.
KUBEVIP_LOADBALANCER_CIDRS	✖	✔	Eine Liste nicht überlappender CIDRs zur Zuteilung der IP für den Diensttyp LoadBalancer. Beispiel: 10.0.0.0/24,10.0.2/24. Setzt die Einstellung für KUBEVIP_LOADBALANCER_IP_RANGES außer Kraft.

NSX Advanced Load Balancer

Informationen zum Bereitstellen von NSX Advanced Load Balancer finden Sie unter Installieren von NSX Advanced Load Balancer.

Variable	Kann festgelegt werden in…		Beschreibung
	Verwaltungscluster-YAML	Arbeitslastcluster-YAML
AVI_ENABLE	✔	✖	Optional; standardmäßig false. Setzen Sie die Variable auf true oder false. Aktiviert NSX Advanced Load Balancer als Lastausgleichsdienst für Arbeitslasten. Bei der Einstellung true müssen Sie die erforderlichen Variablen festlegen, die unten in NSX Advanced Load Balancer aufgeführt sind.
AVI_ADMIN_CREDENTIAL_NAME	✔	✖	Optional; standardmäßig avi-controller-credentials. Der Name des geheimen Kubernetes-Schlüssels, der den Benutzernamen und das Kennwort für den Administrator des NSX Advanced Load Balancer-Controllers enthält.
AVI_AKO_IMAGE_PULL_POLICY	✔	✖	Optional; standardmäßig IfNotPresent.
AVI_CA_DATA_B64	✔	✖	Erforderlich. Der Inhalt der Controller-Zertifizierungsstelle, die zum Signieren des Controller-Zertifikats verwendet wird. Dieser muss base64-codiert sein. Eine Beschreibung zum Abrufen nicht codierter Inhalte von benutzerdefinierten Zertifikaten finden Sie in Einrichten eines AVI-Controllers: Benutzerdefiniertes Zertifikat.
AVI_CA_NAME	✔	✖	Optional; standardmäßig avi-controller-ca. Der Name des geheimen Kubernetes-Schlüssels, der die Zertifizierungsstelle für den NSX Advanced Load Balancer-Controller enthält.
AVI_CLOUD_NAME	✔	✖	Erforderlich. Die Cloud, die Sie in Ihrer NSX Advanced Load Balancer-Bereitstellung erstellt haben. Beispiel: Default-Cloud.
AVI_CONTROLLER	✔	✖	Erforderlich. Die IP-Adresse oder der Hostname des NSX Advanced Load Balancer-Controllers.
AVI_CONTROL_PLANE_HA_PROVIDER	✔	✔	Erforderlich. Setzen Sie diese Variable auf true, um NSX Advanced Load Balancer als API-Server-Endpoint der Steuerungsebene zu aktivieren, oder auf false, um Kube-Vip als Endpoint der Steuerungsebene zu verwenden.
AVI_CONTROL_PLANE_NETWORK	✔	✖	Optional. Definiert das VIP-Netzwerk der Steuerungsebene des Arbeitslastclusters. Verwenden Sie diese Einstellung, wenn Sie ein separates VIP-Netzwerk für die Arbeitslastcluster konfigurieren möchten. Dieses Feld ist optional. Wenn es leer gelassen wird, wird dasselbe Netzwerk wie das AVI_DATA_NETWORK verwendet.
AVI_CONTROL_PLANE_NETWORK_CIDR	✔	✖	Optional; ist standardmäßig auf dasselbe Netzwerk wie AVI_DATA_NETWORK_CIDR festgelegt. Das CIDR des Subnetzes, das für die Steuerungsebene des Arbeitslastclusters verwendet werden soll. Verwenden Sie diese Einstellung, wenn Sie ein separates VIP-Netzwerk für die Arbeitslastcluster konfigurieren möchten. Sie können das Subnetz-CIDR für ein bestimmtes Netzwerk in der Ansicht Infrastruktur – Netzwerke (Infrastructure - Networks) der NSX Advanced Load Balancer-Schnittstelle anzeigen.
AVI_DATA_NETWORK	✔	✖	Erforderlich. Der Name des Netzwerks, auf dem das dynamische IP-Subnetz oder der IP-Pool einem Lastausgleichsdienst für den Datenverkehr zu Anwendungen zugewiesen wird, die auf Arbeitslastclustern gehostet werden. Dieses Netzwerk muss in derselben vCenter Server-Instanz wie das von Tanzu Kubernetes Grid verwendete Kubernetes-Netzwerk vorhanden sein, das Sie in der Variable SERVICE_CIDR angeben. Auf diese Weise kann NSX Advanced Load Balancer das Kubernetes-Netzwerk in vCenter Server erkennen und Dienst-Engines bereitstellen und konfigurieren.
AVI_DATA_NETWORK_CIDR	✔	✖	Erforderlich. Das CIDR des Subnetzes, das für die Lastausgleichsdienst-VIP verwendet werden soll. Dies stammt aus einem der konfigurierten Subnetze des VIP-Netzwerks. Sie können das Subnetz-CIDR für ein bestimmtes Netzwerk in der Ansicht Infrastruktur – Netzwerke (Infrastructure - Networks) der NSX Advanced Load Balancer-Schnittstelle anzeigen.
AVI_DISABLE_INGRESS_CLASS	✔	✖	Optional; standardmäßig false. Deaktivieren Sie die Ingress-Klasse. Hinweis: Diese Variable funktioniert nicht in TKG v2.3. Eine Problemumgehung finden Sie in den Versionshinweisen im Abschnitt Bekanntes Problem: Einige NSX ALB-Konfigurationsvariablen funktionieren nicht.
AVI_DISABLE_STATIC_ROUTE_SYNC	✔	✖	Optional; standardmäßig false. Setzen Sie diese Variable auf true, wenn die Pod-Netzwerke über die NSX ALB-Dienst-Engine erreichbar sind. Hinweis: Diese Variable funktioniert nicht in TKG v2.3. Eine Problemumgehung finden Sie in den Versionshinweisen im Abschnitt Bekanntes Problem: Einige NSX ALB-Konfigurationsvariablen funktionieren nicht.
AVI_INGRESS_DEFAULT_INGRESS_CONTROLLER	✔	✖	Optional; standardmäßig false. Verwenden Sie AKO als standardmäßigen Ingress-Controller. Hinweis: Diese Variable funktioniert nicht in TKG v2.3. Eine Problemumgehung finden Sie in den Versionshinweisen im Abschnitt Bekanntes Problem: Einige NSX ALB-Konfigurationsvariablen funktionieren nicht.
AVI_INGRESS_NODE_NETWORK_LIST	✔	✖	Gibt den Namen des Portgruppen(PG)-Netzwerks an, zu dem Ihre Knoten gehören, und das zugehörige CIDR, das die CNI jedem Knoten zuweist, damit dieser Knoten seinen Pods zugewiesen werden kann. Aktualisieren Sie dies am besten in der AKODeploymentConfig-Datei, siehe L7-Ingress im ClusterIP-Modus. Wenn Sie jedoch die Clusterkonfigurationsdatei verwenden, sieht das Format in etwa wie folgt aus: ‘[{“networkName”: “vsphere-portgroup”,“cidrs”: [“100.64.42.0/24”]}]’.
AVI_INGRESS_SERVICE_TYPE	✔	✖	Optional. Gibt an, ob AKO im ClusterIP-, NodePort- oder NodePortLocal-Modus funktioniert. NodePort ist die Standardeinstellung.
AVI_INGRESS_SHARD_VS_SIZE	✔	✖	Optional. AKO verwendet eine Sharding-Logik für Layer 7-Ingress-Objekte. Ein Sharded VS umfasst das Hosting mehrerer ungeschützter oder geschützter Ingresses, die von einer virtuellen IP bzw. VIP gehostet werden. Legen Sie als Einstellung LARGE, MEDIUM oder SMALL fest. Der Standardwert lautet SMALL. Verwenden Sie diese Option, um die Layer-7-VS-Anzahl zu steuern. Dies gilt sowohl für geschützte als auch für ungeschützte VS, aber nicht für Passthrough.
AVI_LABELS	✔	✔	Optional. Wenn diese Option festgelegt ist, ist NSX Advanced Load Balancer nur auf Arbeitslastclustern mit dieser Bezeichnung aktiviert. Geben Sie die Anführungszeichen ("") mit an. Beispiel: AVI_LABELS: “{foo: ‘bar’}”.
AVI_MANAGEMENT_CLUSTER_CONTROL_PLANE_VIP_NETWORK_CIDR	✔	✖	Optional. Das CIDR des Subnetzes, das für die Steuerungsebene des Verwaltungsclusters verwendet werden soll. Verwenden Sie diese Einstellung, wenn Sie ein separates VIP-Netzwerk für die Steuerungsebene des Verwaltungsclusters konfigurieren möchten. Sie können das Subnetz-CIDR für ein bestimmtes Netzwerk in der Ansicht Infrastruktur – Netzwerke (Infrastructure - Networks) der NSX Advanced Load Balancer-Schnittstelle anzeigen. Dieses Feld ist optional. Wenn es leer gelassen wird, wird dasselbe Netzwerk wie das AVI_DATA_NETWORK_CIDR verwendet.
AVI_MANAGEMENT_CLUSTER_CONTROL_PLANE_VIP_NETWORK_NAME	✔	✖	Optional. Definiert das VIP-Netzwerk der Steuerungsebene des Verwaltungsclusters. Verwenden Sie diese Einstellung, wenn Sie ein separates VIP-Netzwerk für die Steuerungsebene des Verwaltungsclusters konfigurieren möchten. Dieses Feld ist optional. Wenn es leer gelassen wird, wird dasselbe Netzwerk wie das AVI_DATA_NETWORK verwendet.
AVI_MANAGEMENT_CLUSTER_SERVICE_ENGINE_GROUP	✔	✖	Optional. Gibt den Namen der Dienst-Engine-Gruppe an, die von AKO im Verwaltungscluster verwendet werden soll. Dieses Feld ist optional. Wenn es leer gelassen wird, wird dasselbe Netzwerk wie das AVI_SERVICE_ENGINE_GROUP verwendet.
AVI_MANAGEMENT_CLUSTER_VIP_NETWORK_NAME	✔	✖	Optional; ist standardmäßig auf dasselbe Netzwerk wie AVI_DATA_NETWORK festgelegt. Der Name des Netzwerks, in dem Sie einem Lastausgleichsdienst für den Verwaltungscluster und den Arbeitslastcluster der Steuerungsebene ein dynamisches IP-Subnetz oder einen IP-Pool zuweisen (bei Verwendung von NSX ALB zur Bereitstellung von HA auf der Steuerungsebene). Dieses Netzwerk muss in derselben vCenter Server-Instanz wie das von Tanzu Kubernetes Grid verwendete Kubernetes-Netzwerk vorhanden sein, das Sie in der Variable SERVICE_CIDR für den Verwaltungscluster angeben. Auf diese Weise kann NSX Advanced Load Balancer das Kubernetes-Netzwerk in vCenter Server erkennen und Dienst-Engines bereitstellen und konfigurieren.
AVI_MANAGEMENT_CLUSTER_VIP_NETWORK_CIDR	✔	✖	Optional; ist standardmäßig auf dasselbe Netzwerk wie AVI_DATA_NETWORK_CIDR festgelegt. Das CIDR des Subnetzes, das für die Lastausgleichsdienst-VIP des Verwaltungsclusters und der Steuerungsebene des Arbeitslastclusters (bei Verwendung von NSX ALB zur Bereitstellung von HA auf der Steuerungsebene) verwendet werden soll. Dies stammt aus einem der konfigurierten Subnetze des VIP-Netzwerks. Sie können das Subnetz-CIDR für ein bestimmtes Netzwerk in der Ansicht Infrastruktur – Netzwerke (Infrastructure - Networks) der NSX Advanced Load Balancer-Schnittstelle anzeigen.
AVI_NAMESPACE	✔	✖	Optional; standardmäßig “tkg-system-networking”. Der Namespace für den AKO-Operator.
AVI_NSXT_T1LR	✔	✖	Optional. Der NSX T1-Routerpfad, den Sie für Ihren Verwaltungscluster in der AVI-Controller-Benutzeroberfläche unter NSX Cloud konfiguriert haben. Dies ist erforderlich, wenn Sie NSX Cloud auf Ihrem NSX ALB-Controller verwenden. Um einen anderen T1 für Ihre Arbeitslastcluster zu verwenden, ändern Sie das Objekt AKODeploymentConfig install-ako-for-all, nachdem der Verwaltungscluster erstellt wurde.
AVI_PASSWORD	✔	✖	Erforderlich. Das Kennwort, das Sie bei der Bereitstellung für den Controller-Administrator festgelegt haben.
AVI_SERVICE_ENGINE_GROUP	✔	✖	Erforderlich. Name der Dienst-Engine-Gruppe. Beispiel: Default-Group.
AVI_USERNAME	✔	✖	Erforderlich. Der Admin-Benutzername, den Sie bei der Bereitstellung für den Controller-Host festgelegt haben.

NSX-Pod-Routing

Diese Variablen konfigurieren Arbeitslast-Pods mit routingfähiger IP-Adresse, wie unter Bereitstellen eines Clusters mit Pods mit routingfähiger IP beschrieben. Alle Einstellungen für Zeichenfolgen sollten in doppelten Anführungszeichen stehen, z. B. "true".

Variable	Kann festgelegt werden in…		Beschreibung
	Verwaltungscluster-YAML	Arbeitslastcluster-YAML
NSXT_POD_ROUTING_ENABLED	✖	✔	Optional; standardmäßig “false”. Legen Sie diese Variable auf “true” fest, um NSX-routingfähige Pods mit den folgenden Variablen zu aktivieren. Siehe Bereitstellen eines Clusters mit Pods mit routingfähiger IP.
NSXT_MANAGER_HOST	✖	✔	Erforderlich, wenn NSXT_POD_ROUTING_ENABLED= “true”. IP-Adressen von NSX Manager.
NSXT_ROUTER_PATH	✖	✔	Erforderlich, wenn NSXT_POD_ROUTING_ENABLED= “true”. In NSX Manager angezeigter T1-Routerpfad.
Für die Authentifizierung mit Benutzername/Kennwort bei NSX:
NSXT_USERNAME	✖	✔	Benutzername für die Anmeldung bei NSX Manager.
NSXT_PASSWORD	✖	✔	Kennwort für die Anmeldung bei NSX Manager.
Für die Authentifizierung bei NSX mithilfe von Anmeldedaten und deren Speicherung in einem geheimen Kubernetes-Schlüssel (auch festgelegter NSXT_USERNAME und NSXT_PASSWORD, siehe oben):
NSXT_SECRET_NAMESPACE	✖	✔	Optional; standardmäßig “kube-system”. Der Namespace mit dem geheimen Schlüssel, der NSX-Benutzername und -Kennwort enthält.
NSXT_SECRET_NAME	✖	✔	Optional; standardmäßig “cloud-provider-vsphere-nsxt-credentials”. Der Name des geheimen Schlüssels, der NSX-Benutzername und -Kennwort enthält.
Für die Zertifikatauthentifizierung bei NSX:
NSXT_ALLOW_UNVERIFIED_SSL	✖	✔	Optional; standardmäßig false. Setzen Sie diese Variable auf “true”, wenn NSX ein selbstsigniertes Zertifikat verwendet.
NSXT_ROOT_CA_DATA_B64	✖	✔	Erforderlich, wenn NSXT_ALLOW_UNVERIFIED_SSL= “false”. Base64-codierte Zeichenfolge für das Stammzertifikat der Zertifizierungsstelle, die NSX für die LDAP-Authentifizierung verwendet.
NSXT_CLIENT_CERT_KEY_DATA	✖	✔	Base64-codierte Zeichenfolge für die Zertifikatschlüsseldatei für lokales Clientzertifikat.
NSXT_CLIENT_CERT_DATA	✖	✔	Base64-codierte Zeichenfolge für die Zertifikatdatei für lokales Clientzertifikat.
Für die Remoteauthentifizierung bei NSX mit VMware Identity Manager auf VMware Cloud (VMC):
NSXT_REMOTE_AUTH	✖	✔	Optional; standardmäßig false. Setzen Sie diese Variable auf “true”, damit die Remoteauthentifizierung bei NSX mit VMware Identity Manager auf VMware Cloud (VMC) erfolgt.
NSXT_VMC_AUTH_HOST	✖	✔	Optional; Standardwert ist leer. VMC-Authentifizierungshost.
NSXT_VMC_ACCESS_TOKEN	✖	✔	Optional; Standardwert ist leer. Token für den VMC-Authentifizierungszugriff.

Knoten-IPAM

Diese Variablen konfigurieren die IP-Adressverwaltung (IPAM) innerhalb des Clusters, wie unter Knoten-IPAM beschrieben. Alle Einstellungen für Zeichenfolgen sollten in doppelten Anführungszeichen stehen, z. B. "true".

Variable	Kann festgelegt werden in…		Beschreibung
	Verwaltungscluster-YAML	Arbeitslastcluster-YAML
CONTROL_PLANE_NODE_NAMESERVERS	✔	✔	Durch Komma getrennte Liste von Nameservern, z. B. “10.10.10.10” für von Knoten-IPAM verwaltete Adressen von Knoten der Steuerungsebene. Unterstützt unter Ubuntu und Photon. Nicht unterstützt unter Windows.
NODE_IPAM_IP_POOL_APIVERSION	✖	✔	API-Version für das vom Arbeitslastcluster verwendete InClusterIPPool-Objekt. Standardmäßig “ipam.cluster.x-k8s.io/v1alpha2”; frühere TKG-Versionen verwendeten v1alpha1.
NODE_IPAM_IP_POOL_KIND	✖	✔	Typ des vom Arbeitslastcluster verwendeten IP-Pool-Objekts. Standardmäßig “InClusterIPPool” oder “GlobalInClusterIPPool”, um denselben Pool mit anderen Clustern gemeinsam zu nutzen.
NODE_IPAM_IP_POOL_NAME	✖	✔	Name des IP-Pool-Objekts, das den von einem Arbeitslastcluster verwendeten IP-Pool konfiguriert.
WORKER_NODE_NAMESERVERS	✔	✔	Durch Komma getrennte Liste von Nameservern, z. B. “10.10.10.10”, für Worker-Knotenadressen, die von Knoten-IPAM verwaltet werden. Unterstützt unter Ubuntu und Photon. Nicht unterstützt unter Windows.
MANAGEMENT_NODE_IPAM_IP_POOL_GATEWAY	✔	✖	Das Standard-Gateway für IPAM-Pooladressen in einem Verwaltungscluster, z. B. "10.10.10.1".
MANAGEMENT_NODE_IPAM_IP_POOL_ADDRESSES	✔	✖	Die Adressen, die von IPAM in einem Verwaltungscluster zugewiesen werden können, in einer durch Komma getrennten Liste, die einzelne IP-Adressen, Bereiche (z. B. 10.0.0.2-10.0.0.100) oder CIDRs (z. B. 10.0.0.32/27) enthalten kann. Fügen Sie zusätzliche Adressen hinzu, die bei Bedarf für Cluster-Upgrades unbenutzt bleiben. Die erforderliche Anzahl zusätzlicher Adressen beträgt standardmäßig eins und wird durch die Anmerkung topology.controlPlane und topology.workers in den Definitionen topology.cluster.x-k8s.io/upgrade-concurrency des Clusterobjekts festgelegt.
MANAGEMENT_NODE_IPAM_IP_POOL_SUBNET_PREFIX	✔	✖	Das Netzwerkpräfix des Subnetzes für IPAM-Pooladressen in einem eigenständigen Verwaltungscluster, z. B. “24”

GPU-fähige Cluster

Diese Variablen konfigurieren GPU-fähige Arbeitslastcluster im PCI-Passthrough-Modus, wie unter Bereitstellen eines GPU-fähigen Arbeitslastclusters beschrieben. Alle Einstellungen für Zeichenfolgen sollten in doppelten Anführungszeichen stehen, z. B. "true".

Variable	Kann festgelegt werden in…		Beschreibung
	Verwaltungscluster-YAML	Arbeitslastcluster-YAML
VSPHERE_CONTROL_PLANE_CUSTOM_VMX_KEYS	✔	✔	Legt benutzerdefinierte VMX-Schlüssel auf allen Maschinen der Steuerungsebene fest. Verwenden Sie das Format Key1=Value1,Key2=Value2. Weitere Informationen finden Sie unter Bereitstellen eines GPU-fähigen Arbeitslastclusters.
VSPHERE_CONTROL_PLANE_HARDWARE_VERSION	✔	✔	Die Hardwareversion für die Steuerungsebenen-VM mit dem GPU-Gerät im PCI-Passthrough-Modus. Die erforderliche Mindestversion ist 17. Das Format des Werts ist vmx-17, wobei es sich bei den abschließenden Ziffern um die Hardwareversion der virtuellen Maschine handelt. Informationen zur Funktionsunterstützung für verschiedene Hardwareversionen finden Sie unter Hardware-Funktionen mit den Kompatibilitätseinstellungen für virtuelle Maschinen in der vSphere-Dokumentation.
VSPHERE_CONTROL_PLANE_PCI_DEVICES	✔	✔	Konfiguriert PCI-Passthrough auf allen Maschinen der Steuerungsebene. Verwenden Sie das Format <vendor_id>:<device_id>. Beispiel: VSPHERE_WORKER_PCI_DEVICES: “0x10DE:0x1EB8”. Informationen zum Auffinden der Anbieter- und Geräte-IDs finden Sie unter Bereitstellen eines GPU-fähigen Arbeitslastclusters.
VSPHERE_IGNORE_PCI_DEVICES_ALLOW_LIST	✔	✔	Setzen Sie diese Variable auf false, wenn Sie die NVIDIA Tesla T4-GPU verwenden, und auf true, wenn Sie die NVIDIA V100-GPU verwenden.
VSPHERE_WORKER_CUSTOM_VMX_KEYS	✔	✔	Legt benutzerdefinierte VMX-Schlüssel auf allen Worker-Maschinen fest. Verwenden Sie das Format Key1=Value1,Key2=Value2. Ein Beispiel finden Sie unter Bereitstellen eines GPU-fähigen Arbeitslastclusters.
VSPHERE_WORKER_HARDWARE_VERSION	✔	✔	Die Hardwareversion für die Worker-VM mit dem GPU-Gerät im PCI-Passthrough-Modus. Die erforderliche Mindestversion ist 17. Das Format des Werts ist vmx-17, wobei es sich bei den abschließenden Ziffern um die Hardwareversion der virtuellen Maschine handelt. Informationen zur Funktionsunterstützung für verschiedene Hardwareversionen finden Sie unter Hardware-Funktionen mit den Kompatibilitätseinstellungen für virtuelle Maschinen in der vSphere-Dokumentation.
VSPHERE_WORKER_PCI_DEVICES	✔	✔	Konfiguriert PCI-Passthrough auf allen Worker-Maschinen. Verwenden Sie das Format <vendor_id>:<device_id>. Beispiel: VSPHERE_WORKER_PCI_DEVICES: “0x10DE:0x1EB8”. Informationen zum Auffinden der Anbieter- und Geräte-IDs finden Sie unter Bereitstellen eines GPU-fähigen Arbeitslastclusters.
WORKER_ROLLOUT_STRATEGY	✔	✔	Optional. Konfiguriert die Rollout-Strategie für die MachineDeployment. Der Standardwert lautet RollingUpdate. Bei der Einstellung OnDelete werden bei Updates zuerst die vorhandenen Worker-Maschinen gelöscht, bevor die Worker-Ersatzmaschinen erstellt werden. Wenn alle verfügbaren PCI-Geräte von den Worker-Knoten verwendet werden, ist die Einstellung OnDelete für diese Variable unbedingt geboten.

AWS

Bei den Variablen in der folgenden Tabelle handelt es sich um die Optionen, die Sie in der Clusterkonfigurationsdatei angeben, wenn Sie Arbeitslastcluster unter AWS bereitstellen. Viele dieser Optionen sind für den Arbeitslastcluster und für den zu dessen Bereitstellung verwendeten Verwaltungscluster identisch.

Weitere Informationen zu den Konfigurationsdateien für AWS finden Sie unter Konfiguration eines Verwaltungsclusters für AWS und AWS-Clusterkonfigurationsdateien.

Variable	Kann festgelegt werden in…		Beschreibung
	Verwaltungscluster-YAML	Arbeitslastcluster-YAML
AWS_ACCESS_KEY_ID	✔	✔	Optional. Die Zugriffsschlüssel-ID für Ihr AWS-Konto. Dies ist eine Möglichkeit für die Authentifizierung bei AWS. Weitere Informationen finden Sie unter Konfigurieren der AWS-Kontoanmeldedaten. Verwenden Sie nur AWS_PROFILE oder eine Kombination aus AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY, aber nicht beides.
AWS_CONTROL_PLANE_OS_DISK_SIZE_GIB	✔	✔	Optional. Festplattengröße für Knoten der Steuerungsebene. Überschreibt die standardmäßige Festplattengröße für den VM-Typ, der von CONTROL_PLANE_MACHINE_TYPE, SIZE oder CONTROLPLANE_SIZE festgelegt wurde.
AWS_LOAD_BALANCER_SCHEME_INTERNAL	✔	✔	Optional. Legt für Verwaltungscluster als Lastausgleichsdienstschema „Intern“ fest, wodurch der Zugriff über das Internet verhindert wird. Stellt bei Arbeitslastclustern sicher, dass der Verwaltungscluster intern auf den Lastausgleichsdienst des Arbeitslastclusters zugreift, wenn sie gemeinsam dieselbe VPC verwenden oder Peers sind. Weitere Informationen finden Sie unter Verwenden eines internen Lastausgleichsdiensts für Kubernetes-API-Server.
AWS_NODE_AZ	✔	✔	Erforderlich. Der Name der AWS-Verfügbarkeitszone in Ihrer ausgewählten Region, die Sie als Verfügbarkeitsbereich für diesen Verwaltungscluster verwenden möchten. Die Namen der Verfügbarkeitsbereiche sind mit dem Namen der AWS-Region identisch und enthalten zusätzlich ein Suffix aus einem einzelnen Kleinbuchstaben, z. B. a, b, c. Beispiel: us-west-2a. Um einen prod-Verwaltungscluster mit drei Knoten der Steuerungsebene bereitzustellen, müssen Sie auch AWS_NODE_AZ_1 und AWS_NODE_AZ_2 festlegen. Das Suffix des Buchstabens in jedem dieser Verfügbarkeitsbereiche muss eindeutig sein. Beispiel: us-west-2a, us-west-2b und us-west-2c.
AWS_NODE_OS_DISK_SIZE_GIB	✔	✔	Optional. Festplattengröße für Worker-Knoten. Überschreibt die standardmäßige Festplattengröße für den VM-Typ, der von NODE_MACHINE_TYPE, SIZE oder WORKER_SIZE festgelegt wurde.
AWS_NODE_AZ_1 und AWS_NODE_AZ_2	✔	✔	Optional. Legen Sie diese Variablen fest, wenn Sie einen prod-Verwaltungscluster mit drei Knoten der Steuerungsebene bereitstellen möchten. Beide Verfügbarkeitsbereiche müssen sich in derselben Region befinden wie AWS_NODE_AZ. Weitere Informationen finden Sie unter AWS_NODE_AZ. Beispiel: us-west-2a, ap-northeast-2b usw.
AWS_PRIVATE_NODE_CIDR_1	✔	✔	Optional. Wenn der empfohlene Bereich 10.0.2.0/24 nicht verfügbar ist, geben Sie einen anderen IP-Bereich im CIDR-Format ein. Wenn Tanzu Kubernetes Grid Ihren Verwaltungscluster bereitstellt, wird dieses Subnetz in AWS_NODE_AZ_1 erstellt. Weitere Informationen finden Sie unter AWS_PRIVATE_NODE_CIDR.
AWS_PRIVATE_NODE_CIDR_2	✔	✔	Optional. Wenn der empfohlene Bereich 10.0.4.0/24 nicht verfügbar ist, geben Sie einen anderen IP-Bereich im CIDR-Format ein. Wenn Tanzu Kubernetes Grid Ihren Verwaltungscluster bereitstellt, wird dieses Subnetz in AWS_NODE_AZ_2 erstellt. Weitere Informationen finden Sie unter AWS_PRIVATE_NODE_CIDR.
AWS_PROFILE	✔	✔	Optional. Das von aws configure verwaltete AWS-Anmeldedatenprofil, das Tanzu Kubernetes Grid für den Zugriff auf sein AWS-Konto verwendet. Dies ist die bevorzugte Option für die Authentifizierung bei AWS. Weitere Informationen finden Sie unter Konfigurieren der AWS-Kontoanmeldedaten. Verwenden Sie nur AWS_PROFILE oder eine Kombination aus AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY, aber nicht beides.
AWS_PUBLIC_NODE_CIDR_1	✔	✔	Optional. Wenn der empfohlene Bereich 10.0.3.0/24 nicht verfügbar ist, geben Sie einen anderen IP-Bereich im CIDR-Format ein. Wenn Tanzu Kubernetes Grid Ihren Verwaltungscluster bereitstellt, wird dieses Subnetz in AWS_NODE_AZ_1 erstellt. Weitere Informationen finden Sie unter AWS_PUBLIC_NODE_CIDR.
AWS_PUBLIC_NODE_CIDR_2	✔	✔	Optional. Wenn der empfohlene Bereich 10.0.5.0/24 nicht verfügbar ist, geben Sie einen anderen IP-Bereich im CIDR-Format ein. Wenn Tanzu Kubernetes Grid Ihren Verwaltungscluster bereitstellt, wird dieses Subnetz in AWS_NODE_AZ_2 erstellt. Weitere Informationen finden Sie unter AWS_PUBLIC_NODE_CIDR.
AWS_PRIVATE_SUBNET_ID	✔	✔	Optional. Wenn Sie AWS_VPC_ID für die Verwendung einer vorhandenen VPC festlegen, geben Sie die ID eines privaten Subnetzes ein, das bereits in AWS_NODE_AZ vorhanden ist. Diese Einstellung ist optional. Wenn Sie sie nicht festlegen, identifiziert tanzu management-cluster create das private Subnetz automatisch. Um einen prod-Verwaltungscluster mit drei Knoten der Steuerungsebene bereitzustellen, müssen Sie auch AWS_PRIVATE_SUBNET_ID_1 und AWS_PRIVATE_SUBNET_ID_2 festlegen.
AWS_PRIVATE_SUBNET_ID_1	✔	✔	Optional. Die ID eines privaten Subnetzes, das in AWS_NODE_AZ_1 vorhanden ist. Wenn Sie diese Variable nicht festlegen, identifiziert tanzu management-cluster create das private Subnetz automatisch. Weitere Informationen finden Sie unter AWS_PRIVATE_SUBNET_ID.
AWS_PRIVATE_SUBNET_ID_2	✔	✔	Optional. Die ID eines privaten Subnetzes, das in AWS_NODE_AZ_2 vorhanden ist. Wenn Sie diese Variable nicht festlegen, identifiziert tanzu management-cluster create das private Subnetz automatisch. Weitere Informationen finden Sie unter AWS_PRIVATE_SUBNET_ID.
AWS_PUBLIC_SUBNET_ID	✔	✔	Optional. Wenn Sie AWS_VPC_ID für die Verwendung einer vorhandenen VPC festlegen, geben Sie die ID eines öffentlichen Subnetzes ein, das bereits in AWS_NODE_AZ vorhanden ist. Diese Einstellung ist optional. Wenn Sie sie nicht festlegen, identifiziert tanzu management-cluster create das öffentliche Subnetz automatisch. Um einen prod-Verwaltungscluster mit drei Knoten der Steuerungsebene bereitzustellen, müssen Sie auch AWS_PUBLIC_SUBNET_ID_1 und AWS_PUBLIC_SUBNET_ID_2 festlegen.
AWS_PUBLIC_SUBNET_ID_1	✔	✔	Optional. Die ID eines öffentlichen Subnetzes, das in AWS_NODE_AZ_1 vorhanden ist. Wenn Sie diese Variable nicht festlegen, identifiziert tanzu management-cluster create das öffentliche Subnetz automatisch. Weitere Informationen finden Sie unter AWS_PUBLIC_SUBNET_ID.
AWS_PUBLIC_SUBNET_ID_2	✔	✔	Optional. Die ID eines öffentlichen Subnetzes, das in AWS_NODE_AZ_2 vorhanden ist. Wenn Sie diese Variable nicht festlegen, identifiziert tanzu management-cluster create das öffentliche Subnetz automatisch. Weitere Informationen finden Sie unter AWS_PUBLIC_SUBNET_ID.
AWS_REGION	✔	✔	Erforderlich. Der Name der AWS-Region, in der der Cluster bereitgestellt werden soll. Beispiel: us-west-2. Sie können auch die Regionen us-gov-east und us-gov-west in AWS GovCloud angeben. Wenn Sie bereits eine andere Region als Umgebungsvariable festgelegt haben, z. B. in Bereitstellen von Verwaltungsclustern für AWS, müssen Sie die Einstellung für diese Umgebungsvariable aufheben. Beispiel: us-west-2, ap-northeast-2 usw.
AWS_SECRET_ACCESS_KEY	✔	✔	Optional. Der geheime Zugriffsschlüssel für Ihr AWS-Konto. Dies ist eine Möglichkeit für die Authentifizierung bei AWS. Weitere Informationen finden Sie unter Konfigurieren der AWS-Kontoanmeldedaten. Verwenden Sie nur AWS_PROFILE oder eine Kombination aus AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY, aber nicht beides.
AWS_SECURITY_GROUP_APISERVER_LB	✔	✔	Optional. Benutzerdefinierte Sicherheitsgruppen mit benutzerdefinierten Regeln, die auf den Cluster angewendet werden sollen. Weitere Informationen finden Sie unter Konfiguration von benutzerdefinierten Sicherheitsgruppen.
AWS_SECURITY_GROUP_BASTION
AWS_SECURITY_GROUP_CONTROLPLANE
AWS_SECURITY_GROUP_APISERVER_LB
AWS_SECURITY_GROUP_NODE
AWS_SESSION_TOKEN	✔	✔	Optional. Geben Sie das Ihrem Konto gewährte AWS-Sitzungstoken an, wenn Sie einen temporären Zugriffsschlüssel verwenden müssen. Weitere Informationen zur Verwendung temporärer Zugriffsschlüssel finden Sie unter Grundlegende Informationen zu und Abrufen von AWS-Anmeldedaten. Geben Sie das Sitzungstoken für Ihr AWS-Konto an. Alternativ können Sie Kontoanmeldedaten als lokale Umgebungsvariablen oder in Ihrer Standardanbieterkette für AWS-Anmeldedaten angeben.
AWS_SSH_KEY_NAME	✔	✔	Erforderlich. Der Name des privaten SSH-Schlüssels, den Sie bei Ihrem AWS-Konto registriert haben.
AWS_VPC_ID	✔	✔	Optional. Um eine VPC zu verwenden, die bereits in Ihrer ausgewählten AWS-Region vorhanden ist, geben Sie die ID der VPC ein und legen Sie dann AWS_PUBLIC_SUBNET_ID und AWS_PRIVATE_SUBNET_ID fest.
BASTION_HOST_ENABLED	✔	✔	Optional. Standardmäßig ist diese Variable in der globalen Tanzu Kubernetes Grid-Konfiguration auf "true" gesetzt. Geben Sie "true" an, um einen Bastion-Host auf AWS bereitzustellen, oder "false", um einen vorhandenen Bastion-Host wiederzuverwenden. Wenn in Ihren Verfügbarkeitsbereichen kein Bastion-Host vorhanden ist und Sie AWS_VPC_ID so einstellen, dass eine vorhandene VPC verwendet wird, setzen Sie BASTION_HOST_ENABLED auf "true".
CONTROL_PLANE_MACHINE_TYPE	✔	✔	Erforderlich, wenn cloudunabhängige SIZE oder CONTROLPLANE_SIZE nicht festgelegt ist. Der Amazon EC2-Instanztyp, der für Clusterknoten der Steuerungsebene verwendet werden soll, z. B. t3.small oder m5.large.
NODE_MACHINE_TYPE	✔	✔	Erforderlich, wenn cloudunabhängige SIZE oder WORKER_SIZE nicht festgelegt ist. Der Amazon EC2-Instanztyp, der für Worker-Clusterknoten verwendet werden soll, z. B. t3.small oder m5.large.

Microsoft Azure

Die Variablen in der folgenden Tabelle sind die Optionen, die Sie in der Clusterkonfigurationsdatei angeben, wenn Sie Arbeitslastcluster in Azure bereitstellen. Viele dieser Optionen sind für den Arbeitslastcluster und für den zu dessen Bereitstellung verwendeten Verwaltungscluster identisch.

Weitere Informationen zu den Konfigurationsdateien für Azure finden Sie unter Konfiguration eines Verwaltungsclusters für Azure und Azure-Clusterkonfigurationsdateien.

Variable	Kann festgelegt werden in…		Beschreibung
	Verwaltungscluster-YAML	Arbeitslastcluster-YAML
AZURE_CLIENT_ID	✔	✔	Erforderlich. Die Client-ID der App für Tanzu Kubernetes Grid, die Sie bei Azure registriert haben.
AZURE_CLIENT_SECRET	✔	✔	Erforderlich. Ihr geheimer Azure-Clientschlüssel aus Registrieren einer Tanzu Kubernetes Grid-App unter Azure.
AZURE_CUSTOM_TAGS	✔	✔	Optional. Kommagetrennte Liste der Tags, die auf für den Cluster erstellte Azure-Ressourcen angewendet werden sollen. Ein Tag ist ein Schlüssel-Wert-Paar, z. B. “foo=bar, plan=prod”. Weitere Informationen zum Taggen von Azure-Ressourcen finden Sie in der Microsoft Azure-Dokumentation unter Organisieren von Azure-Ressourcen und Verwaltungshierarchie mit Tags und Tag-Unterstützung für Azure-Ressourcen.
AZURE_ENVIRONMENT	✔	✔	Optional; standardmäßig AzurePublicCloud. Unterstützte Clouds sind AzurePublicCloud, AzureChinaCloud, AzureGermanCloud, AzureUSGovernmentCloud.
AZURE_IDENTITY_NAME	✔	✔	Optional. Geben Sie diese Variable an, wenn Sie Cluster in verschiedenen Azure-Konten verwenden möchten. Der Name, der für die AzureClusterIdentity verwendet werden soll, die Sie für die Verwendung von Clustern in verschiedenen Azure-Konten erstellen. Weitere Informationen finden Sie in Bereitstellen von Arbeitslastclustern für Azure unter Cluster in unterschiedlichen Azure-Konten.
AZURE_IDENTITY_NAMESPACE	✔	✔	Optional. Geben Sie diese Variable an, wenn Sie Cluster in verschiedenen Azure-Konten verwenden möchten. Der Namespace für die AzureClusterIdentity, die Sie zur Verwendung von Clustern in verschiedenen Azure-Konten erstellen. Weitere Informationen finden Sie in Bereitstellen von Arbeitslastclustern für Azure unter Cluster in unterschiedlichen Azure-Konten.
AZURE_LOCATION	✔	✔	Erforderlich. Der Name der Azure-Region, in der der Cluster bereitgestellt werden soll. Beispiel: eastus.
AZURE_RESOURCE_GROUP	✔	✔	Optional; Standardwert ist die CLUSTER_NAME-Einstellung. Der Name der Azure-Ressourcengruppe, die Sie für den Cluster verwenden möchten. Muss für jeden Cluster eindeutig sein. AZURE_RESOURCE_GROUP und AZURE_VNET_RESOURCE_GROUP sind standardmäßig identisch.
AZURE_SSH_PUBLIC_KEY_B64	✔	✔	Erforderlich. Ihr öffentlicher SSH-Schlüssel, der in Bereitstellen eines Verwaltungsclusters für Microsoft Azure erstellt wurde, konvertiert in Base64, wobei Zeilenumbrüche entfernt wurden. Beispiel: …c3NoLXJzYSBB [] vdGFsLmlv.
AZURE_SUBSCRIPTION_ID	✔	✔	Erforderlich. Die Abonnement-ID Ihres Azure-Abonnements.
AZURE_TENANT_ID	✔	✔	Erforderlich. Die Mandanten-ID Ihres Azure-Kontos.
Netzwerk
AZURE_CONTROL_PLANE_OUTBOUND_LB_FRONTEND_IP_COUNT	✔	✔	Optional; standardmäßig 1. Legen Sie diese Variable fest, um dem Lastausgleichsdienst der Steuerungsebene in Umgebungen mit einer hohen Anzahl von erwarteten ausgehenden Verbindungen mehrere Front-End-IP-Adressen hinzuzufügen.
AZURE_ENABLE_ACCELERATED_NETWORKING	✔	✔	Optional; standardmäßig true. Setzen Sie diese Variable auf false, um den beschleunigen Azure-Netzwerkbetrieb auf VMs mit mehr als 4 CPUs zu deaktivieren.
AZURE_ENABLE_CONTROL_PLANE_OUTBOUND_LB	✔	✔	Optional. Setzen Sie diese Variable auf true, wenn AZURE_ENABLE_PRIVATE_CLUSTER true ist und Sie eine öffentliche IP-Adresse auf dem ausgehenden Lastausgleichsdienst für die Steuerungsebene aktivieren möchten.
AZURE_ENABLE_NODE_OUTBOUND_LB	✔	✔	Optional. Setzen Sie diese Variable auf true, wenn AZURE_ENABLE_PRIVATE_CLUSTER true ist und Sie eine öffentliche IP-Adresse auf dem ausgehenden Lastausgleichsdienst für die Worker-Knoten aktivieren möchten.
AZURE_ENABLE_PRIVATE_CLUSTER	✔	✔	Optional. Setzen Sie diese Variable auf true, um den Cluster als privaten Cluster zu konfigurieren und einen internen Azure-Lastausgleichsdienst (ILB) für seinen eingehenden Datenverkehr zu verwenden. Weitere Informationen finden Sie unter Private Azure-Cluster.
AZURE_FRONTEND_PRIVATE_IP	✔	✔	Optional. Legen Sie diese Variable fest, wenn AZURE_ENABLE_PRIVATE_CLUSTER true ist und Sie die interne Standardadresse des Lastausgleichsdiensts von 10.0.0.100 außer Kraft setzen möchten.
AZURE_NODE_OUTBOUND_LB_FRONTEND_IP_COUNT	✔	✔	Optional; standardmäßig 1. Legen Sie diese Variable fest, um dem Lastausgleichsdienst des Worker-Knotens in Umgebungen mit einer hohen Anzahl von erwarteten ausgehenden Verbindungen mehrere Front-End-IP-Adressen hinzuzufügen.
AZURE_NODE_OUTBOUND_LB_IDLE_TIMEOUT_IN_MINUTES	✔	✔	Optional; standardmäßig 4. Legen Sie diese Variable fest, um anzugeben, wie viele Minuten ausgehende TCP-Verbindungen über den Lastausgleichsdienst für ausgehenden Datenverkehr des Worker-Knotens geöffnet bleiben.
AZURE_VNET_CIDR	✔	✔	Optional. Mit dieser Variablen können Sie angeben, ob der Cluster in einem neuen VNet und Subnetzen bereitgestellt werden soll, und die Standardwerte außer Kraft setzen. Die Standardeinstellung für AZURE_VNET_CIDR lautet 10.0.0.0/16, die Standardeinstellung für AZURE_CONTROL_PLANE_SUBNET_CIDR lautet 10.0.0.0/24 und die Standardeinstellung für AZURE_NODE_SUBNET_CIDR lautet 10.0.1.0/24.
AZURE_CONTROL_PLANE_SUBNET_CIDR
AZURE_NODE_SUBNET_CIDR
AZURE_VNET_NAME	✔	✔	Optional. Mit dieser Variablen können Sie festlegen, ob der Cluster in einem vorhandenen VNet und Subnetzen bereitgestellt werden soll, oder Sie können einem neuen VNet und Subnetzen Namen zuweisen.
AZURE_CONTROL_PLANE_SUBNET_NAME
AZURE_NODE_SUBNET_NAME
AZURE_VNET_RESOURCE_GROUP	✔	✔	Optional; ist standardmäßig auf den Wert von AZURE_RESOURCE_GROUP festgelegt.
VMs der Steuerungsebene
AZURE_CONTROL_PLANE_DATA_DISK_SIZE_GIB	✔	✔	Optional. Größe der Datenfestplatte und der Betriebssystemfestplatte in GB für VMs der Steuerungsebene, wie in der Azure-Dokumentation Rollen von Festplatten beschrieben. Beispiele: 128, 256. Knoten der Steuerungsebene werden immer mit einer Datenfestplatte bereitgestellt.
AZURE_CONTROL_PLANE_OS_DISK_SIZE_GIB
AZURE_CONTROL_PLANE_MACHINE_TYPE	✔	✔	Optional; standardmäßig Standard_D2s_v3. Eine für die erwarteten Arbeitslasten ausgewählte Azure-VM-Größe für die Knoten-VMs der Steuerungsebene. Die Mindestanforderung für Azure-Instanztypen ist 2 CPUs und 8 GB Arbeitsspeicher. Mögliche Werte finden Sie in der Schnittstelle des Installationsprogramms für Tanzu Kubernetes Grid.
AZURE_CONTROL_PLANE_OS_DISK_STORAGE_ACCOUNT_TYPE	✔	✔	Optional. Typ des Azure-Speicherkontos für Festplatten von VMs der Steuerungsebene. Beispiel: Premium_LRS.
Worker-Knoten-VMs
AZURE_ENABLE_NODE_DATA_DISK	✔	✔	Optional; standardmäßig false. Setzen Sie diese Option auf true, um eine Datenfestplatte für jede Worker-Knoten-VM bereitzustellen, wie in der Azure-Dokumentation Rollen von Festplatten beschrieben.
AZURE_NODE_DATA_DISK_SIZE_GIB	✔	✔	Optional. Legen Sie diese Variable fest, wenn AZURE_ENABLE_NODE_DATA_DISK true ist. Größe der Datenfestplatte für Worker-VMs in GB, wie in der Azure-Dokumentation Rollen von Festplatten beschrieben. Beispiele: 128, 256.
AZURE_NODE_OS_DISK_SIZE_GIB	✔	✔	Optional. Größe der Betriebssystemfestplatte für Worker-VMs in GB, wie in der Azure-Dokumentation Rollen von Festplatten beschrieben. Beispiele: 128, 256.
AZURE_NODE_MACHINE_TYPE	✔	✔	Optional. Eine für die erwarteten Arbeitslasten ausgewählte Azure-VM-Größe für die Worker-Knoten-VMs. Der Standardwert ist Standard_D2s_v3. Mögliche Werte finden Sie in der Schnittstelle des Installationsprogramms für Tanzu Kubernetes Grid.
AZURE_NODE_OS_DISK_STORAGE_ACCOUNT_TYPE	✔	✔	Optional. Legen Sie diese Variable fest, wenn AZURE_ENABLE_NODE_DATA_DISK true ist. Typ des Azure-Speicherkontos für Worker-VM-Festplatten. Beispiel: Premium_LRS.

Vorrang für Konfigurationswerte

Wenn die Tanzu CLI einen Cluster erstellt, liest sie Werte für die in diesem Thema aufgeführten Variablen aus mehreren Quellen ein. Wenn diese Quellen in Konflikt stehen, werden Konflikte in der folgenden absteigenden Reihenfolge behoben:

Verarbeitung von Layern, sortiert in absteigender Reihenfolge	Quelle	Beispiele
1. In der Schnittstelle des Installationsprogramms festgelegte Konfigurationsvariablen für den Verwaltungscluster	In die von der Option –ui gestartete Schnittstelle des Installationsprogramms eingegeben und in die Clusterkonfigurationsdateien geschrieben. Dateien werden standardmäßig im Verzeichnis ~/.config/tanzu/tkg/clusterconfigs/ gespeichert.
2. In Ihrer lokalen Umgebung festgelegte Clusterkonfigurationsvariablen	In der Shell festgelegt.	export AZURE_NODE_MACHINE_TYPE=Standard_D2s_v3
3. In der Tanzu CLI festgelegte Clusterkonfigurationsvariablen mit tanzu config set env.	In Shell festgelegt; in der globalen Tanzu CLI-Konfigurationsdatei ~/.config/tanzu/config.yaml gespeichert.	tanzu config set env.AZURE_NODE_MACHINE_TYPE Standard_D2s_v3
4. In der Clusterkonfigurationsdatei festgelegte Clusterkonfigurationsvariablen	Wird in der an die Option –file von tanzu management-cluster create oder tanzu cluster create übergebene Datei festgelegt. Standardmäßig lautet die Datei ~/.config/tanzu/tkg/cluster-config.yaml.	AZURE_NODE_MACHINE_TYPE: Standard_D2s_v3
5. Werkseitige Standardkonfigurationswerte	Wird in providers/config_default.yaml festgelegt. Ändern Sie diese Datei nicht.	AZURE_NODE_MACHINE_TYPE: “Standard_D2s_v3”