Versionshinweise zu VMware Tanzu Kubernetes Grid v2.1

Sofern nicht anders angegeben, gelten diese Versionshinweise für alle v2.1.x-Patch-Versionen von Tanzu Kubernetes Grid (TKG).

TKG v2.1 wird als herunterladbares Tanzu CLI-Paket verteilt, das einen eigenständigen TKG-Verwaltungscluster mit Version bereitstellt. TKG v2.1 ist die erste Version von TKG, die das Erstellen und Verwalten von klassenbasierten Afrbeitslastclustern mit einem eigenständigen Verwaltungscluster unterstützt, der in mehreren Infrastrukturen ausgeführt werden kann, einschließlich vSphere, AWS und Azure.

Tanzu Kubernetes Grid v2.x und vSphere with Tanzu Supervisor in vSphere 8

Wichtig
Der vSphere with Tanzu-Supervisor in vSphere 8.0.1c oder höher führt TKG v2.2 aus. Frühere Versionen von vSphere 8 führen TKG v2.0 aus, das nicht unabhängig von Supervisor veröffentlicht wurde. Eigenständige Verwaltungscluster unter TKG 2.x sind ab TKG 2.1 verfügbar. Spätere TKG-Versionen werden in künftigen vSphere-Update-Versionen in Supervisor eingebettet sein. Folglich stimmt die in die aktuelle Version von vSphere with Tanzu eingebettete Version von TKG zu einem bestimmten Zeitpunkt möglicherweise nicht mit der von Ihnen verwendeten eigenständigen TKG-Version überein. Die Versionen von Tanzu CLI, die mit allen TKG v2.x-Versionen kompatibel sind, werden jedoch für die Verwendung mit Supervisor in allen Versionen von vSphere 8 vollständig unterstützt.

Tanzu Kubernetes Grid v2.1 und vSphere with Tanzu in vSphere 7

Vorsicht
Die Versionen der Tanzu CLI, die mit TKG 2.x und mit dem vSphere with Tanzu Supervisor in vSphere 8 kompatibel sind, sind nicht mit dem Supervisor-Cluster in vSphere 7 kompatibel. Um die Tanzu CLI mit einem vSphere with Tanzu Supervisor-Cluster auf vSphere 7 zu verwenden, verwenden Sie die Tanzu CLI-Version von TKG v1.6. Um die Versionen von Tanzu CLI zu verwenden, die mit TKG 2.x mit Supervisor kompatibel sind, führen Sie ein Upgrade auf vSphere 8 durch. Sie können einen eigenständigen TKG 2.x-Verwaltungscluster auf vSphere 7 bereitstellen, wenn der vSphere with Tanzu Supervisor-Cluster nicht vorhanden ist. Informationen zur Kompatibilität zwischen der Tanzu CLI und VMware-Produkten finden Sie in der Tanzu CLI-Dokumentation.

Neuheiten

Tanzu Kubernetes Grid v2.1.x beinhaltet die folgenden neuen Funktionen.

Tanzu Kubernetes Grid v2.1.1

Neue Funktionen in Tanzu Kubernetes Grid v2.1.1:

Unterstützt die Verwendung von NSX Advanced Load Balancer v22.1.2 oder höher auf vSphere 8 mit einem eigenständigen TKG-Verwaltungscluster und dessen Arbeitslastclustern.
Sie können die FIPS-Version von TKG v2.1.1 installieren. Weitere Informationen finden Sie unter FIPS-fähige Versionen.
Konfigurationsvariablen:
- Maschinenintegritätsprüfungen: MHC_MAX_UNHEALTHY_CONTROL_PLANE und MHC_MAX_UNHEALTHY_WORKER_NODE. Weitere Informationen finden Sie unter Maschinenintegritätsprüfungen in der Konfigurationsdatei-Variablenreferenz.
- Unterstützung für tdnf-Server mit benutzerdefiniertem Zertifikat: CUSTOM_TDNF_REPOSITORY_CERTIFICATE (Tech Preview). Weitere Informationen finden Sie unter Knotenkonfiguration in der Konfigurationsdatei-Variablenreferenz.
- Unterstützung für Proxy-Einstellungen auf Knotenebene: TKG_NODE_SYSTEM_WIDE_PROXY (Tech Preview). Weitere Informationen finden Sie unter Proxy-Konfiguration in der Konfigurationsdatei-Variablenreferenz.

Tanzu Kubernetes Grid v2.1.0

Neue Funktionen in Tanzu Kubernetes Grid v2.1.0:

TKG 2.x-Unterstützung: Konfigurieren und erstellen Sie klassenbasierte Cluster auf vSphere, AWS oder Azure mit einem eigenständigen Verwaltungscluster, wie unter Typen von Arbeitslastclustern beschrieben.
Sie können die FIPS-Version von TKG v2.1.0 installieren. Weitere Informationen finden Sie unter FIPS-fähige Versionen.
Tanzu CLI:
- Das package-Plug-In verwendet standardmäßig Befehle im kctrl-Stil. Weitere Informationen finden Sie unter tanzu package in der Tanzu CLI-Befehlsreferenz.
- Die Befehle download-bundle und upload-bundle des Plug-Ins isolated-cluster rufen alle von TKG benötigten Container-Images ab und übertragen sie, wie unter Vorbereiten einer Umgebung mit Internetbeschränkungen beschrieben.
- Die Optionen -A und --all-namespaces für tanzu cluster list schließen Cluster in allen Namespaces des Verwaltungsclusters ein, für die der Benutzer über Anzeigeberechtigungen oder höher verfügt, nicht nur den Standard-Namespace.
- Mit der Befehlsgruppe context können Benutzer Kontexte für die Tanzu CLI festlegen und verwalten. Dazu gehören der Zielserver und die anzuwendende kubeconfig. Weitere Informationen finden Sie unter tanzu context in der Tanzu CLI-Befehlsreferenz.
  - In zukünftigen Versionen wird der Befehl tanzu login zugunsten von tanzu context-Befehlen als veraltet angesehen.
- Die Kategorie Target für Plug-Ins ändert das CLI-Verhalten und fügt Funktionen hinzu, die für die zukünftige Verwendung reserviert sind, wie unter Verhaltensänderungen in Tanzu Kubernetes Grid v2.1 weiter unten beschrieben.
- Die Funktion auto-apply-generated-clusterclass-based-configuration wendet die von der Tanzu CLI generierte klassenbasierte Clusterkonfiguration automatisch an, wenn Sie eine Legacy-Clusterkonfigurationsdatei an tanzu cluster create übergeben. Die Funktion ist standardmäßig auf false festgelegt. Weitere Informationen finden Sie unter Funktionen in Tanzu CLI-Architektur und -Konfiguration.
- Mit der Funktion allow-legacy-cluster können Sie planbasierte Cluster erstellen. Die Funktion ist standardmäßig auf false festgelegt. Weitere Informationen finden Sie unter Funktionen in Tanzu CLI-Architektur und -Konfiguration.
- Die Befehle tanzu mc credentials update und tanzu cluster credentials update fügen Optionen für Azure hinzu. Dazu gehören --azure-client-id, --azure-client-secret und --azure-tenant-id.
Die folgenden Clusterkonfigurationsvariablen werden für klassenbasierte Cluster und eigenständige Verwaltungscluster unterstützt, wie in Variablenreferenz für Konfigurationsdatei beschrieben:
- Knoten-Konfiguration: CONTROL_PLANE_NODE_LABELS, CONTROL_PLANE_NODE_NAMESERVERS, CONTROL_PLANE_NODE_SEARCH_DOMAINS, WORKER_NODE_NAMESERVERS, WORKER_NODE_SEARCH_DOMAINS
- ExtraArgs-Eigenschaft: APISERVER_EXTRA_ARGS, CONTROLPLANE_KUBELET_EXTRA_ARGS, ETCD_EXTRA_ARGS, KUBE_CONTROLLER_MANAGER_EXTRA_ARGS, KUBE_SCHEDULER_EXTRA_ARGS, WORKER_KUBELET_EXTRA_ARGS
- Ratenbegrenzung und Synchronisierung: NTP_SERVERS, APISERVER_EVENT_RATE_LIMIT_CONF_BASE64
Cluster können VM-Zertifikate des Knotens der Steuerungsebene automatisch verlängern. Weitere Informationen finden Sie unter Automatische Verlängerung des Zertifikats von Steuerungsebenen-Knoten.
(vSphere) Sie können Arbeitslastcluster mit mehreren Betriebssystemen bereitstellen, auf denen sowohl Windows- als auch Linux-basierte Worker-Knoten ausgeführt werden, wie unter Bereitstellen eines Arbeitslastclusters mit mehreren Betriebssystemen beschrieben. In dieser Version werden Windows-Arbeitslastcluster durch die Arbeitslastcluster mit mehreren Betriebssystemen ersetzt. Weitere Informationen finden Sie unter Verhaltensänderungen in Tanzu Kubernetes Grid v2.1.
- Sie können Arbeitslastcluster mit mehreren Betriebssystemen mit Workern in mehreren Verfügbarkeitsbereichen bereitstellen (siehe Beschreibung unter Bereitstellen von Arbeitslastclustern in mehreren Verfügbarkeitsbereichen (vSphere Tech Preview)).
(vSphere) Klassenbasierte Arbeitslastcluster können mit clusterinterner IP-Adressverwaltung (IP Address Management, IPAM) über einen zugeteilten IP-Pool konfiguriert werden, sodass DHCP-Reservierungen nicht konfiguriert werden müssen, wenn sich die Knotenanzahl oder die Instanzen ändern.
(vSphere) Machine-Objektbezeichnungen für Clusterknoten geben die Adresse ihres ESXi-Hosts an, um die Ausführung spezifischer Arbeitslasten auf spezieller Hardware mithilfe von nodeSelector zu unterstützen.
(vSphere) Ubuntu-OVA-Images verwenden den UEFI(Unified Extensible Firmware Interface)-Modus zum Starten, wodurch der herkömmliche BIOS-Firmware-Modus ersetzt wird. Der UEFI-Modus ermöglicht GPU(Graphic Processing Unit)-Arbeitslasten und verbessert die Knotensicherheit. Weitere Informationen zu UEFI auf Ubuntu finden Sie unter UEFI in der Ubuntu-Dokumentation.
Sie können Kube-VIP als L4-LoadBalancer-Dienst für Arbeitslasten verwenden, siehe Kube-VIP-Lastausgleichsdienst (Tech Preview).
Sie können Einzelknoten-Arbeitslastcluster, die sowohl gehostete Arbeitslasten als auch die Steuerungsebeneninfrastruktur auf einem einzelnen ESXi-Host ausführen, für Edge-Anwendungen bereitstellen, wie unter Einzelknotencluster auf vSphere (Tech Preview) beschrieben.
- Sie können minimale Einzelknotencluster auf der Grundlage von tiny TKrs bereitstellen, die Ihre Stellfläche auf ein Minimum reduzieren.
Sie können die Clusterinfrastruktur sichern und bereitstellen, wie unter Sichern und Wiederherstellen der Verwaltungs- und Arbeitslastcluster-Infrastruktur (Tech Preview) beschrieben.
Unterstützt PSA(Pod Security Admission)-Controller zum Ersetzen von Pod-Sicherheitsrichtlinien, wie in Namespaces beschrieben, siehe Zugangssteuerung für Pod-Sicherheit (Tech Preview).

Unterstützte Kubernetes-Versionen in Tanzu Kubernetes Grid v2.1

Jede Version von Tanzu Kubernetes Grid bietet Unterstützung für die Kubernetes-Version des Verwaltungsclusters sowie zusätzliche Kubernetes-Versionen, die als Tanzu Kubernetes-Releases (TKrs) verteilt werden.

Jede Version von Tanzu Kubernetes Grid unterstützt alle TKr-Versionen der vorherigen beiden Nebenlinien von Kubernetes, mit Ausnahme derjenigen, die unter Bekannte Probleme erfasst sind. Beispielsweise unterstützt TKG v2.1.x die unten aufgeführten Kubernetes-Versionen v1.23.x und v1.22.x, aber nicht v1.21.x oder früher.

Version von Tanzu Kubernetes Grid	Kubernetes-Version des Verwaltungsclusters	Bereitgestellte Kubernetes-Versionen (TKr)
2.1.1	1.24.10	1.24.10, 1.23.16, 1.22.17
2.1.0	1.24.9	1.24.9, 1.23.15, 1.22.17
1.6.1	1.23.10	1.23.10, 1.22.13, 1.21.14
1.6.0	1.23.8	1.23.8, 1.22.11, 1.21.14
1.5.4	1.22.9	1.22.9, 1.21.11, 1.20.15
1.5.3	1.22.8	1.22.8, 1.21.11, 1.20.15
1.5.2, 1.5.1, 1.5.0	1.22.5	1.22.5, 1.21.8, 1.20.14

Produkt-Snapshot für Tanzu Kubernetes Grid v2.1

Tanzu Kubernetes Grid v2.1 unterstützt die folgenden Infrastrukturplattformen und Betriebssysteme sowie Clustererstellung und -verwaltung, Netzwerk, Speicher, Authentifizierung, Sicherung und Migration und Beobachtbarkeitskomponenten. Die in Klammern aufgeführten Komponentenversionen sind in Tanzu Kubernetes Grid v2.1.1 enthalten. Weitere Informationen finden Sie unter Komponentenversionen.

	vSphere	AWS	Azure
Infrastrukturplattform	vSphere 6.7U3 vSphere 7 vSphere 8 VMware Cloud on AWS** Azure VMware Solution Oracle Cloud VMware Solution (OCVS) Google Cloud VMware Engine (GCVE)	Natives AWS	Natives Azure
CLI, API und Paketinfrastruktur	Tanzu Framework v0.28.1
Clustererstellung und -verwaltung	Kerncluster-API (v1.2.8), Cluster-API-Anbieter vSphere (v1.5.3)	Kerncluster-API (v1.2.8), Cluster-API-Anbieter AWS (v2.0.2)	Kerncluster-API (v1.2.8), Cluster-API-Anbieter Azure (v1.6.3)
Mit TKG verteiltes Kubernetes-Knotenbetriebssystem	Photon OS 3, Ubuntu 20.04	Amazon Linux 2, Ubuntu 20.04	Ubuntu 18.04, Ubuntu 20.04
Eigenes Image erstellen	Photon OS 3, Red Hat Enterprise Linux 7*** und 8, Ubuntu 18.04, Ubuntu 20.04, Windows 2019	Amazon Linux 2, Ubuntu 18.04, Ubuntu 20.04	Ubuntu 18.04, Ubuntu 20.04
Container-Laufzeit	Containerd (v1.6.6)
Containernetzwerk	Antrea (v1.7.2), Calico (v3.24.1)
Container-Registrierung	Harbor (v2.6.3)
Ingress	NSX Advanced Load Balancer Essentials und Avi-Controller **** (v21.1.3–v21.1.6, v22.1.1, v22.1.2), Contour (v1.22.3)	Contour (v1.22.3)	Contour (v1.22.3)
Speicher	vSphere Container Storage Interface (v2.5.2*) und vSphere Cloud Native Storage	Amazon EBS CSI-Treiber (v1.8.0) und Cloud-Anbieter in der Struktur	Azure Disk CSI-Treiber (v1.19.0), Azure File CSI-Treiber (v1.21.0) und Cloud-Anbieter in der Struktur
Authentifizierung	OIDC über Pinniped (v0.12.1), LDAP über Pinniped (v0.12.1) und Dex
Beobachtbarkeit	Fluent Bit (v1.9.5), Prometheus (v2.37.0), Grafana (v7.5.17)
Sicherung und Migration	Velero (v1.9.5)

* Version von vsphere_csi_driver. Eine vollständige Liste der vSphere Container Storage Interface-Komponenten, die in der Version Tanzu Kubernetes Grid v1.6 enthalten sind, finden Sie unter Komponentenversionen.

** Eine Liste der VMware Cloud on AWS SDDC-Versionen, die mit dieser Version kompatibel sind, finden Sie in der VMware-Produkt-Interoperabilitätsmatrix.

*** Tanzu Kubernetes Grid v1.6 ist die letzte Version, die die Erstellung von Red Hat Enterprise Linux 7-Images unterstützt.

**** Um unter vSphere 8 NSX Advanced Load Balancer mit einem eigenständigen TKG-Verwaltungscluster und dessen Arbeitslastclustern zu verwenden, benötigen Sie NSX ALB v22.1.2 oder höher und TKG v2.1.1 oder höher.

Eine vollständige Liste der Kubernetes-Versionen, die im Lieferumfang von Tanzu Kubernetes Grid v2.1 enthalten sind, finden Sie unter Unterstützte Kubernetes-Versionen in Tanzu Kubernetes Grid v2.1 weiter oben.

Komponentenversionen

Die Tanzu Kubernetes Grid v2.1.x-Versionen enthalten die folgenden Softwarekomponentenversionen:

Komponente	TKG v2.1.1	TKG v2.1.0
aad-pod-identity	v1.8.13+vmware.2^*	v1.8.13+vmware.1^*
addons-manager	v2.1+vmware.1-tkg.3	v2.1+vmware.1-tkg.3
ako-operator	v1.7.0+vmware.3	v1.7.0+vmware.3^*
alertmanager	v0.24.0+vmware.2^*	v0.24.0+vmware.1
antrea	v1.7.2+vmware.1-advanced	v1.7.2+vmware.1-advanced^*
aws-ebs-csi-driver	v1.8.0+vmware.2	v1.8.0+vmware.2^*
azuredisk-csi-driver	v1.19.0+vmware.1	v1.19.0+vmware.1^*
azurefile-csi-driver^*	v1.21.0+vmware.1	v1.21.0+vmware.1
calico_all	v3.24.1+vmware.1	v3.24.1+vmware.1^*
capabilities-package	v0.28.1-dev-capabilities^*	v0.28.0-dev-capabilities^*
carvel-secretgen-controller	v0.11.2+vmware.1	v0.11.2+vmware.1^*
cloud-provider-azure	v1.1.26+vmware.1, v1.23.23+vmware.1, v1.24.10+vmware.1	v1.1.26+vmware.1^, v1.23.23+vmware.1^, v1.24.9+vmware.1^*
cloud_provider_vsphere	v1.24.3+vmware.1	v1.24.3+vmware.1^*
cluster-api-provider-azure	v1.6.3_vmware.1^*	v1.6.1_vmware.1^*
cluster_api	v1.2.8+vmware.1	v1.2.8+vmware.1^*
cluster_api_aws	v2.0.2+vmware.1	v2.0.2+vmware.1^*
cluster_api_vsphere	v1.5.3+vmware.1l^*	v1.5.1+vmware.1l^*
cni_plugins	v1.1.1+vmware.18^*	v1.1.1+vmware.16^*
configmap-reload	v0.7.1+vmware.2^*	v0.7.1+vmware.1
containerd	v1.6.6+vmware.3^*	v1.6.6+vmware.1^*
contour	v1.22.3+vmware.1	v1.22.3+vmware.1^*
coredns	v1.8.6+vmware.17^*	v1.8.6+vmware.15^*
crash-diagnostics	v0.3.7+vmware.6	v0.3.7+vmware.6^*
cri_tools	v1.23.0+vmware.8^*	v1.23.0+vmware.7^*
csi_attacher	v3.5.0+vmware.1, v3.4.0+vmware.1, v3.3.0+vmware.1	v3.5.0+vmware.1^*, v3.4.0+vmware.1, v3.3.0+vmware.1
csi_livenessprobe	v2.7.0+vmware.1, v2.6.0+vmware.1, v2.5.0+vmware.1, v2.4.0+vmware.1	v2.7.0+vmware.1^*, v2.6.0+vmware.1, v2.5.0+vmware.1, v2.4.0+vmware.1
csi_node_driver_registrar	v2.5.1+vmware.1, v2.5.0+vmware.1, v2.3.0+vmware.1	v2.5.1+vmware.1, v2.5.0+vmware.1, v2.3.0+vmware.1
csi_provisioner	v3.2.1+vmware.1, v3.1.0+vmware.2, v3.0.0+vmware.1	v3.2.1+vmware.1^*, v3.1.0+vmware.2, v3.0.0+vmware.1
dex	v2.35.3+vmware.2	v2.35.3+vmware.2^*
Envoy	v1.23.3+vmware.2	v1.23.3+vmware.2^*
external-dns	v0.12.2+vmware.4	v0.12.2+vmware.4^*
external-snapshotter	v6.0.1+vmware.1, v5.0.1+vmware.1	v6.0.1+vmware.1, v5.0.1+vmware.1
etcd	v3.5.6+vmware.6^*	v3.5.6+vmware.3^*
fluent-bit	v1.9.5+vmware.1	v1.9.5+vmware.1^*
gangway	v3.2.0+vmware.2	v3.2.0+vmware.2
grafana	v7.5.17+vmware.1^*	v7.5.16+vmware.1
guest-cluster-auth-service	v1.2.0^*	v1.1.0^*
harbor	v2.6.3+vmware.1	v2.6.3+vmware.1^*
image-builder	v0.1.13+vmware.2	v0.1.13+vmware.2^*
image-builder-resource-bundle	v1.24.10+vmware.1-tkg.1^*	v1.24.9+vmware.1-tkg.1^*
imgpkg	v0.31.1+vmware.1	v0.31.1+vmware.1^*
jetstack_cert-manager	v1.10.1+vmware.1	v1.10.1+vmware.1^*
k8s-sidecar	v1.15.6+vmware.3^, v1.12.1+vmware.5^	v1.15.6+vmware.2, v1.12.1+vmware.3^*
k14s_kapp	v0.53.2+vmware.1	v0.53.2+vmware.1^*
k14s_ytt	v0.43.1+vmware.1	v0.43.1+vmware.1^*
kapp-controller	v0.41.5+vmware.1, v0.38.5+vmware.2	v0.41.5+vmware.1^, v0.38.5+vmware.2^
kbld	v0.35.1+vmware.1	v0.35.1+vmware.1^*
kube-state-metrics	v2.6.0+vmware.2^*	v2.6.0+vmware.1^*
kube-vip	v0.5.7+vmware.1	v0.5.7+vmware.1^*
kube-vip-cloud-provider^*	v0.0.4+vmware.2	v0.0.4+vmware.2
kube_rbac_proxy	v0.11.0+vmware.2	v0.11.0+vmware.2
kubernetes	v1.24.10+vmware.1^*	v1.24.9+vmware.1^*
kubernetes-csi_external-resizer	v1.4.0+vmware.1, v1.3.0+vmware.1	v1.4.0+vmware.1^*, v1.3.0+vmware.1
kubernetes-sigs_kind	v1.24.10+vmware.1-tkg.1_v0.17.0^*	v1.24.9+vmware.1-tkg.1_v0.17.0^*
kubernetes_autoscaler	v1.24.0+vmware.1	v1.24.0+vmware.1^*
load-balancer-and-ingress-service (AKO)	v1.8.2+vmware.1	v1.8.2+vmware.1^*
metrics-server	v0.6.2+vmware.1	v0.6.2+vmware.1^*
multus-cni	v3.8.0+vmware.2	v3.8.0+vmware.2^*
pinniped	v0.12.1+vmware.1-tkg.1	v0.12.1+vmware.1-tkg.1
pinniped-post-deploy	v0.12.1+vmware.2-tkg.3	v0.12.1+vmware.2-tkg.3^*
prometheus	v2.37.0+vmware.2^*	v2.37.0+vmware.1^*
prometheus_node_exporter	v1.4.0+vmware.2^*	v1.4.0+vmware.1^*
pushgateway	v1.4.3+vmware.2^*	v1.4.3+vmware.1
sonobuoy	v0.56.13+vmware.1	v0.56.13+vmware.1^*
standalone-plugins-paket	v0.28.1-dev-standalone-plugins^*	v0.28.1-dev-standalone-plugins^*
tanzu-framework	v0.28.1^*	v0.28.0^*
tanzu-framework-addons	v0.28.1^*	v0.28.0^*
tanzu-framework-management-packages	v0.28.1-tf^*	v0.28.0-tf^*
tkg-bom	v2.1.1^*	v2.1.0^*
tkg-core-packages	v1.24.10+vmware.1-tkg.1^*	v1.24.9+vmware.1-tkg.1^*
tkg-standard-packages	v2.1.1^*	v2.1.0^*
tkg-storageclass-package	v0.28.1-tkg-storageclass^*	v0.28.0-tkg-storageclass^*
tkg_telemetry	v2.1.1+vmware.1^*	v2.1.0+vmware.1^*
velero	v1.9.5+vmware.1	v1.9.5+vmware.1^*
velero-mgmt-cluster-plugin^*	v0.1.0+vmware.1	v0.1.0+vmware.1
velero-plugin-for-aws	v1.5.3+vmware.1	v1.5.3+vmware.1^*
velero-plugin-for-csi	v0.3.3+vmware.1	v0.3.3+vmware.1^*
velero-plugin-for-microsoft-azure	v1.5.3+vmware.1	v1.5.3+vmware.1^*
velero-plugin-for-vsphere	v1.4.2+vmware.1	v1.4.2+vmware.1^*
vendir	v0.30.1+vmware.1	v0.30.1+vmware.1^*
vsphere_csi_driver	v2.6.2+vmware.2	v2.6.2+vmware.2^*
whereabouts	v0.5.4+vmware.1	v0.5.4+vmware.1^*

^* Weist auf einen neuen Komponenten- oder Versions-Bump seit der vorherigen Version hin. TKG v2.1.0 ist älter als v2.1.1, und v1.6.1 ist älter als v2.1.0.

Um eine vollständige Liste der Versionen der Softwarekomponenten zu erhalten, die im Lieferumfang von TKG v2.1 enthalten sind, rufen Sie mithilfe von imgpkg das Repository-Paket ab und listen Sie dann dessen Inhalt auf. Für TKG v2.1.1 beispielsweise:

imgpkg pull -b projects.registry.vmware.com/tkg/packages/standard/repo:v2.1.1 -o standard-2.1.1
cd standard-2.1.1/packages
tree

In lokalen Stücklistendateien (BOM-Dateien) wie der folgenden sind auch Paketversionen aufgelistet, die aber möglicherweise nicht aktuell sind:

~/.config/tanzu/tkg/bom/tkg-bom-v2.1.yaml
~/.config/tanzu/tkg/bom/tkr-bom-v1.24.10+vmware.1-tkg.1.yaml

Unterstützte Upgrade-Pfade

Im TKG-Upgrade-Pfad folgt v2.1 unmittelbar auf v1.6. TKG v2.0 ist keine herunterladbare Version von TKG: Es handelt sich um die Version von TKG, die im vSphere with Tanzu Supervisor in vSphere 8 eingebettet ist.

Sie können von Tanzu Kubernetes Grid v1.6.x nur ein Upgrade auf v2.1.x durchführen. Wenn Sie ein Upgrade auf Tanzu Kubernetes Grid v2.1.x von einer älteren Version als v1.6.x durchführen möchten, müssen Sie zuerst ein Upgrade auf v1.6.x durchführen.

Beim Upgrade von Kubernetes-Versionen auf Arbeitslastclustern können Sie Nebenversionen nicht überspringen. Beispielsweise können Sie für einen Tanzu Kubernetes-Cluster kein direktes Upgrade von v1.21.x auf v1.23.x durchführen. Sie müssen einen v1.21.x-Cluster auf v1.22.x aktualisieren, bevor Sie das Upgrade des Clusters auf v1.23.x durchführen.

Veröffentlichungsdaten

Tanzu Kubernetes Grid v2.1-Veröffentlichungsdaten sind:

v2.1.0: Donnerstag, 29. Januar 2023
v2.1.1: 21. März 2023

Verhaltensänderungen in Tanzu Kubernetes Grid v2.1

Tanzu Kubernetes Grid v2.1 führt die folgenden neuen Verhaltensweisen im Vergleich zu v1.6.1 ein, der letzten vorherigen Version.

Die Option --include-management-cluster in tanzu cluster list erfordert die Option -A zum Auflisten eines eigenständigen Verwaltungsclusters. Mit der Option -A listet der Befehl Cluster in allen Namespaces auf.
Das package-Plug-In der Tanzu CLI verwendet standardmäßig Befehle im kctrl-Stil. Weitere Informationen finden Sie unter tanzu package with kctrl in der Tanzu CLI-Befehlsreferenz.
- In TKG v1.6 wird das Plug-In package standardmäßig mit deaktiviertem kctrl-Modus ausgeführt, der unten als Legacy-Modus bezeichnet wird.
- Die Befehle des kctrl-Modus und des Legacy-Modus unterscheiden sich folgendermaßen:
  - Zum Erstellen einer Standardwertdatei für die Paketkonfiguration verwenden kctrl-artige tanzu package available get-Befehle das Flag --generate-default-values-file anstelle von --default-values-file-output.
  - Das Flag --create-namespace wird entfernt. Wenn Sie -n oder --namespace verwenden, um einen Ziel-Namespace anzugeben, muss der Namespace bereits vorhanden sein.
  - Das Flag --create wird für package repository update entfernt.
  - Das Flag --package-name wird in --package für package installed create und package install umbenannt.
  - Das Flag --install wird für package installed update entfernt.
  - Das globale Flag --verbose wird entfernt.
  - Die Flags --poll-interval und -poll-timeout werden in --wait-interval und --wait-timeout umbenannt.
  - In der Ausgabe package available get werden die verfügbaren Versionen für das Paket in einer zusätzlichen Tabelle aufgelistet.
  - In der Ausgabe package available list wird die Spalte LATEST-VERSION entfernt, und SHORT-DESCRIPTION wird standardmäßig nicht angezeigt. Verwenden Sie zu Anzeigezwecken das Flag --wide.
  - In der Ausgabe package repository list werden die Spalten REPOSITORY und TAG durch eine Spalte vom Typ SOURCE ersetzt, die sich aus dem Quelltyp (z. B. imgpkg), der Repository-URL und dem Tag zusammensetzt.
- In den Themen unter CLI-verwaltete Pakete in der Dokumentation zu TKG v1.6 erfahren Sie, wie das tanzu package-Plug-In mit deaktiviertem kctrl-Modus funktioniert.
Das Paketrepository tanzu-standard ist auf klassenbasierten Clustern nicht vorinstalliert. Informationen zum Hinzufügen des Paketrepositorys finden Sie unter Hinzufügen eines Paketrepositorys.
Der Erstellungsvorgang des Tanzu CLI-Verwaltungsclusters unterstützt nicht mehr das Erstellen einer neuen VPC. Die Installationsprogramm-Schnittstelle enthält keine Option zum Erstellen einer neuen VPC, und Clusterkonfigurationsdateien unterstützen nicht mehr die AWS_*-Optionen zum Erstellen einer neuen VPC für ein angegebenes CIDR. Wenn Sie eine neue VPC verwenden möchten, müssen Sie vor der Bereitstellung eines eigenständigen Verwaltungsclusters auf AWS eine VPC für Ihre TKG-Bereitstellung mithilfe der AWS-Konsole erstellen.
Die Tanzu CLI verwendet eine neue Abstraktion für Ziele (Targets), um verschiedene Befehlsgruppen dem Servertyp zuzuordnen, für den die Befehle gelten. Der Befehl tanzu context list bezieht sich mit dem Flag --target auf dasselbe Konzept wie context type. Da Befehlsgruppen auf CLI-Plug-Ins basieren, gilt Folgendes:
- Plug-Ins, die Befehle für Kubernetes-Cluster definieren, haben ein Ziel- k8s
- In Plug-Ins, die Befehle für TMC definieren, ist das Ziel tmc für die zukünftige Verwendung reserviert
- Plug-Ins, die kontextunabhängige Befehle definieren, haben kein Ziel-
- Mit identisch benannten Plug-Ins für verschiedene Ziele kann die Tanzu CLI Befehle unter Befehlsgruppen wie tanzu cluster an den Kontext anpassen.
In TKG v2.1 ist der einzige unterstützte Ziel- oder Kontexttyp k8s. Dies wird auch durch Folgendes angegeben:
- Kubernetes cluster operations in der Ausgabe der tanzu help-Befehle
- kubernetes in der Spalte TARGET in der Ausgabe von tanzu plugin list
VMware empfiehlt nicht, Windows-Arbeitslastcluster bereitzustellen, die nur über Windows-basierte Worker verfügen, wie in der TKG v1.6-Dokumentation beschrieben. Stattdessen empfiehlt VMware, Cluster mit mehreren Betriebssystemen zu erstellen, wie unter Bereitstellung eines Arbeitslastclusters mit mehreren Betriebssystemen beschrieben. In Clustern mit mehreren Betriebssystemen können sowohl Windows- als auch Linux-Container ausgeführt werden, sodass sowohl Linux-basierte TKG-Komponenten als auch Linux-Arbeitslasten unterstützt werden.
Aufgrund von Änderungen bei der Zertifikatsverarbeitung in Go v1.18 muss das vCenter-Zertifikat den Schlüsselbunden von MacOS-Bootstrap-Maschinen hinzugefügt werden, bevor sie tanzu cluster create mit Fingerabdruck-Verifizierung ausführen können. Weitere Informationen finden Sie unter Voraussetzung für die Clusterbereitstellung.

Benutzerdokumentation

Eine neue Veröffentlichung, Bereitstellen und Verwalten eigenständiger TKG 2.1-Verwaltungscluster, enthält Themen spezifisch für eigenständige Verwaltungscluster, die für die Verwendung von TKG mit einem vSphere with Tanzu-Supervisor nicht relevant sind.

Weitere Informationen finden Sie unter Die richtige TKG-Dokumentation für Ihre Bereitstellung finden auf der Seite VMware Tanzu Kubernetes Grid-Dokumentation.

Behoben in v2.1.1

Die folgenden Probleme, die als bekannte Probleme in Tanzu Kubernetes Grid v2.1.0 dokumentiert wurden, wurden in Tanzu Kubernetes Grid v2.1.1 behoben.

Benutzerdefinierte CNI kann nicht bereitgestellt werden

Die Option CNI:none funktioniert nicht auf Arbeitslastclustern, die von einem eigenständigen Verwaltungscluster bereitgestellt werden. Die einzigen verfügbaren Optionen sind antrea (Standard) und calico.
TKG-Benutzerkonto erstellt inaktive vCenter-Sitzungen

Das vSphere-Konto für TKG erstellt inaktive vCenter-Sitzungen, wie in vSphere > Bestandliste Hosts und Cluster (Hosts and Clusters) > Ihr vCenter > Registerkarte Überwachen (Monitor) > Sitzungen (Sessions) aufgeführt.

Problemumgehung: Entfernen Sie inaktive vCenter-Sitzungen, indem Sie alle Sitzungen starten und beenden:
1. Melden Sie sich über ssh als root bei vCenter an.
2. Wenn Sie dazu aufgefordert werden, geben Sie shell ein.
3. Führen Sie service-control --stop --all aus.
4. Warten Sie, bis die Dienste als Stopped angezeigt werden.
5. Führen Sie service-control --start --all aus.
LoadBalancer-Dienste für klassenbasierte Arbeitslastcluster auf Azure benötigen eine manuelle Gateway- oder Frontend-Konfiguration

Aufgrund eines Namenskonflikts zwischen AzureClusterName und ClusterName sind Dienste vom Typ LoadBalancer, die für Apps auf klassenbasierten Azure-Arbeitslastclustern bereitgestellt werden, nicht über das Internet verfügbar.

Problemumgehung: Stellen Sie Ihre eigene Route für den Lastausgleichsdienst bereit, z. B. über ein NAT-Gateway, Proxy oder ein anderes internes Routing, damit Knoten hinter dem Lastausgleichsdienst auf das Internet zugreifen können.

VMware empfiehlt die Verwendung eines NAT-Gateways, sofern verfügbar, für ausgehende Konnektivität. Wenn kein NAT-Gateway verfügbar ist:
1. Navigieren Sie im Azure-Portal zur LoadBalancer-Ressource, die von CAPZ erstellt wird und den gleichen Namen wie der AzureCluster haben sollte.
2. Wählen Sie Frontend-IP-Konfiguration (Frontend IP Configuration) aus und klicken Sie auf Hinzufügen (Add).
3. Erstellen Sie eine neue öffentliche IP-Adresse für den Lastausgleichsdienst.
4. Konfigurieren und erstellen Sie den Dienst mithilfe der folgenden Spezifikation, indem Sie den Wert loadBalancerIP auf die öffentliche IP-Adresse festlegen, wobei dies durch IP-ADDRESS angegeben wird:
```
  apiVersion: v1
  kind: Service
  metadata:
    name: frontend
    labels:
      app: guestbook
      tier: frontend
    namespace: sample-app
  spec:
    # Add the frontend public IP here
    loadBalancerIP: IP-ADDRESS
    type: LoadBalancer
    ports:
    - port: 80
    selector:
      app: guestbook
      tier: frontend
```
Beim Upgrade von Clustern wird die Kube-VIP-Version nicht aktualisiert

Beim Upgrade eigenständiger Verwaltungs- und Arbeitslastcluster auf v2.1 wird kein Upgrade der kube-vip auf die aktuelle Version durchgeführt.

Problemumgehung: Aktualisieren Sie für Cluster, für die Sie ein Upgrade durchgeführt haben und die Kube-VIP für ihren Steuerungsebenen-Endpoint verwenden, wie mit AVI_CONTROL_PLANE_HA_PROVIDER = false konfiguriert, die Komponente kube-vip:
1. Rufen Sie die aktuelle TKr-BoM-Datei ab, die für das Cluster-Upgrade verwendet wird. Suchen Sie eine lokale Kopie dieser Datei in ~/.config/tanzu/tkg/bom/ mit einem Dateinamen, der mit tkr- beginnt. Beispiel: tkr-bom-v1.24.10+vmware.1-tkg.1.yaml.
2. Listen Sie die aktuelle Version von kube-vip aus der BoM-Datei auf, z. B.:
```
$ cat ~/.config/tanzu/tkg/bom/tkr-bom-v1.24.10+vmware.1-tkg.1.yaml | yq '.components.kube-vip'
- version: v0.5.7+vmware.1
  images:
    kubeVipImage:
      imagePath: kube-vip
      tag: v0.5.7_vmware.1
```
3. Rufen Sie das kcp-Objekt für den Cluster ab. Der Name dieses Objekts hat das Format CLUSTER-NAME-control-plane.
  - Objekte des Verwaltungsclusters werden im Namespace „tkg-system“ erstellt.
  - Arbeitslastclusterobjekte befinden sich in dem Namespace, der für die Clustererstellung verwendet wird, oder im Namespace default, wenn NAMESPACE nicht festgelegt wurde.
4. Führen Sie kubectl edit aus, um das Objekt kcp zu bearbeiten und den Pfad von kube-vip zu aktualisieren, sodass er mit der aktuellen Version aus dem BoM-Image übereinstimmt. Suchen Sie den Speicherort dieser Einstellung, indem Sie folgenden Befehl ausführen:
```
kubectl get kcp <cluster-name>-control-plane -o jsonpath='{.spec.kubeadmConfigSpec.files[0]}' | jq
```
Das Upgrade von Verwaltungsclustern von v1.5.x auf v2.1.0 führt zu einem Knotennetzwerkfehler aufgrund von null avi_ingress_node_network_list im geheimen Schlüssel des AKO-Operators

Bei eigenständigen Verwaltungsclustern, die ursprünglich in TKG v1.5 oder früher erstellt wurden, wird beim Upgrade auf v2.1.0 ein Nullwert für avi_ingress_node_network_list im geheimen Schlüssel des AKO-Operators festgelegt. Dies führt zu einem Knotennetzwerkfehler beim Upgrade auf v2.1.0 und generiert Fehler bei fehlender Avi-Konfiguration in den Protokollen.

Problemumgehung: Nach dem Upgrade der Tanzu CLI auf v2.1.0, aber vor der Ausführung von tanzu mc upgrade:
1. Wechseln Sie zum Kontext des Verwaltungsclusters:
```
kubectl config use-context <MGMT-CLUSTER>-admin@<MGMT-CLUSTER>
```
2. Rufen Sie den geheimen Schlüssel des AKO-Operators ab und entschlüsseln Sie seine Datenwerte:
```
kubectl get secret <MGMT-CLUSTER>-ako-operator-addon -n tkg-system -o jsonpath="{.data.values\.yaml}" | base64 --decode > values.yaml
```
3. Öffnen Sie die values.yaml-Datei mit einem Texteditor. Die Einstellung für avi_ingress_node_network_list sieht wie folgt aus:
```
avi_ingress_node_network_list: '""'
```
4. Ändern Sie die Einstellung wie folgt, indem Sie den Bereich Ihres Clusterknoten-Netzwerks verwenden:
```
avi_ingress_node_network_list: '[{"networkName":"VM Network", "cidrs":["10.191.176.0/20"]}]'
```
5. Führen Sie die Base64-Kodierung der neuen Datenwerte durch und zeichnen Sie die Ausgabezeichenfolge auf:
```
base64 -w 0 values.yaml
```
6. Bearbeiten Sie den geheimen Schlüssel des AKO-Operators:
```
kubectl edit secret MGMT-CLUSTER-ako-operator-addon -n tkg-system
```
7. Fügen Sie die neue, codierte Datenwerte-Zeichenfolge als Wert von values.yaml in den geheimen Schlüssel ein. Speichern und beenden Sie die Bearbeitung.
TMC kann keine klassenbasierten Cluster mit Dienst-Engines bereitstellen, die sich nicht in der Dienst-Engine-Gruppe Default-Group befinden.

Tanzu Mission Control (in TKG integriert) kann keine neuen klassenbasierten Cluster bereitstellen, die NSX ALB verwenden und mit Dienst-Engines konfiguriert sind, die sich nicht in der Dienst-Engine-Gruppe Default-Group in NSX ALB befinden. Diese Einschränkung wirkt sich nicht auf das Upgrade vorhandener Arbeitslastcluster aus, die mit benutzerdefinierten Dienst-Engines konfiguriert sind.

Weitere Informationen finden Sie in den Versionshinweisen zu Tanzu Mission Control.
TMC-Katalog wird für die Auflistung und Bereitstellung von Paketen nicht unterstützt

Sie können die Katalogfunktion von Tanzu Mission Control (TMC) nicht verwenden, um Pakete in TKG v2.1-Arbeitslastclustern aufzulisten oder zu installieren, wie unter Anzeigen von Paketen in der TMC-Dokumentation beschrieben. Auf der TMC-Benutzeroberfläche wird angezeigt, dass das Paketrepository in einem Abgleichstatus verbleibt.

Behoben in v2.1.0

Die folgenden Probleme, die als bekannte Probleme in Tanzu Kubernetes Grid v1.6.1 dokumentiert wurden, wurden in Tanzu Kubernetes Grid v2.1.0 behoben.

Cluster- und Pod-Vorgänge, bei denen Pods gelöscht werden, schlagen möglicherweise fehl, wenn DaemonSet für die automatische Wiederherstellung von persistenten Volumes konfiguriert ist

In Installationen, in denen ein DaemonSet persistente Volumes (PVs) verwendet, kann das Löschen von Maschinen fehlschlagen, da die Leerung standardmäßig DaemonSets ignoriert und das System auf unbestimmte Zeit wartet, bis die Volumes vom Knoten getrennt werden. Zu den betroffenen Clustervorgängen gehören Upgrade, Herunterskalieren und Löschen.
Auf vSphere with Tanzu generiert tanzu cluster list einen Fehler für DevOps-Benutzer

Wenn ein Benutzer mit der DevOps-Ingenieurrolle, wie unter vSphere with Tanzu-Benutzerrollen und -Workflows beschrieben, tanzu cluster list ausführt, wird möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt: Error: unable to retrieve combined cluster info: unable to get list of clusters. User cannot list resource "clusters" at the cluster scope.

Dies geschieht, weil der Befehl tanzu cluster command ohne die Option -n versucht, auf alle Namespaces zuzugreifen, von denen einige für einen DevOps-Ingenieurbenutzer möglicherweise nicht verfügbar sind.

Problemumgehung: Schließen Sie beim Ausführen von tanzu cluster list einen Wert für --namespace ein, um einen Namespace anzugeben, auf den der Benutzer zugreifen kann.

Bekannte Probleme

Im Folgenden sind bekannte Probleme in Tanzu Kubernetes Grid v2.1.x aufgeführt. Alle bekannten Probleme, die in v2.1.1 vorhanden waren und in einer nachfolgenden Patch-Version von v2.1.x behoben wurden, sind unter Behobene Probleme für die Patch-Version aufgeführt, in der sie behoben wurden.

Upgrade durchführen
Pakete
Clustervorgänge
Netzwerk
Identitäts- und Zugriffsverwaltung
Speicher
Befehlszeilenschnittstelle
vSphere
AWS
Arbeitslastcluster mit Windows und mit mehreren Betriebssystemen
Image Builder
AVS

Upgrade durchführen

Bekannt in v2.1.1
Bekannt in v2.1.x

Bekannt in v2.1.1

Im Folgenden sind bekannte Upgrade-Probleme in v2.1.1 aufgeführt.

Upgrade von v2.1 auf v2.1.1 auf vSphere schlägt fehl

Unter vSphere schlägt das Upgrade von v2.1 auf v2.1.1 mit dem Fehler Reconcile failed:Error fehl. Der Fehler wird angezeigt, weil das Paket tkg-clusterclass-vsphere nicht abgeglichen wird und die Installation blockiert ist.

Problemumgehung: Setzen Sie die folgenden vSphere-Ressourcenvariablen zurück, wenn sie in der lokalen Umgebung festgelegt sind:
```
unset VSPHERE_CLONE_MODE
unset VSPHERE_DATACENTER
unset VSPHERE_DATASTORE
unset VSPHERE_FOLDER
unset VSPHERE_NETWORK
unset VSPHERE_RESOURCE_POOL
unset VSPHERE_SERVER
unset VSPHERE_STORAGE_POLICY_ID
unset VSPHERE_TEMPLATE
unset VSPHERE_WORKER_DISK_GIB
unset VSPHERE_WORKER_MEM_MIB
unset VSPHERE_WORKER_NUM_CPUS
```

Bekannt in v2.1.x

Im Folgenden sind bekannte Upgrade-Probleme in v2.1.x aufgeführt.

Das Upgrade von Clustern auf Azure schlägt fehl

Auf Azure schlägt das Upgrade von Verwaltungsclustern und Arbeitslastclustern mit Fehlern fehl, z. B. context deadline exceeded oder unable to upgrade management cluster: error waiting for kubernetes version update for kubeadm control plane. Dies geschieht, weil Vorgänge auf Azure manchmal länger dauern als auf anderen Plattformen.

Problemumgehung: Führen Sie tanzu management-cluster upgrade oder tanzu cluster upgrade erneut aus, indem Sie im Flag --timeout eine längere Zeitüberschreitung angeben. Der Standard-Zeitüberschreitungswert beträgt 30 Minuten, 0 Sekunden.
Upgrade schlägt für eigenständige Verwaltungscluster fehl, die ursprünglich in TKG v1.3 oder früher erstellt wurden

In TKG v2.1 werden die Komponenten, die einen generischen Cluster in einen eigenständigen TKG-Verwaltungscluster umwandeln, in einem Carvel-Paket tkg-pkg gepackt. Bei eigenständigen Verwaltungsclustern, die ursprünglich in TKG v1.3 oder früher erstellt wurden, fehlt ein Konfigurationsschlüssel, den der Upgrade-Vorgang zum Installieren von tkg-pkg benötigt. Dies führt dazu, dass das Upgrade fehlschlägt.

Problemumgehung: Führen Sie die zusätzlichen Schritte unter Upgrade eigenständiger Verwaltungscluster für eigenständige Verwaltungscluster aus, die in TKG v1.3 oder früher erstellt wurden.
Das Upgrade schlägt für Cluster fehl, die mit dem Platzhalterzeichen (*) in der Einstellung TKG_NO_PROXY erstellt wurden

TKG v1.6 lässt das Platzhalterzeichen (*) in den Einstellungen der Clusterkonfigurationsdatei für TKG_NO_PROXY nicht zu. Cluster, die von früheren TKG-Versionen mit dieser Einstellung erstellt wurden, müssen vor dem Upgrade besonders behandelt werden, um folgenden Fehler zu vermeiden: workload cluster configuration validation failed: invalid string '*' in TKG_NO_PROXY.

Problemumgehung: Abhängig vom Clustertyp, den Sie aktualisieren:
- Verwaltungscluster:
  1. Wechseln Sie zum Verwaltungscluster-Kontext kubectl.
  2. Bearbeiten Sie die configMap kapp-controller-config:
```
kubectl edit cm kapp-controller-config -n tkg-system
```
  3. Suchen Sie das Feld data.noProxy und ändern Sie den Platzhalter-Hostnamen, indem Sie * entfernen. Ändern Sie beispielsweise *.vmware.com to .vmware.com
  4. Speichern und beenden Sie die Bearbeitung. Der Cluster ist bereit für das Upgrade.
- Arbeitslastcluster:
  1. Wechseln Sie zum Arbeitslastcluster-Kontext kubectl.
  2. Legen Sie Umgebungsvariablen für Ihren Clusternamen und Namespace fest, z. B.:
```
CLUSTER_NAME=my-test-cluster
NS=my-test-namespace
```
  3. Rufen Sie die kapp-Controller-Datenwerte für den Arbeitslastcluster ab und entschlüsseln Sie sie:
```
kubectl get secret "${CLUSTER_NAME}-kapp-controller-data-values" -n $NS -o json | jq -r '.data."values.yaml"' | base64 -d > "${CLUSTER_NAME}-${NS}-kapp-controller-data-values"
```
  4. Bearbeiten Sie die Datei ${CLUSTER_NAME}-${NS}-kapp-controller-data-values, indem Sie * aus der Einstellung kappController.config.noProxy entfernen. Ändern Sie beispielsweise *.vmware.com to .vmware.com.
  5. Speichern und schließen Sie die Datei.
  6. Verschlüsseln Sie die Datenwertdatei ${CLUSTER_NAME}-${NS}-kapp-controller-data-values erneut:
```
cat "${CLUSTER_NAME}-${NS}-kapp-controller-data-values" | base64 -w 0
```
  7. Bearbeiten Sie den geheimen Schlüssel ${CLUSTER_NAME}-${NS}-kapp-controller-data-values und aktualisieren Sie die data.value.yaml-Einstellung, indem Sie die Zeichenfolge der neu verschlüsselten Datenwerte einfügen.
```
kubectl edit secret "${CLUSTER_NAME}-kapp-controller-data-values" -n "${NS}"
```
  8. Speichern und beenden Sie die Bearbeitung. Der Cluster ist bereit für das Upgrade.
TKrs der älteren Version sind unmittelbar nach dem Upgrade des eigenständigen Verwaltungsclusters nicht verfügbar

Beim Upgrade eines eigenständigen Verwaltungsclusters von TKG v1.6 auf v2.1 wird der TKr-Quell-Controller durch eine neuere Version ersetzt, die klassenbasierte Cluster unterstützt. Anschließend werden TKrs neu synchronisiert. Dies führt dazu, dass nach Abschluss des Befehls tanzu mc upgrade möglicherweise von tanzu cluster available-upgrades get und tanzu kubernetes-release get nicht alle gültigen TKr-Versionen angezeigt werden und die Tanzu CLI eventuell nicht sofort ein Upgrade der Arbeitslastcluster durchführen kann.

Problemumgehung: Warten Sie einige Minuten, bis die TKrs erneut heruntergeladen wurde.

Pakete

Konfigurations-Update erfordert ein Upgrade für einige Pakete

Bekanntes Problem in: v2.1.1

Im Tanzu Standard-Paketrepository für TKG v2.1.1 fehlen die folgenden Paketversionen, die sich im Repository von v2.1.0 befinden:
- cert-manager: 1.10.1+vmware.1-tkg.1.yml, 1.5.3+vmware.7-tkg.1.yml und 1.7.2+vmware.3-tkg.1.yml
- external-dns: 0.10.0+vmware.1-tkg.3.yml, 0.11.0+vmware.1-tkg.3.yml und 0.12.2+vmware.4-tkg.1.yml
- grafana: 7.5.16+vmware.1-tkg.2.yml
Aus diesem Grund können Sie nach dem Upgrade eines Arbeitslastclusters von TKG v2.1.0 auf v2.1.1 tanzu package installed update nicht ausführen, um die Konfigurationen dieser Pakete zu aktualisieren, ohne auch ein Upgrade der Pakete auf die neuesten Versionen durchzuführen:
- cert-manager: 1.10.1+vmware.1-tkg.2.yml
- external-dns: 0.12.2+vmware.4-tkg.2.yml
- grafana: 7.5.17+vmware.1-tkg.1.yml
Dieses Problem tritt nur auf, wenn Sie Paketkonfigurationen ändern müssen. Die installierten Pakete werden weiterhin ohne Upgrade ausgeführt.

Problemumgehung: Führen Sie einen der folgenden Schritte aus:
- Wenn Sie ihre cert-manager-, external-dns- oder grafana-Paketkonfiguration aktualisieren müssen:
  1. Führen Sie tanzu package installed get aus, um die Version des Pakets abzurufen.
  2. Wenn im Repository von v2.1.1 die installierte Paketversion fehlt, übergeben Sie, wie oben aufgeführt, die neueste Version an das Flag -v, wenn tanzu package installed update ausgeführt wird.
- Aktualisieren Sie nach dem Upgrade von Arbeitslastclustern auf TKG v2.1.1 die drei Pakete auf die obigen Versionen.
Informationen zu tanzu package-Befehlen finden Sie unter Installieren und Verwalten von Paketen.
Multus-CNI schlägt auf Pods der Größe medium und kleiner mit NSX Advanced Load Balancer fehl

Auf vSphere können Arbeitslastcluster mit Worker-Knoten der Größe medium oder kleiner, auf denen das Multus-CNI-Paket mit NSX ALB ausgeführt wird, mit dem Fehler Insufficient CPU oder anderen Fehlern fehlschlagen.

Problemumgehung: Um die Multus-CNI mit NSX ALB zu verwenden, stellen Sie Arbeitslastcluster mit Worker-Knoten der Größe large oder extra-large bereit.
TKG-BoM-Datei enthält irrelevante Cert-Manager-Paketversion

In der TKG-BoM-Datei (TKG Bill of Materials), die die Tanzu CLI in ~/.config/tanzu/tkg installiert, werden sowohl v1.5.3 als auch v1.7.2 als Versionen für das Paket cert manager (jetstack_cert-manager) aufgeführt. Die korrekte zu installierende Version ist v1.5.3, wie unter Installieren von cert-manager beschrieben.

Problemumgehung: Installieren Sie v1.5.3 von cert-manager.
Für die Deaktivierung von Pinniped muss das Objekt Secret auf Legacy-Clustern manuell gelöscht werden.

Wenn Sie die externe Identitätsverwaltung auf einem Verwaltungscluster deaktivieren, bleibt das nicht verwendete Pinniped-Objekt Secret auf Legacy-Arbeitslastclustern erhalten.

Wenn ein Benutzer dann versucht, mit einer alten kubeconfig auf den Cluster zuzugreifen, wird ein Anmelde-Popup angezeigt und der Vorgang schlägt fehl.

Problemumgehung: Löschen Sie das Pinniped-Secret des Legacy-Clusters manuell, wie unter Deaktivieren der Identitätsverwaltung beschrieben.
Der Harbor-CVE-Export schlägt möglicherweise fehl, wenn die Ausführungs-ID 1.000.000 überschreitet

Harbor v2.6.3, die für TKG v2.1 gepackte Version, weist ein bekanntes Problem auf, bei dem CVE-Berichte mit dem Fehler „404 Seite nicht gefunden (404 page not found)“ exportiert werden, wenn die automatisch inkrementierte ID des primären Ausführungsschlüssels auf über 1.000.000 steigt.

Dieses Harbor-Problem wird in späteren Versionen von Harbor behoben, die in spätere Versionen von TKG aufgenommen werden sollen.
Keine Unterstützung für Harbor-Proxy-Cache

Sie können die Proxy-Cache-Funktion von Harbor nicht verwenden, um Tanzu Kubernetes Grid v2.1 in einer Umgebung mit Internetbeschränkungen auszuführen. Sie können weiterhin einen Harbor-Proxy-Cache verwenden, um Images aus früheren Versionen von Tanzu Kubernetes Grid und Nicht-Tanzu-Images wie Anwendungs-Images zu übermitteln.

Problemumgehung: Keine
Pakete entsprechen nicht dem standardmäßigen Baseline-PSA-Profil

Bei PSA-Controllern in TKG im nicht unterstützten Tech-Preview-Zustand entsprechen einige TKG-Pakete nicht dem Standardprofil baseline.

Problemumgehung: Legen Sie die Bezeichnungen audit=privileged und warn=privileged in den betroffenen Paket-Namespaces fest, wie in Zugangssteuerung für Pod-Sicherheit (Tech Preview) beschrieben.
Das Hinzufügen eines Standardrepositorys schlägt für Einzelknotencluster fehl

Die Ausführung von tanzu package repository add, um das Repository tanzu-standard einem Einzelknotencluster des in Einzelknotencluster auf vSphere (Tech Preview) beschriebenen Typs hinzuzufügen, schlägt möglicherweise fehl.

Dies geschieht, weil Einzelknotencluster mit cert-manager als Kern-Add-On gestartet werden, was zu einem Konflikt mit dem anderen cert-manager-Paket im Repository tanzu-standard führt.

Problemumgehung: Bevor Sie das Repository tanzu-standard hinzufügen, patchen Sie die Anmerkungen des cert-manager-Pakets, wie unter Installieren von cert-manager beschrieben.

Clustervorgänge

Bekannt in v2.1.1
Bekannt in v2.1

Bekannt in v2.1.1

Im Folgenden sind bekannte Probleme bei Clustervorgängen in v2.1.1 aufgeführt.

Es können keine neuen Arbeitslastcluster basierend auf nicht aktuellen TKr-Versionen mit Antrea CNI erstellt werden

Sie können keinen neuen Arbeitslastcluster erstellen, der Antrea CNI verwendet und Kubernetes-Versionen ausführt, die mit früheren Versionen von TKG ausgeliefert wurden, wie z. B. Kubernetes v1.23.10. Dies ist die Kubernetes-Standardversion in TKG v1.6.1, wie in Unterstützte Kubernetes-Versionen in Tanzu Kubernetes Grid v2.1 aufgeführt.

TKG v2.1.1 bietet vollständige Unterstützung für vorhandene Cluster, in denen ältere Versionen von Kubernetes ausgeführt werden.

Problemumgehung: Erstellen Sie einen Arbeitslastcluster, in dem Kubernetes 1.24.10, 1.23.16 oder 1.22.17 ausgeführt wird. Das Kubernetes-Projekt empfiehlt dass Sie Komponenten auf der neuesten Patch-Version einer aktuellen Nebenversion ausführen.

Bekannt in v2.1

tanzu cluster create validiert erzeugte Clusterspezifikationen mit nicht standardmäßigen Kubernetes-Versionen nicht ordnungsgemäß

Wenn Sie einen klassenbasierten Arbeitslastcluster anhand einer Konfigurationsdatei mithilfe eines unter Erstellen eines klassenbasierten Clusters beschriebenen zweistufigen Prozesses erstellen und im ersten Schritt einen --tkr-Wert angeben, um als Basis für den Cluster eine nicht standardmäßige Version von Kubernetes zu verwenden, schlägt der zweite Schritt möglicherweise mit Validierungsfehlern fehl.

Problemumgehung: Wenn Sie tanzu cluster create im zweiten Schritt zum zweiten Mal ausführen und das generierte Clustermanifest übergeben, geben Sie dieselben --tkr-Werte und anderen Optionen wie im ersten Schritt an (siehe Beschreibung unter Erstellen eines klassenbasierten Clusters).
Autoscaler für klassenbasierte Cluster erfordert manuelle Anmerkungen

Aufgrund eines Problems bei der Bezeichnungsweitergabe in der Cluster-API sind die Einstellungen AUTOSCALER_MIN_SIZE_* und AUTOSCALER_MAX_SIZE_* in der Clusterkonfigurationsdatei für klassenbasierte Arbeitslastcluster in den MachineDeployment-Objekten des Clusters nicht festgelegt.

Problemumgehung: Nachdem Sie einen klassenbasierten Arbeitslastcluster mit aktiviertem Cluster-Autoscaler erstellt haben, fügen Sie die Einstellung für die minimale und die maximale Anzahl von Maschinen für jeden AZ manuell hinzu, wie unter Manuelles Hinzufügen von Anmerkungen für die minimale und maximale Größe beschrieben.
Die Eigenschaft labels von Knotenpools und andere Konfigurationseigenschaften können nicht geändert werden

Sie können die Eigenschaften labels, az, nodeMachineType oder die vSphere-Eigenschaften eines vorhandenen Knotenpools nicht hinzufügen oder anderweitig ändern, wie unter Konfigurationseigenschaften aufgeführt.

Problemumgehung: Erstellen Sie einen neuen Knotenpool im Cluster mit den gewünschten Eigenschaften, migrieren Sie Arbeitslasten in den neuen Knotenpool und löschen Sie den ursprünglichen.
Sie können die Knoten der Steuerungsebene des Verwaltungsclusters nicht auf eine gerade Anzahl skalieren

Wenn Sie tanzu cluster scale auf einem Verwaltungscluster ausführen und eine gerade Zahl an die Option --controlplane-machine-count übergeben, skaliert TKG die Knoten der Steuerungsebene nicht, und die CLI gibt keinen Fehler aus. Um das Quorum beizubehalten, sollte die Anzahl der Knoten der Steuerungsebene immer ungerade sein.

Problemumgehung: Skalieren Sie die Anzahl der Knoten der Steuerungsebene nicht auf eine gerade Zahl.
Klassenbasierte Clusternamen haben ein Limit von 25 Zeichen mit NSX ALB als Lastausgleichsdienst oder Ingress-Controller

Wenn NSX Advanced Load Balancer (ALB) als klassenbasierten Cluster-Lastausgleichsdienst oder Ingress-Controller mit einem eigenständigen Verwaltungscluster verwendet wird, enthalten die Anwendungsnamen sowohl den Clusternamen als auch load-balancer-and-ingress-service, den internen Namen für das AKO-Paket. Wenn der kombinierte Name den Grenzwert von 64 Zeichen für Avi-Controller-Apps überschreitet, schlägt der Befehl tanzu cluster create möglicherweise mit einer Fehlermeldung fehl, die besagt, dass der avi-system-Namespace nicht gefunden wurde.

Problemumgehung: Begrenzen Sie die Länge des klassenbasierten Clusternamens auf maximal 25 Zeichen, wenn Sie NSX ALB als Lastausgleichsdienst oder Ingress-Controller verwenden.

Netzwerk

Hinweis
Für v4.0 und höher wird VMware NSX-T Data Center in „VMware NSX“ umbenannt.

Das Erstellen einer ClusterClass-Konfigurationsdatei aus einer Legacy-Konfigurationsdatei und --dry-run enthält eine leere Antrea-Konfiguration

Das Erstellen einer ClusterClass-Konfigurationsdatei unter Verwendung von tanzu cluster create --dry-run -f mit einer Legacy-Konfigurationsdatei, die einen ANTREA_NODEPORTLOCAL-Eintrag enthält, hat eine automatisch erzeugte Antrea-Konfiguration ohne Bezeichnungen zur Folge, wodurch Antrea nicht erfolgreich abgeglichen werden kann. Dies geschieht, da AntreaConfig-Ressourcen in TKG 2.1.1 tkg.tanzu.vmware.com/package-name label benötigen, damit der Add-On-Manager Antrea im designierten Arbeitslastcluster installieren kann. Dieses Problem gilt nicht für 2.1.0.

Problemumgehung: Fügen Sie die fehlenden Bezeichnungen zu AntreaConfig in der Konfigurationsdatei ClusterClass hinzu und erstellen Sie den Cluster erneut:
```
labels:
tkg.tanzu.vmware.com/cluster-name: rito
tkg.tanzu.vmware.com/package-name: antrea.tanzu.vmware.com.1.7.2---vmware.1-tkg.1-advanced 
```
IPv6-Netzwerke werden auf vSphere 8 nicht unterstützt

TKG v2.1 unterstützt kein IPv6-Netzwerk auf vSphere 8, obwohl es Single-Stack-IPv6-Netzwerke mit Kube-Vip auf vSphere 7 unterstützt, wie unter IPv6-Netzwerk beschrieben.

Problemumgehung: Wenn Sie TKG in einer IPv6-Umgebung auf vSphere benötigen oder aktuell verwenden, installieren Sie vSphere 8 nicht bzw. führen Sie kein Upgrade auf vSphere 8 durch.
NSX ALB-Ingress-Modus NodePortLocal wird für Verwaltungscluster nicht unterstützt

In TKG v2.1 können Sie NSX Advanced Load Balancer (ALB) nicht als Diensttyp mit dem Ingress-Modus NodePortLocal für den Datenverkehr zum Verwaltungscluster ausführen.

Dieses Problem wirkt sich nicht auf die Unterstützung für den NodePortLocal Ingress zu Arbeitslastclustern aus, wie in L7 Ingress im NodePortLocal-Modus beschrieben.

Problemumgehung: Konfigurieren Sie Verwaltungscluster, indem Sie für AVI_INGRESS_SERVICE_TYPE entweder NodePort oder ClusterIP festlegen. Der Standardwert lautet NodePort.
Die Erstellung des Verwaltungsclusters schlägt bei älteren NSX-T-Versionen und Photon 3- oder Ubuntu-VMs mit Linux-Kernel 5.8 fehl oder verlangsamt die Leistung

Die Bereitstellung eines Verwaltungsclusters mit der folgenden Infrastruktur und Konfiguration schlägt möglicherweise fehl oder führt zu eingeschränktem Datenverkehr zwischen Pods:
- vSphere mit einer der folgenden Versionen von NSX-T:
  - NSX-T v3.1.3 mit aktiviertem erweiterten Datenpfad
  - NSX-T v3.1.x niedriger als v3.1.3
  - NSX-T v3.0.x niedriger als v3.0.2 Hot Patch
  - NSX-T v2.x. Dazu gehört Azure VMware Solution (AVS) v2.0 unter Verwendung von NSX-T v2.5
- Basisimage: Photon 3 oder Ubuntu mit Linux-Kernel 5.8
Durch diese Kombination tritt ein Prüfsummenproblem zwischen älteren Versionen von NSX-T und Antrea-CNI auf.

TMC: Wenn der Verwaltungscluster bei Tanzu Mission Control (TMC) registriert ist, gibt es keine Problemumgehung für dieses Problem. Andernfalls können Sie eine der folgenden Problemumgehungen nutzen.

Umgehungen:
- Stellen Sie Arbeitslastcluster bereit, für die ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD auf "true" festgelegt ist. Diese Einstellung deaktiviert das Auslagern der UDP-Prüfsumme von Antrea, wodurch bekannte Probleme mit einigen Underlay-Netzwerk- und physischen Netzwerkkartentreibern vermieden werden.
- Upgrade auf NSX-T v3.0.2 Hot Patch v3.1.3 oder höher ohne aktivierten erweiterten Datenpfad
- Verwenden Sie ein Ubuntu-Basisimage mit Linux-Kernel 5.9 oder höher.

Identitäts- und Zugriffsverwaltung

Beim erneuten Erstellen eines eigenständigen Verwaltungsclusters wird die Pinniped-Authentifizierung nicht wiederhergestellt

Nachdem Sie einen eigenständigen Verwaltungscluster wie unter Sichern und Wiederherstellen der Verwaltungs- und Arbeitslastcluster-Infrastruktur (Tech Preview) beschrieben neu erstellt haben, können sich Benutzer nicht über die Pinniped-Authentifizierung bei Arbeitslastclustern anmelden.

Problemumgehung: Konfigurieren Sie nach dem erneuten Erstellen des Verwaltungsclusters die Identitätsverwaltung neu, wie unter Aktivieren und Konfigurieren der Identitätsverwaltung in einer vorhandenen Bereitstellung beschrieben.

Speicher

Das Ändern des Standardobjekts StorageClass führt zu einem Abstimmungsfehler in Arbeitslastclustern

Das Ändern der Eigenschaften eines in TKG enthaltenen StorageClass-Standardobjekts führt zu einem Paketabstimmungsfehler in Arbeitslastclustern, die die Speicherklasse verwenden.

Problemumgehung: Um eine Speicherklasse anzupassen, erstellen Sie eine neue StorageClass-Definition mit einem anderen name anstatt die Standardobjektdefinition zu ändern. Konfigurieren Sie den Cluster neu, um die neue Speicherklasse zu verwenden.
Arbeitslastcluster kann Speicher nicht über mehrere Datenspeicher verteilen

Sie können einen Arbeitslastcluster nicht aktivieren, um Speicher auf mehrere Datenspeicher zu verteilen (siehe Beschreibung unter Bereitstellen eines Clusters, der einen Datenspeicher-Cluster verwendet). Wenn Sie mehrere Datenspeicher in einem Datenspeicher-Cluster als Basis für die Speicherrichtlinie eines Arbeitslastclusters kennzeichnen, verwendet der Arbeitslastcluster nur einen der Datenspeicher.

Problemumgehung: Keine

Befehlszeilenschnittstelle

Nicht alphanumerische Zeichen können in HTTP/HTTPS-Proxy-Kennwörtern nicht verwendet werden

Bei der Bereitstellung von Verwaltungsclustern mit der CLI können die folgenden nicht alphanumerischen Zeichen in Kennwörtern nicht verwendet werden: # ` ^ | / ? % ^ { [ ] } \ " < > Darüber hinaus können bei der Bereitstellung des Verwaltungsclusters mit der Benutzeroberfläche keine nicht alphanumerischen Zeichen in HTTP-/HTTPS-Proxy-Kennwörtern verwendet werden.

Problemumgehung: Sie können andere nicht alphanumerische Zeichen als # ` ^ | / ? % ^ { [ ] } \ " < > in Kennwörtern verwenden, wenn Sie ein Verwaltungscluster mit der CLI bereitstellen.
Tanzu CLI funktioniert nicht auf macOS-Maschinen mit ARM-Prozessoren

Tanzu CLI v0.11.6 funktioniert nicht auf macOS-Maschinen mit ARM-Chips (Apple M1), wie unter Finder > Über diesen Mac > Übersicht identifiziert.

Problemumgehung: Verwenden Sie eine Bootstrap-Maschine mit einem Linux- oder Windows-Betriebssystem oder eine macOS-Maschine mit einem Intel-Prozessor.
Tanzu CLI listet tanzu management-cluster osimage auf

Die Befehlsgruppe management-cluster listet tanzu management-cluster osimage auf. Diese Funktion befindet sich derzeit in der Entwicklung und ist für die zukünftige Verwendung reserviert.

Problemumgehung: Verwenden Sie tanzu management-cluster osimage nicht.
Validierungsfehler bei der Ausführung von tanzu cluster create

Wenn Sie eine flache Schlüssel-Wert-Konfigurationsdatei an die Option --file von tanzu cluster create übergeben, konvertiert der Befehl standardmäßig die Konfigurationsdatei in eine Objektspezifikationsdatei im Kubernetes-Stil und wird dann beendet. Dieses Verhalten wird durch die Funktion auto-apply-generated-clusterclass-based-configuration gesteuert, die standardmäßig auf false festgelegt ist. Wenn Sie die von der Option --file generierte Objektspezifikationsdatei im Kubernetes-Stil an tanzu cluster create übergeben, schlägt der Befehl in einigen Fällen mit einer Fehlermeldung ähnlich der folgenden fehl:
```
Error: workload cluster configuration validation failed...
```
Dieser Fehler kann auch auftreten, wenn Sie eine Objektspezifikationsdatei im Kubernetes-Stil, die von der Option --dry-run generiert wird, an tanzu cluster create übergeben.

Problemumgehung: Legen Sie die Konfigurationsparameter, die in der Fehlerausgabe aufgeführt sind, als lokale Umgebungsvariablen fest. Um diesen Fehler zu vermeiden, können Sie klassenbasierte Cluster in einem Schritt erstellen, ohne eine Vorschau ihrer Konfiguration anzuzeigen, indem Sie die Funktion auto-apply-generated-clusterclass-based-configuration auf true festlegen und dann tanzu cluster create ausführen. Um auto-apply-generated-clusterclass-based-configuration auf true festzulegen, führen Sie Folgendes aus:
```
tanzu config set features.cluster.auto-apply-generated-clusterclass-based-configuration true
```
Dadurch wird die Tanzu CLI so konfiguriert, dass klassenbasierte Cluster immer in einem Schritt erstellt werden. Weitere Informationen finden Sie unter Erstellen eines klassenbasierten Clusters.
Die Option --default-values-file-output von tanzu package available get gibt eine unvollständige Konfigurationsvorlagendatei für das Harbor-Paket aus

Durch die Ausführung von tanzu package available get harbor.tanzu.vmware.com/PACKAGE-VERSION --default-values-file-output FILE-PATH wird eine unvollständige Konfigurationsvorlagendatei für das Harbor-Paket erstellt. Um eine vollständige Datei zu erhalten, verwenden Sie den Befehl imgpkg pull wie unter Installieren von Harbor für die Dienstregistrierung beschrieben.
Windows-Eingabeaufforderung: Überflüssige Zeichen in CLI-Ausgabespaltenüberschriften

In der Windows-Eingabeaufforderung (Command Prompt, CMD) enthält eine in Spalten formatierte Tanzu CLI-Befehlsausgabe überflüssige Zeichen in Spaltenüberschriften.

Dieses Problem tritt nicht in Windows Terminal oder PowerShell auf.

Problemumgehung: Führen Sie auf Windows-Bootstrap-Maschinen die Tanzu CLI über Windows Terminal aus.
Ignorierbarer Fehler AKODeploymentConfig während der Erstellung des Verwaltungsclusters

Beim Ausführen von tanzu management-cluster create zum Erstellen eines Verwaltungsclusters mit NSX ALB wird der folgende Fehler ausgegeben: no matches for kind ???AKODeploymentConfig??? in version ???networking.tkg.tanzu.vmware.com/v1alpha1???. Der Fehler kann ignoriert werden. Weitere Informationen finden Sie in diesem Artikel in der KB.

Ignorierbare Fehler machinehealthcheck und clusterresourceset während der Erstellung des Arbeitslastclusters auf vSphere

Wenn ein Arbeitslastcluster mithilfe des Befehls tanzu cluster create über vSphere with Tanzu auf vSphere bereitgestellt wird, kann die Ausgabe Fehler im Zusammenhang mit der Ausführung von machinehealthcheck und dem Zugriff auf die clusterresourceset-Ressourcen enthalten, wie unten gezeigt:

Error from server (Forbidden): error when creating "/tmp/kubeapply-3798885393": machinehealthchecks.cluster.x-k8s.io is forbidden: User "sso:[email protected]" cannot create resource "machinehealthchecks" in API group "cluster.x-k8s.io" in the namespace "tkg"
...
Error from server (Forbidden): error when retrieving current configuration of: Resource: "addons.cluster.x-k8s.io/v1beta1, Resource=clusterresourcesets", GroupVersionKind: "addons.cluster.x-k8s.io/v1beta1, Kind=ClusterResourceSet"
...

Der Arbeitslastcluster wurde erfolgreich erstellt. Sie können die Fehler ignorieren.

CLI gibt den Status kürzlich gelöschter Knoten vorübergehend falsch aus, wenn MHCs deaktiviert sind

Wenn Maschinenintegritätsprüfungen (Machine Health Checks, MHCs) deaktiviert sind, melden Tanzu CLI-Befehle wie tanzu cluster status möglicherweise nicht den aktuellen Knotenzustand, während die Infrastruktur neu erstellt wird.

Problemumgehung: Keine

vSphere

Knotenpools mit Knoten der Größe small bleiben möglicherweise beim Provisioning hängen

Knotenpools, die Knoten mit SIZE als small enthalten, bleiben möglicherweise im Zustand Provisioning hängen und erreichen nie den Zustand Running.

Problemumgehung: Konfigurieren Sie den Knotenpool mit Knoten, die mindestens die Größe medium aufweisen.
Mit NSX ALB können keine Cluster mit identischen Namen erstellt werden

Wenn Sie NSX Advanced Load Balancer für Arbeitslasten (AVI_ENABLE) oder die Steuerungsebene (AVI_CONTROL_PLANE_HA_PROVIDER) verwenden, kann der Avi-Controller möglicherweise nicht zwischen Clustern mit identischen Namen unterscheiden.

Problemumgehung: Legen Sie einen eindeutigen CLUSTER_NAME-Wert für jeden Cluster fest:
- Verwaltungscluster: Erstellen Sie nicht mehrere Verwaltungscluster mit demselben Wert für CLUSTER_NAME, auch nicht von unterschiedlichen Bootstrap-Maschinen.
- Arbeitslastcluster: Erstellen Sie nicht mehrere Arbeitslastcluster, die denselben CLUSTER_NAME haben und sich auch im selben Verwaltungscluster-Namespace befinden, wie durch den Wert NAMESPACE festgelegt.
Das Hinzufügen einer externen Identitätsverwaltung zu einer vorhandenen Bereitstellung erfordert möglicherweise das Festlegen eines Dummy-Werts für VSPHERE_CONTROL_PLANE_ENDPOINT

Für die Integration eines externen Identitätsanbieters in eine vorhandene TKG-Bereitstellung muss möglicherweise ein Dummy-Wert für VSPHERE_CONTROL_PLANE_ENDPOINT in der Verwaltungscluster-Konfigurationsdatei festgelegt werden, die zum Erstellen des geheimen Add-on-Schlüssels verwendet wird, wie unter Generieren des geheimen Pinniped-Add-on-Schlüssels für den Verwaltungscluster beschrieben.

AWS

Problem beim CAPA-Ressourcen-Tagging führt zu Abgleichsfehler bei der Bereitstellung und dem Upgrade des AWS-Verwaltungsclusters

Aufgrund eines Ressourcen-Tagging-Problems im Upstream-Cluster-API-Anbieter AWS (Cluster API Provider AWS, CAPA) können Offline-Bereitstellungen nicht auf die API ResourceTagging zugreifen. Dies führt zu Abstimmungsfehlern bei der Erstellung oder dem Upgrade eines Verwaltungsclusters.

Problemumgehung: Legen Sie in einer Offline-AWS-Umgebung EXP_EXTERNAL_RESOURCE_GC=false in Ihrer lokalen Umgebung oder in der Verwaltungscluster-Konfigurationsdatei fest, bevor Sie tanzu mc create oder tanzu mc upgrade ausführen.
Arbeitslastclusterknoten-Pools unter AWS müssen sich in demselben Verfügbarkeitsbereich wie der eigenständige Verwaltungscluster befinden.

Wenn Sie einen Knotenpool erstellen, der mit einem az konfiguriert ist und sich nicht im Verwaltungscluster befindet, bleibt der neue Knotenpool möglicherweise mit dem Status ScalingUp, wie in tanzu cluster node-pool list aufgeführt, hängen und erreicht nie den Zustand Ready.

Problemumgehung: Erstellen Sie Knotenpools nur in demselben AZ wie der eigenständige Verwaltungscluster.
Das Löschen des Clusters auf AWS schlägt fehl, wenn der Cluster Netzwerkressourcen verwendet, die nicht mit Tanzu Kubernetes Grid bereitgestellt wurden.

Die Befehle tanzu cluster delete und tanzu management-cluster delete hängen möglicherweise bei Clustern, die unabhängig vom Tanzu Kubernetes Grid-Bereitstellungsvorgang vom AWS Cloud Controller Manager erstellte Netzwerkressourcen verwenden. Zu diesen Ressourcen können Lastausgleichsdienste und andere Netzwerkdienste gehören, wie unter The Service Controller in der Dokumentation zum Kubernetes AWS Cloud-Anbieter aufgeführt.

Weitere Informationen finden Sie unter Cluster-API-Problem Drain workload clusters of service Type=Loadbalancer on teardown.

Problemumgehung: Verwenden Sie kubectl delete, um Dienste vom Typ LoadBalancer aus dem Cluster zu löschen. Wenn dies fehlschlägt, verwenden Sie die AWS-Konsole, um alle LoadBalancer- und SecurityGroup-Objekte, die vom Cloud Controller Manager für diesen Dienst erstellt wurden, manuell zu löschen.

Vorsicht
: Löschen Sie keine Lastausgleichsdienste oder Sicherheitsgruppen, die von Tanzu verwaltet werden und die die Tags key: sigs.k8s.io/cluster-api-provider-aws/cluster/CLUSTER-NAME, value: owned aufweisen.

Azure

Das Löschen des Clusters schlägt fehl, wenn das Speicher-Volume ein Konto mit privatem Endpoint verwendet

Wenn der Azure CSI-Treiber bei einem Azure-Arbeitslastcluster in einer nicht verwalteten Ressourcengruppe ein persistentes Volume (PV) erstellt, das ein Speicherkonto mit privatem Endpoint verwendet, erstellt er einen privateEndpoint und vNet-Ressourcen, die nicht zusammen mit dem PV gelöscht werden. Dies führt dazu, dass das Löschen des Clusters mit einer Fehlermeldung wie subnets failed to delete. err: failed to delete resource ... Subnet management-cluster-node-subnet is in use fehlschlägt.

Problemumgehung: Bevor Sie den Azure-Cluster löschen, löschen Sie die Netzwerkschnittstelle für den privaten Endpoint des Speicherkontos manuell:
1. Melden Sie sich über einen Browser beim Azure-Ressourcen-Explorer an.
2. Klicken Sie links auf Abonnements (Subscriptions) und erweitern Sie Ihr Abonnement.
3. Erweitern Sie unter Ihrem Abonnement links resourceGroups und erweitern Sie die Ressourcengruppe Ihrer TKG-Bereitstellung.
4. Erweitern Sie unter der Ressourcengruppe providers > Microsoft.Network > networkinterfaces.
5. Wählen Sie unter networkinterfaces die Netzwerkkartenressource aus, die nicht gelöscht werden kann.
6. Klicken Sie oben auf die Schaltfläche Read/Write und dann auf die Registerkarte Actions(POST, DELETE) direkt darunter.
7. Klicken Sie auf Löschen.
8. Nachdem die Netzwerkkarte gelöscht wurde, löschen Sie den Azure-Cluster.

Arbeitslastcluster mit Windows und mit mehreren Betriebssystemen

Sie können kein Windows-Systemimage auf einer MacOS-Maschine erstellen

Aufgrund eines Problems mit dem von Kubernetes Image Builder verwendeten Open-Source-Dienstprogramm packer können Sie kein Windows-Systemimage auf einer MacOS-Maschine erstellen, wie in Benutzerdefinierte Windows-Maschinen-Images beschrieben.

Problemumgehung: Verwenden Sie eine Linux-Maschine, um Ihre benutzerdefinierten Windows-Systemimages zu erstellen.
Sicherung und Wiederherstellung wird für Arbeitslastcluster nicht Windows und mit mehreren Betriebssystemen nicht unterstützt

Sie können Arbeitslastcluster mit Windows-basierten Worker-Knoten nicht sichern und wiederherstellen.

Problemumgehung: Keine

Image-Builder

Ignorierbarer goss-Testfehler während des Image-Erstellungsvorgangs

Wenn Sie Kubernetes Image Builder ausführen, um ein benutzerdefiniertes Linux-Systemimage zu erstellen, schlagen die goss-Tests python-netifaces, python-requests und ebtables fehl. Die Befehlsausgabe meldet die Fehler. Die Fehler können ignoriert werden; sie verhindern eine erfolgreiche Image-Erstellung nicht.

AVS

Löschen von vSphere CSI-Volumes schlägt auf AVS möglicherweise fehl

In Azure vSphere Solution (AVS) kann das Löschen von persistenten vSphere CSI-Volumes (PVs) fehlschlagen. Zum Löschen eines PV ist die Berechtigung cns.searchable erforderlich. Das standardmäßige Administratorkonto für AVS, [email protected], wird nicht mit dieser Berechtigung erstellt. Weitere Informationen finden Sie unter vSphere-Rollen und -Berechtigungen.

Problemumgehung: Um ein vSphere CSI-PV auf AVS zu löschen, wenden Sie sich an den Azure-Support.