Variablenreferenz für Konfigurationsdatei

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

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

CLUSTER_NAME: my-cluster

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

Gemeinsame Variablen für alle Zielplattformen

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

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

Für Verwaltungscluster: Legen Sie zum Aktivieren oidc oder ldap fest. Dabei sind zusätzliche OIDC- oder LDAP-Einstellungen erforderlich. Diese sind in den Tabellen für Identitätsanbieter – OIDC und LDAP – aufgeführt (siehe unten).
Sie können diese Variable auslassen oder auf none setzen, um die Identitätsverwaltung zu deaktivieren. Es wird dringend empfohlen, die Identitätsverwaltung für Produktionsbereitstellungen zu aktivieren.
Hinweis Sie müssen OIDC- oder LDAP-Einstellungen in der Konfigurationsdatei für Arbeitslastcluster konfigurieren.

INFRASTRUCTURE_PROVIDER Erforderlich. Legen Sie als Einstellung vsphere, aws, azure oder tkg-service-vsphere fest.
NAMESPACE Optional; ist standardmäßig default, um Arbeitslastcluster in einem Namespace mit dem Namen default bereitzustellen.
SERVICE_CIDR Optional; standardmäßig 100.64.0.0/13. Der für die Kubernetes-Dienste zu verwendende CIDR-Bereich. Ändern Sie diesen Wert nur, wenn der empfohlene Standardbereich nicht verfügbar ist.

Identitätsanbieter – OIDC

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

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

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

Identitätsanbieter – LDAP

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

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

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

Knoten-Konfiguration

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

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

Optional. Mit dieser Variablen können Sie festlegen, ob Sie einen angepassten tdnf-Repository-Server mit einem selbstsignierten Zertifikat anstelle des Photon-Standard-tdnf-Repository-Servers verwenden. Geben Sie den Inhalt des Base64-codierten Zertifikats des tdnf-Repository-Servers ein.

Löscht alle Repositorys unter /etc/yum.repos.d/ und veranlasst, dass der TKG-Knoten dem Zertifikat vertraut.

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

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

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

Kubernetes-Optimierung (nur klassenbasierte Cluster)

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

Wichtig

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

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

Automatische Clusterskalierung

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

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

Proxy-Konfiguration

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

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

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

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

Variable Kann festgelegt werden in… Beschreibung
Verwaltungscluster-YAML Arbeitslastcluster-YAML
TKG_HTTP_PROXY_ENABLED

Optional. Um ausgehenden HTTP(S)-Datenverkehr vom Verwaltungscluster an einen Proxy zu senden, z. B. in einer Umgebung mit Internetbeschränkungen, setzen Sie diese Variable auf true.

TKG_HTTP_PROXY

Optional. Legen Sie diese Variable fest, wenn Sie einen Proxy konfigurieren möchten. Setzen Sie sie auf "“, um die Proxy-Konfiguration für einen einzelnen Cluster zu deaktivieren. Nur anwendbar, wenn TKG_HTTP_PROXY_ENABLED = true. Die URL des HTTP-Proxys im folgenden Format: PROTOCOL://USERNAME:PASSWORD@FQDN-OR-IP:PORT. Dabei gilt:

  • Erforderlich. PROTOCOL ist http.
  • Optional. USERNAME und PASSWORD sind Benutzername und Ihr Kennwort für den HTTP-Proxy. Geben Sie diese mit an, wenn der Proxy eine Authentifizierung erfordert.
  • Erforderlich. FQDN-OR-IP und PORT sind der FQDN bzw. die IP-Adresse und die Portnummer des HTTP-Proxys.

Beispiel: http://user:[email protected]:1234 oder http://myproxy.com:1234. Wenn Sie TKG_HTTP_PROXY festlegen, müssen Sie TKG_HTTPS_PROXY ebenfalls festlegen.

TKG_HTTPS_PROXY Optional. Legen Sie diese Variable fest, wenn Sie einen Proxy konfigurieren möchten. Nur anwendbar, wenn TKG_HTTP_PROXY_ENABLED = true. Die URL des HTTPS-Proxys. Sie können diese Variable auf denselben Wert festlegen wie TKG_HTTP_PROXY oder einen anderen Wert angeben. Die URL muss mit http:// beginnen. Wenn Sie TKG_HTTPS_PROXY festlegen, müssen Sie TKG_HTTP_PROXY ebenfalls festlegen.
TKG_NO_PROXY

Optional. Nur anwendbar, wenn TKG_HTTP_PROXY_ENABLED = true.

Ein oder mehrere Netzwerk-CIDRs oder Hostnamen, die den HTTP(S)-Proxy umgehen müssen, sind durch Kommas getrennt und ohne Leerzeichen oder Platzhalterzeichen (*) aufgelistet. Listet die Hostnamensuffixe als .example.com und nicht als *.example.com auf.

Beispiel: .noproxy.example.com,noproxy.example.com,192.168.0.0/24.

Intern hängt Tanzu Kubernetes Grid localhost, 127.0.0.1, die Werte von CLUSTER_CIDR und SERVICE_CIDR, .svc und .svc.cluster.local an den Wert an, der in TKG_NO_PROXY festgelegt wurde. Azure VNET CIDR, 169.254.0.0/16 und 168.63.129.16 werden auch für Bereitstellungen in Azure angehängt. Für vSphere müssen Sie das CIDR von VSPHERE_NETWORK, das die IP-Adresse Ihres Steuerungsebenen-Endpoints enthält, manuell zu TKG_NO_PROXY hinzufügen.

Wenn Sie VSPHERE_CONTROL_PLANE_ENDPOINT auf einen FQDN festlegen, fügen Sie sowohl den FQDN als auch VSPHERE_NETWORK zu TKG_NO_PROXY hinzu.

Wichtiger Hinweis: In Umgebungen, in denen Tanzu Kubernetes Grid hinter einem Proxy ausgeführt wird, ermöglicht TKG_NO_PROXY den VMs im Cluster die direkte Kommunikation mit der Infrastruktur, die dasselbe Netzwerk ausführt, hinter demselben Proxy. Dazu gehören unter anderem Ihre Infrastruktur, OIDC- oder LDAP-Server, Harbor, VMware NSX und NSX Advanced Load Balancer (vSphere). Legen Sie TKG_NO_PROXY fest, um alle Endpoints einzubeziehen, auf die Cluster zugreifen müssen, die aber für Ihre Proxys nicht erreichbar sind.

TKG_PROXY_CA_CERT Optional. Legen Sie fest, ob Ihr Proxyserver ein selbstsigniertes Zertifikat verwendet. Geben Sie das CA-Zertifikat im base64-codierten Format an, z. B. …TKG_PROXY_CA_CERT: “LS0t[]tLS0tLQ==””.
TKG_NODE_SYSTEM_WIDE_PROXY (Tech Preview)

Optional. Übernimmt die folgenden Einstellungen in /etc/environment und /etc/profile:

export HTTP_PROXY=$TKG_HTTP_PROXY
export HTTPS_PROXY=$TKG_HTTPS_PROXY
export NO_PROXY=$TKG_NO_PROXY

Wenn Benutzer per SSH eine Verbindung zum TKG-Knoten herstellen und Befehle ausführen, werden in den Befehlen standardmäßig die definierten Variablen verwendet. Systemd-Prozesse sind davon nicht betroffen.

Antrea-CNI-Konfiguration

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

Variable Kann festgelegt werden in… Beschreibung
Verwaltungscluster-YAML Arbeitslastcluster-YAML
ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD Optional; standardmäßig false. Setzen Sie diese Variable auf true, um die Auslagerung der UDP-Prüfsumme von Antrea zu deaktivieren. Wenn Sie diese Variable auf true setzen, werden bekannte Probleme mit Underlay-Netzwerk- und physischen Netzwerkkartentreibern vermieden.
ANTREA_EGRESS Optional; standardmäßig true. Aktivieren Sie diese Variable, um die SNAT-IP zu definieren, die für den ausgehenden Pod-Datenverkehr im Cluster verwendet wird. Weitere Informationen finden Sie in der Antrea-Dokumentation unter Egress.
ANTREA_EGRESS_EXCEPT_CIDRS Optional. Die CIDR-Bereiche, deren Egresse keine Quellen-Netzwerkadressübersetzung (SNAT) für ausgehenden Pod-Datenverkehr aufweisen. Geben Sie die Anführungszeichen (““) mit an. Beispiel: “10.0.0.0/6”.
ANTREA_ENABLE_USAGE_REPORTING Optional; standardmäßig false. Aktiviert bzw. deaktiviert Nutzungsberichte (Telemetrie).
ANTREA_FLOWEXPORTER Optional; standardmäßig false. Setzen Sie diese Variable auf true, um den Netzwerk-Flow sichtbar zu machen. Die Flow-Exportfunktion fragt die Conntrack-Flows regelmäßig ab und exportiert die Flows als IPFIX-Flow-Datensätze. Weitere Informationen finden Sie in der Antrea-Dokumentation unter Sichtbarkeit des Netzwerkflusses in Antrea in der Antrea-Dokumentation.
ANTREA_FLOWEXPORTER_ACTIVE_TIMEOUT

Optional; standardmäßig “60s”. Diese Variable gibt das Zeitlimit für den aktiven Flow-Export an, d. h. wann eine Zeitüberschreitung eintritt und ein Flow-Datensatz für aktive Flows an den Collector gesendet wird. Geben Sie die Anführungszeichen (””) mit an.

Hinweis: Die gültigen Zeiteinheiten lauten ns, us (oder s), ms, s, m, h.

ANTREA_FLOWEXPORTER_COLLECTOR_ADDRESS Optional. Diese Variable gibt die IPFIX-Collector-Adresse an. Geben Sie die Anführungszeichen (““) mit an. Der Standardwert ist “flow-aggregator.flow-aggregator.svc:4739:tls”. Weitere Informationen finden Sie in der Antrea-Dokumentation unter Sichtbarkeit des Netzwerkflusses in Antrea in der Antrea-Dokumentation.
ANTREA_FLOWEXPORTER_IDLE_TIMEOUT

Optional; standardmäßig “15s”. Diese Variable gibt das Zeitlimit für den inaktiven Flow-Export an, d. h. wann eine Zeitüberschreitung eintritt und ein Flow-Datensatz für inaktive Flows an den Collector gesendet wird. Geben Sie die Anführungszeichen (””) mit an.

Hinweis: Die gültigen Zeiteinheiten lauten ns, us (oder s), ms, s, m, h.

ANTREA_FLOWEXPORTER_POLL_INTERVAL

Optional; standardmäßig “5s”. Diese Variable legt die Häufigkeit der gesicherten Verbindungen aus dem Conntrack-Modul durch den Flow-Exporter fest. Geben Sie die Anführungszeichen (““) mit an.

Hinweis: Die gültigen Zeiteinheiten lauten ns, us (oder s), ms, s, m, h.

ANTREA_IPAM Optional; standardmäßig false. Setzen Sie diese Variable auf true, um IP-Adressen aus IPPools zuzuteilen. Der gewünschte Satz von IP-Bereichen, optional bei VLANs, wird mit der CRD IPPool definiert. Weitere Informationen finden Sie in der Antrea-Dokumentation unter Antrea-IPAM-Funktionen.
ANTREA_KUBE_APISERVER_OVERRIDE Optional. Geben Sie die Adresse des Kubernetes-API-Servers an. Weitere Informationen finden Sie in der Antrea-Dokumentation unter Entfernen von kube-proxy.
ANTREA_MULTICAST Optional; standardmäßig false. Setzen Sie diese Variable auf true, um Multicast-Datenverkehr innerhalb des Clusternetzwerks (zwischen Pods) und zwischen dem externen Netzwerk und dem Clusternetzwerk zu ermöglichen.
ANTREA_MULTICAST_INTERFACES Optional. Die Namen der Schnittstelle auf Knoten, die zur Weiterleitung von Multicast-Datenverkehr verwendet werden. Geben Sie die Anführungszeichen (””) mit an. Beispiel: “eth0”.
ANTREA_NETWORKPOLICY_STATS Optional; standardmäßig true. Aktivieren Sie diese Variable, um NetworkPolicy-Statistiken zu erfassen. Die statistischen Daten enthalten die Gesamtzahl der Sitzungen, Pakete und Bytes, die von einer NetworkPolicy zugelassen oder verweigert werden.
ANTREA_NO_SNAT Optional; standardmäßig false. Setzen Sie diese Variable auf true, um die Quell-Netzwerkadressübersetzung (Source Network Address Translation, SNAT) zu deaktivieren.
ANTREA_NODEPORTLOCAL Optional; standardmäßig true. Setzen Sie diese Variable auf false, um den NodePortLocal-Modus zu deaktivieren. Weitere Informationen finden Sie in der Antrea-Dokumentation unter NodePortLocal (NPL).
ANTREA_NODEPORTLOCAL_ENABLED Optional. Setzen Sie diese Variable auf true, um den NodePortLocal-Modus zu aktivieren, wie in der Antrea-Dokumentation unter NodePortLocal (NPL) beschrieben.
ANTREA_NODEPORTLOCAL_PORTRANGE Optional; standardmäßig 61000-62000. Weitere Informationen finden Sie in der Antrea-Dokumentation unter NodePortLocal (NPL).
ANTREA_POLICY Optional; standardmäßig true. Aktiviert bzw. deaktiviert die Antrea-native Richtlinien-API, bei der es sich um Antrea-spezifische Richtlinien-CRDs handelt. Darüber hinaus bleibt die Implementierung von Kubernetes-Netzwerkrichtlinien aktiv, wenn diese Variable aktiviert ist. Informationen zur Verwendung von Netzwerkrichtlinien finden Sie in der Antrea-Dokumentation unter Antrea-Netzwerkrichtlinien-CRDs.
ANTREA_PROXY Optional; standardmäßig false. Aktiviert bzw. deaktiviert AntreaProxy, um kube-proxy für den Pod-zu-ClusterIP-Dienstdatenverkehr zu ersetzen. Dies verbessert die Leistung und verringert die Latenz. Beachten Sie, dass kube-proxy weiterhin für andere Arten von Dienstdatenverkehr verwendet wird. Weitere Informationen zur Verwendung von Proxys finden Sie in der Antrea-Dokumentation unter AntreaProxy.
ANTREA_PROXY_ALL Optional; standardmäßig false. Aktiviert bzw. deaktiviert AntreaProxy, um den gesamten Dienstdatenverkehr einschließlich NodePort-, LoadBalancer- und ClusterIP-Datenverkehr zu verarbeiten. Um kube-proxy durch AntreaProxy zu ersetzen, muss ANTREA_PROXY_ALL aktiviert sein. Weitere Informationen zur Verwendung von Proxys finden Sie in der Antrea-Dokumentation unter AntreaProxy.
ANTREA_PROXY_LOAD_BALANCER_IPS Optional; standardmäßig true. Setzen Sie diese Variable auf false, um den Datenverkehr für den Lastausgleich an den externen Lastausgleichsdienst weiterzuleiten.
ANTREA_PROXY_NODEPORT_ADDRS Optional. Die IPv4- oder IPv6-Adresse für NodePort. Geben Sie die Anführungszeichen (““) mit an.
ANTREA_PROXY_SKIP_SERVICES Optional. Ein Array von Zeichenfolgenwerten, mit denen eine Liste der Dienste angegeben werden kann, die AntreaProxy ignorieren soll. Für den Datenverkehr zu diesen Diensten wird kein Lastausgleich durchgeführt. Geben Sie die Anführungszeichen (””) mit an. Gültige Werte sind beispielsweise eine gültige ClusterIP (z. B. 10.11.1.2) oder ein Dienstname mit einem Namespace (z. B. kube-system/kube-dns). Weitere Informationen finden Sie in der Antrea-Dokumentation unter Besondere Anwendungsfälle.
ANTREA_SERVICE_EXTERNALIP Optional; standardmäßig false. Setzen Sie diese Variable auf true, damit ein Controller externe IPs aus einer ExternalIPPool-Ressource für Dienste des Typs LoadBalancer zuteilt. Weitere Informationen zum Implementieren von Diensten des Tys LoadBalancer finden Sie in der Antrea-Dokumentation unter Dienst vom Typ „LoadBalancer“.
ANTREA_TRACEFLOW Optional; standardmäßig true. Informationen zur Verwendung von Traceflow finden Sie in der Antrea-Dokumentation im Traceflow-Benutzerhandbuch.
ANTREA_TRAFFIC_ENCAP_MODE

Optional; standardmäßig “encap”. Legen Sie als Einstellung noEncap, hybrid oder NetworkPolicyOnly fest. Informationen zur Verwendung der Datenverkehrsmodi NoEncap und Hybrid finden Sie in der Antrea-Dokumentation unter NoEncap- und Hybrid-Datenverkehrsmodi von Antrea.

Hinweis: Für die Modi noEncap und hybrid ist eine spezielle Konfiguration des Knotennetzwerks erforderlich, um zu verhindern, dass sie die Pod-Kommunikation zwischen Knoten deaktivieren.

Der noEncap-Modus wird nur unter vSphere unterstützt und kann die Pod-Kommunikation zwischen Knoten deaktivieren. Legen Sie für ANTREA_TRAFFIC_ENCAP_MODE in Clustern, in denen Pods knotenübergreifend kommunizieren müssen, nicht die Einstellung noEncap fest.

ANTREA_TRANSPORT_INTERFACE Optional. Der Name der Schnittstelle auf dem Knoten, der für das Tunneling oder Routing des Datenverkehrs verwendet wird. Geben Sie die Anführungszeichen (““) mit an. Beispiel: “eth0”.
ANTREA_TRANSPORT_INTERFACE_CIDRS Optional. Die Netzwerk-CIDRs der Schnittstelle auf dem Knoten, die für das Tunneling oder Routing des Datenverkehrs verwendet wird. Geben Sie die Anführungszeichen (””) mit an. Beispiel: “10.0.0.2/24”.

Maschinenintegritätsprüfungen

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

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

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

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

Konfiguration von privaten Image-Registrierungen

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

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

vSphere

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

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

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

Kube-VIP-Lastausgleichsdienst (Tech Preview)

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

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

NSX Advanced Load Balancer

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

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

NSX-Pod-Routing

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

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

Knoten-IPAM

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

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

GPU-fähige Cluster

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

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

AWS

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

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

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

Microsoft Azure

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

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

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

Vorrang für Konfigurationswerte

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

Verarbeitung von Layern, sortiert in absteigender Reihenfolge Quelle Beispiele
1. In der Schnittstelle des Installationsprogramms festgelegte Konfigurationsvariablen für den Verwaltungscluster In die von der Option –ui gestartete Schnittstelle des Installationsprogramms eingegeben und in die Clusterkonfigurationsdateien geschrieben. Dateien werden standardmäßig im Verzeichnis ~/.config/tanzu/tkg/clusterconfigs/ gespeichert. Dropdown-Menü für den Worker-Knoteninstanztyp mit Auswahl „Standard_D2s_v3“
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”

check-circle-line exclamation-circle-line close-line
Scroll to top icon