Versionshinweise zu VMware Tanzu Kubernetes Grid v2.2

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

TKG v2.2 wird als herunterladbares Tanzu CLI-Paket verteilt, das einen versionierten eigenständigen TKG-Verwaltungscluster bereitstellt. TKG v2.2 unterstützt das Erstellen und Verwalten von Arbeitslastclustern mit einem eigenständigen Verwaltungscluster, der in mehreren Infrastrukturen ausgeführt werden kann, einschließlich vSphere 6.7, 7 und 8, AWS und Azure.

Tanzu Kubernetes Grid v2.0, v2.2 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.2 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.2.x umfasst die folgenden neuen Funktionen:

Unterstützung für Kubernetes v1.25.7, 1.24.11 und 1.23.17. Informationen finden Sie im Folgenden unter Unterstützte Kubernetes-Versionen in Tanzu Kubernetes Grid v2.2.
Für eigenständige Verwaltungscluster und klassenbasierte Arbeitslastcluster können Sie eine Vertrauensstellung für mehrere private Image-Registrierungen konfigurieren, indem Sie ADDITIONAL_IMAGE_REGISTRY*-Variablen in einer Clusterkonfigurationsdatei oder additionalImageRegistries-Einstellungen in einer Cluster-Objektspezifikation verwenden. Weitere Informationen finden Sie unter Vertrauenswürdige Registrierungen für einen klassenbasierten Cluster.
Entfernt die Beanspruchung eines dauerhaften jobservice.scandataExports-Volumes aus Harbor v2.7.1. Wenn Sie zuvor das Harbor Scandata Volume EmptyDir Overlay auf das Harbor-Paket angewendet haben, informieren Sie sich unter Aktualisieren einer ausgeführten Harbor-Bereitstellung, bevor Sie das Harbor-Paket auf v2.7.1 aktualisieren.
Ab TKG 2.2.0 bietet VMware Unterstützung auf Laufzeitebene für von VMware unterstützte Pakete, wie z. B. Harbor, Contour und Velero, wenn diese auf Tanzu Kubernetes Grid bereitgestellt werden.
Das vSphere CSI-Paket unterstützt die vsphereCSI.netpermissions-Konfiguration.

Unterstützte Kubernetes- und TKG-Versionen

Mit TKG v2.2 wurden die Supportrichtlinien von VMware für ältere Patchversionen von TKG und TKrs geändert, die Kubernetes-Versionen für TKG paketieren. Die Supportrichtlinien für TKG v2.1 und ältere Nebenversionen von TKG werden nicht geändert.

In den folgenden Abschnitten wird die Unterstützung für alle aktuell unterstützten Versionen von TKG und TKrs unter den jeweils geltenden Supportrichtlinien zusammengefasst.

Unterstützte Kubernetes-Versionen

Jede Version von Tanzu Kubernetes Grid bietet Unterstützung für die Kubernetes-Version des zugehörigen Verwaltungsclusters sowie zusätzliche Kubernetes-Versionen, die als Tanzu Kubernetes-Releases (TKrs) verteilt werden, mit Ausnahme derjenigen, die unter Bekanntes Problem erfasst sind.

Nebenversionen: VMware unterstützt TKG v2.2 mit Kubernetes v1.25, v1.24 und v1.23 zum Zeitpunkt der Veröffentlichung und für die Dauer der TKG v2.1-Unterstützung. Sobald TKG v2.1 das Ende des allgemeinen Supports erreicht hat, bietet VMware keine weitere Unterstützung mehr für Kubernetes v1.23 und v1.24 mit TKG.

Patchversionen: Nachdem VMware eine neue TKr-Patchversion für eine Nebenversion veröffentlicht hat, wird die Unterstützung für ältere Patchversionen zwei Monate beibehalten. Kunden sollten das Upgrade auf neue TKr-Patchversionen somit innerhalb der nächsten zwei Monate durchführen. Ab TKG v2.2 unterstützt VMware nicht alle TKr-Patchversionen aus früheren Nebenversionen von Kubernetes.

Unterstützte TKG- und TKr-Versionen

Die derzeit unterstützten TKG-Patchversionen bieten Unterstützung für die unten aufgeführten TKr-Patchversionen.

Version von Tanzu Kubernetes Grid	Kubernetes-Version des Verwaltungsclusters	Bereitgestellte Kubernetes-Versionen (TKr)
2.2.0	1.25.7	1.25.7, 1.24.11, 1.23.17
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

Mit TKG v2.2.0 unterstützte TKr-Versionen

TKG v2.2.0 unterstützt die in der folgenden Tabelle aufgeführten TKr-Patchversionen basierend auf den folgenden Veröffentlichungsdaten:

v2.2.0: 18. Mai 2023
v2.1.1: 21. März 2023

Kubernetes-Nebenversion	Kubernetes-Patch	Freigegeben mit TKG	Enddatum des Supports (falls nicht aktuell)
v1.25	v1.25.7	v2.2.0	Zuletzt unterstützt
v1.24	v1.24.11	v2.2.0	Zuletzt unterstützt
	v1.24.10	v2.1.1	11. Juli 2023
	v1.24.9	v2.1.0	21. Mai 2023
v1.23	v1.23.17	v2.2.0	Zuletzt unterstützt
	v1.23.16	v2.1.1	11. Juli 2023
	v1.23.15	v2.1.0	21. Mai 2023

Unterstützte Tanzu Kubernetes Grid-Versionen

VMware unterstützt TKG-Versionen wie folgt:

Nebenversionen: VMware unterstützt TKG gemäß der N-2-Lebenszyklusrichtlinie, die für die aktuellen und vorherigen Nebenversionen von TKG gilt. Mit der Veröffentlichung von TKG v2.2.0 wird TKG v1.5 nicht mehr unterstützt. Weitere Informationen finden Sie in der VMware-Produkt-Lebenzyklusmatrix.

Patchversionen: VMware unterstützt nicht alle vorherigen TKG-Patchversionen. Nachdem VMware eine neue Patchversion von TKG veröffentlicht hat, wird die Unterstützung für die ältere Patchversion zwei Monate beibehalten. Kunden sollten das Upgrade auf neue TKG-Patchversionen somit innerhalb der nächsten zwei Monate durchführen.

Die Unterstützung für TKG v2.2.0 endet beispielsweise zwei Monate, nachdem TKG v2.2.1 allgemein zur Verfügung gestellt wurde.

Klärung des Paket-Supports für das Tanzu Standard-Repository

VMware bietet folgende Unterstützung für die optionalen Pakete, die im VMware Tanzu Standard-Repository bereitgestellt werden:

VMware bietet eine Installations- und Upgrade-Validierung für die Pakete, die im optionalen VMware Tanzu Standard-Repository enthalten sind und in Tanzu Kubernetes Grid bereitgestellt werden. Diese Validierung beschränkt sich auf die Installation und das Upgrade des Pakets, umfasst jedoch alle verfügbaren Updates, die für CVEs erforderlich sind. Alle Fehlerkorrekturen, Funktionsverbesserungen und Sicherheitskorrekturen werden in neuen Paketversionen bereitgestellt, wenn sie im Upstream-Paketprojekt verfügbar sind.
VMware bietet keine Unterstützung auf Laufzeitebene für die Komponenten, die vom Tanzu-Standard-Repository bereitgestellt werden. Das Debugging von Konfigurations- und leistungsbezogenen Problemen oder Debugging und Fehlerbehebung im Paket selbst werden von VMware nicht bereitgestellt.

Weitere Informationen zum VMware Support für Tanzu Standard-Pakete finden Sie unter Neue Funktionen oben und Hinweise zu künftigen Verhaltensänderungen unten.

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

Tanzu Kubernetes Grid v2.2 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.2.0 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.29.0
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.18)
Containernetzwerk	Antrea (v1.9.0), Calico (v3.24.1)
Containerregistrierung	Harbor (v2.7.1)
Ingress	NSX Advanced Load Balancer Essentials und Avi-Controller **** (v21.1.5-v21.1.6, v22.1.2-v22.1.3), Contour (v1.23.5)	Contour (v1.23.5)	Contour (v1.23.5)
Speicher	vSphere Container Storage Interface (v2.7.1*) und vSphere Cloud Native Storage	Amazon EBS CSI-Treiber (v1.16.0) und Cloud-Anbieter in der Struktur	Azure Disk CSI-Treiber (v1.27.0), Azure File CSI-Treiber (v1.26.1) 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.7)

* Version von vsphere_csi_driver. Eine vollständige Liste der vSphere Container Storage Interface-Komponenten, die in der Version Tanzu Kubernetes Grid v2.2 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.

***** Wenn Sie einen Cluster auf Kubernetes v1.25 upgraden, müssen Sie ein Upgrade von Prometheus auf Version 2.37.0+vmware.3-tkg.1 durchführen. Frühere Versionen des Prometheus-Pakets, wie z. B. Version 2.37.0+vmware.1-tkg.1, sind nicht mit Kubernetes 1.25 kompatibel.

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

Komponentenversionen

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

Komponente	TKG v2.2
aad-pod-identity	v1.8.15+vmware.1^*
addons-manager	v2.2+vmware.1^*
ako-operator	v1.8.0_vmware.1^*
alertmanager	v0.25.0_vmware.1^*
antrea	v1.9.0_vmware.2-tkg.1-advanced^*
aws-ebs-csi-driver	v1.16.0_vmware.1-tkg.1^*
azuredisk-csi-driver	v1.27.0_vmware.2-tkg.1^*
azurefile-csi-driver	v1.26.1_vmware.2-tkg.1^*
calico	v3.24.1_vmware.1-tkg.2^*
capabilities-package	v0.29.0-dev-capabilities^*
carvel-secretgen-controller	v0.11.2+vmware.1
cloud-provider-azure	v1.1.26+vmware.1, v1.23.23+vmware.1, v1.24.10+vmware.1
cloud_provider_vsphere	v1.25.1+vmware.2^*
cluster-api-provider-azure	v1.6.3_vmware.2^*
cluster_api	v1.2.8+vmware.2^*
cluster_api_aws	v2.0.2+vmware.2^*
cluster_api_vsphere	v1.5.3+vmware.2^*
cni_plugins	v1.1.1+vmware.20^*
configmap-reload	v0.7.1+vmware.2
containerd	v1.6.18+vmware.1^*
contour	v1.23.5+vmware.1-tkg.1^*
coredns	v1.9.3_vmware.8^*
crash-diagnostics	v0.3.7+vmware.6
cri_tools	v1.24.2+vmware.8^*
csi_attacher	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
csi_node_driver_registrar	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
dex	v2.35.3_vmware.3^*
Envoy	v1.24.5_vmware.1^*
external-dns	v0.12.2+vmware.5^*
external-snapshotter	v6.0.1+vmware.1, v5.0.1+vmware.1
etcd	v3.5.6+vmware.9^*
fluent-bit	v1.9.5+vmware.1
gangway	v3.2.0+vmware.2
grafana	v7.5.17+vmware.2
guest-cluster-auth-service	v1.3.0^*
harbor	v2.7.1+vmware.1^*
image-builder	v0.1.13+vmware.3^*
image-builder-resource-bundle	v1.25.7+vmware.2-tkg.1^*
imgpkg	v0.31.1+vmware.1
jetstack_cert-manager	v1.10.2+vmware.1^*
k8s-sidecar	v1.15.6+vmware.5^, v1.12.1+vmware.6^
k14s_kapp	v0.53.2+vmware.1
k14s_ytt	v0.43.1+vmware.1
kapp-controller	v0.41.7_vmware.1-tkg.1^*
kbld	v0.35.1+vmware.1
kube-state-metrics	v2.7.0+vmware.2^*
kube-vip	v0.5.7+vmware.2^*
kube-vip-cloud-provider^*	v0.0.4+vmware.4^*
kube_rbac_proxy	v0.11.0+vmware.2
kubernetes	v1.25.7+vmware.2^*
kubernetes-csi_external-resizer	v1.4.0+vmware.1, v1.3.0+vmware.1
kubernetes-sigs_kind	v1.25.7+vmware.2-tkg.2_v0.17.0^*
kubernetes_autoscaler	v1.25.0+vmware.1^*
load-balancer-and-ingress-service (AKO)	v1.9.3_vmware.1-tkg.1^*
metrics-server	v0.6.2+vmware.1
multus-cni	v3.8.0+vmware.3^*
pinniped	v0.12.1_vmware.3-tkg.4^*
pinniped-post-deploy	v0.12.1+vmware.2-tkg.3
prometheus	v2.37.0+vmware.3^*
prometheus_node_exporter	v1.4.0+vmware.3^*
pushgateway	v1.4.3+vmware.3^*
sonobuoy	v0.56.16+vmware.1^*
standalone-plugins-paket	v0.29.0-dev-standalone-plugins^*
tanzu-framework	v0.29.0^*
tanzu-framework-addons	v0.29.0^*
tanzu-framework-management-packages	v0.29.0-tf^*
tkg-bom	v2.2.0^*
tkg-core-packages	v1.25.7+vmware.2-tkg.1^*
tkg-standard-packages	v2.2.0^*
tkg-storageclass-package	v0.29.0-tkg-storageclass^*
tkg_telemetry	v2.2.0+vmware.1^*
velero	v1.9.7+vmware.1^*
velero-mgmt-cluster-plugin^*	v0.1.0+vmware.1
velero-plugin-for-aws	v1.5.5+vmware.1^*
velero-plugin-for-csi	v0.3.5+vmware.1^*
velero-plugin-for-microsoft-azure	v1.5.5+vmware.1^*
velero-plugin-for-vsphere	v1.4.3+vmware.1^*
vendir	v0.30.1+vmware.1
vsphere_csi_driver	v2.7.1+vmware.2^*
whereabouts	v0.5.4+vmware.2^*

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

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

imgpkg pull -b projects.registry.vmware.com/tkg/packages/standard/repo:v2.2.0 -o standard-2.2.0
cd standard-2.2.0/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.2.0.yaml
~/.config/tanzu/tkg/bom/tkr-bom-v1.25.7+vmware.1-tkg.1.yaml

Unterstützte Upgrade-Pfade

Im TKG-Upgrade-Pfad folgt v2.2 unmittelbar auf v2.1.1.

Sie können von Tanzu Kubernetes Grid v2.1.x nur ein Upgrade auf v2.2.x durchführen. Wenn Sie ein Upgrade auf Tanzu Kubernetes Grid v2.2.x von einer älteren Version als v2.1.x durchführen möchten, müssen Sie zuerst ein Upgrade auf v2.1.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.23.x auf v1.25.x durchführen. Sie müssen einen v1.23.x-Cluster auf v1.24.x aktualisieren, bevor Sie das Upgrade des Clusters auf v1.25.x durchführen.

Veröffentlichungsdaten

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

v2.2.0: 9. Mai 2023

Verhaltensänderungen in Tanzu Kubernetes Grid v2.2

Tanzu Kubernetes Grid v2.2 führt keine neuen Verhaltensweisen im Vergleich zu v2.1.1 ein, der letzten vorherigen Version.

Hinweise zu künftigen Verhaltensänderungen

In diesem Abschnitt wird vorab auf Verhaltensänderungen hingewiesen, die in zukünftigen Versionen nach der TKG v2.2-Version wirksam werden.

VMware Tanzu Standard-Repository

Wichtig
Bei Tanzu Kubernetes Grid v2.2.x handelt es sich um die letzte Nebenversion von TKG, in deren Lieferumfang das VMware Tanzu Standard-Repository als Teil der Version enthalten ist. TKG v2.2.x und frühere Versionen enthalten einen Satz optionaler Pakete im Tanzu Standard-Repository, die Sie auf Clustern bereitstellen können, um Funktionen wie Protokollweiterleitung, Ingress-Steuerung, Containerregistrierung usw. hinzuzufügen. In einer zukünftigen TKG v2.x-Nebenversion wird das Tanzu Standard-Repository nicht automatisch heruntergeladen, wenn Sie die Tanzu CLI installieren und einen Verwaltungscluster bereitstellen. Zur Verwendung dieses Satzes optionaler Pakete laden Sie sie mithilfe der Tanzu CLI herunter und fügen Sie sie manuell hinzu. Durch die Trennung der optionalen Pakete von TKG-Versionen kann VMware inkrementelle Paketaktualisierungen außerhalb von TKG-Versionen bereitstellen und besser auf CVEs reagieren.

Hinweise zu veralteten Funktionen

In einer zukünftigen Version von TKG wird die Dex-Komponente entfernt, da Pinniped für die Arbeit mit LDAP-Anbietern nicht mehr benötigt wird. Mit dieser Änderung werden die folgenden Clusterkonfigurationsvariablen für die LDAP-Authentifizierung erforderlich: LDAP_BIND_DN und LDAP_BIND_PASSWORD. Weitere Informationen finden Sie unter Identitätsanbieter – LDAP in der Variablenreferenz für Konfigurationsdatei.

Benutzerdokumentation

Unter Bereitstellen und Verwalten eigenständiger TKG 2.2-Verwaltungscluster finden Sie spezifische Themen 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.

Behobene Probleme

Die folgenden Probleme, die als bekannte Probleme in früheren Tanzu Kubernetes Grid-Versionen dokumentiert wurden, wurden in Tanzu Kubernetes Grid v2.2.0 behoben.

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.
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.
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.
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.

Bekannte Probleme

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

Weitere Lösungen für häufig auftretende Probleme finden Sie in Fehlerbehebung bei Problemen mit dem Verwaltungscluster und Fehlerbehebung bei Problemen mit dem Arbeitslastcluster oder in VMware KnowledgeBase-Artikeln.

Pakete
Clustervorgänge
Netzwerk
Identitäts- und Zugriffsverwaltung
Speicher
Befehlszeilenschnittstelle
vSphere
AWS
Image Builder
AVS

Pakete

Die Grafana-Installation schlägt auf vSphere 6.7 mit NSX ALB v21.1.4 oder früher fehl

Sie können das Grafana v7.5.17-Paket nicht auf TKG v2.2-Arbeitslastclustern in vSphere v6.7U3 installieren, die NSX ALB v21.1.4 oder früher als Lastausgleichsdienst verwenden.

Problemumgehung: Wenn in Ihren Arbeitslastclustern Grafana und NSX ALB verwendet werden, führen Sie ein Upgrade von vSphere auf v7.0+ und NSX ALB auf v21.1.5+ durch, bevor Sie ein Upgrade von TKG auf v2.2 durchführen.
Der Harbor-CVE-Export schlägt möglicherweise fehl, wenn die Ausführungs-ID 1.000.000 überschreitet

Harbor v2.7.1, die für TKG v2.2 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.
Golang-Schwachstelle in der Notary-Komponente von Harbor

CVE-2021-33194 ist in Notary vorhanden. Die Notary-Komponente ist in Harbor v2.6+ veraltet und wird in einer zukünftigen Version entfernt (siehe Versionshinweise zu Harbor v2.6.0). VMware empfiehlt die Verwendung von Sigstore Cosign anstelle von Notary für die Container-Signierung und -Überprüfung.
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

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 war die Kubernetes-Standardversion in TKG v1.6.1, wie in Unterstützte Kubernetes-Versionen in Tanzu Kubernetes Grid v2.2 aufgeführt.

Problemumgehung: Erstellen Sie einen Arbeitslastcluster, in dem Kubernetes 1.25.7, 1.24.11 oder 1.23.17 ausgeführt wird. Das Kubernetes-Projekt empfiehlt, dass Sie Komponenten auf der neuesten Patchversion einer aktuellen Nebenversion ausführen.
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.

IPv6-Netzwerke werden auf vSphere 8 nicht unterstützt

TKG v2.2 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.2 können Sie NSX Advanced Load Balancer (ALB) nicht als Diensttyp mit dem Ingress-Modus NodePortLocal für 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.
Golang-Schwachstelle in der Pinniped-Komponente

CVE-2022-41723 ist in Pinniped v0.12.1 vorhanden. Die Ausnutzung dieser Schwachstelle kann zu einem DDoS-Angriff des Pinniped-Diensts führen. Damit es nur selten zu einem solchen Vorfall kommt, können Sie Ingress-Filterung verwenden, um nur Datenverkehr von bekannten IP-Adressen wie einem Unternehmens-VPN-CIDR zuzulassen. Diese Schwachstelle wird in einer zukünftigen Version von Tanzu Kubernetes Grid behoben.
Das Generieren und Verwenden von kubeconfig für den vom Supervisor bereitgestellten Arbeitslastcluster verursacht den Fehler „unbekanntes Flag (unknown flag)“

In Tanzu CLI v0.25.0 und früher generiert das Plug-In cluster Dateien vom Typ kubeconfig, die das Argument --concierge-is-cluster-scoped enthalten können. Das Tanzu CLI v0.29.0-Plug-In pinniped-auth erkennt dieses Argument nicht. Diese temporäre Regression wurde in nachfolgenden Versionen behoben.

Da vSphere 8.0 das v0.25.0-Plug-In cluster einbettet, kann beim Herstellen einer Verbindung mit einem von Supervisor bereitgestellten Cluster über die CLI v0.29.0 (Version in TKG v2.2) folgender Fehler erzeugt werden:
```
Error: unknown flag: --concierge-is-cluster-scoped
Unable to connect to the server: getting credentials: exec: executable tanzu failed with exit code 1
```
Problemumgehung: Entfernen Sie in der Datei kubeconfig die Zeile unter args, die --concierge-is-cluster-scoped festlegt.

Speicher

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

Tanzu CLI

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.
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.

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.

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.

Windows

Windows-Worker werden in Umgebungen mit Internetzugangsbeschränkungen nicht unterstützt.

VMware unterstützt keine TKG-Arbeitslastcluster mit Windows-Worker-Knoten in Proxied- oder Air-Gapped-Umgebungen.

Problemumgehung: Wenden Sie sich an Ihren VMware-Vertreter. Einige TKG-Benutzer haben benutzerdefinierte Windows-Images erstellt und Arbeitslastcluster mit Windows-Workern in Offline-Umgebungen ausgeführt, z. B. wie in diesem inoffiziellen Repository beschrieben.

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.