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
Variable	Verwaltungscluster-YAML	Arbeitslastcluster-YAML	Beschreibung
`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
Variable	Verwaltungscluster-YAML	Arbeitslastcluster-YAML	Beschreibung
`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
Variable	Verwaltungscluster-YAML	Arbeitslastcluster-YAML	Beschreibung
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
Variable	Verwaltungscluster-YAML	Arbeitslastcluster-YAML	Beschreibung
`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 `VSPHERE_WORKER_SIZE` 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
Variable	Verwaltungscluster-YAML	Arbeitslastcluster-YAML	Beschreibung
`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
Variable	Verwaltungscluster-YAML	Arbeitslastcluster-YAML	Beschreibung
`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
Variable	Verwaltungscluster-YAML	Arbeitslastcluster-YAML	Beschreibung
`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
Variable	Verwaltungscluster-YAML	Arbeitslastcluster-YAML	Beschreibung
`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
Variable	Verwaltungscluster-YAML	Arbeitslastcluster-YAML	Beschreibung
`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
Variable	Verwaltungscluster-YAML	Arbeitslastcluster-YAML	Beschreibung
`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 / 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
Variable	Verwaltungscluster-YAML	Arbeitslastcluster-YAML	Beschreibung
`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 diese Variable auf `ADDITIONAL_IMAGE_REGISTRY-true` für alle privaten Image-Registrierungen fest, die mit oben konfiguriert sind und ein selbstsigniertes Zertifikat, nicht aber `ADDITIONAL_IMAGE_REGISTRY_CA_CERTIFICATE` verwenden. `ADDITIONAL_IMAGE_REGISTRY`Da 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
Variable	Verwaltungscluster-YAML	Arbeitslastcluster-YAML	Beschreibung
`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_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_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_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, das zum Zuweisen von CSI-Speicher in einer Umgebung mit mehreren Datencentern oder Hostclustern verwendet wird. Siehe Bereitstellen eines Clusters mit Regions- und Zonen-Tags für CSI
`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, das zum Zuweisen von CSI-Speicher in einer Umgebung mit mehreren Datencentern oder Hostclustern verwendet wird. Siehe Bereitstellen eines Clusters mit Regions- und Zonen-Tags für CSI

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
Variable	Verwaltungscluster-YAML	Arbeitslastcluster-YAML	Beschreibung
`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
Variable	Verwaltungscluster-YAML	Arbeitslastcluster-YAML	Beschreibung
`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.
`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.
`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
Variable	Verwaltungscluster-YAML	Arbeitslastcluster-YAML	Beschreibung
`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
Variable	Verwaltungscluster-YAML	Arbeitslastcluster-YAML	Beschreibung
`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
Variable	Verwaltungscluster-YAML	Arbeitslastcluster-YAML	Beschreibung
`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
Variable	Verwaltungscluster-YAML	Arbeitslastcluster-YAML	Beschreibung
`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
Variable	Verwaltungscluster-YAML	Arbeitslastcluster-YAML	Beschreibung
`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”`