Versionshinweise zu VMware Tanzu Kubernetes Grid v2.3

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

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

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. Aufgrund der früheren in Supervisor eingebetteten TKG-Version sind einige der Funktionen, die bei Verwendung eines eigenständigen TKG 2.3-Verwaltungsclusters verfügbar sind, nicht verfügbar, wenn Sie einen vSphere with Tanzu Supervisor zum Erstellen von Arbeitslastclustern verwenden. Spätere TKG-Versionen werden in künftigen vSphere-Update-Versionen in Supervisor eingebettet sein. Folglich ist die in die aktuelle Version von vSphere with Tanzu eingebettete Version von TKG zu einem bestimmten Zeitpunkt möglicherweise nicht so aktuell wie die neueste eigenständige Version von TKG. 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. Beispielsweise ist Tanzu CLI v1.0.0 vollständig abwärtskompatibel mit den von Supervisor bereitgestellten TKG 2.2-Plug-Ins.

Tanzu CLI und vSphere with Tanzu in vSphere 7

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.3.x umfasst die folgenden neuen Funktionen.

Tanzu Kubernetes Grid v2.3.1

Neue Funktionen in Tanzu Kubernetes Grid v2.3.1:

Unterstützt Kubernetes 1.26.8, 1.25.13 und 1.24.17; weitere Informationen finden Sie unter Unterstützte Kubernetes-Versionen
(vSphere) Wenn Sie ein Upgrade eines eigenständigen Verwaltungs- oder Arbeitslastclusters durchführen, können Sie eine OVA-Zielvorlage mithilfe der Option --vsphere-vm-template-name wie unter Auswählen einer OVA-Vorlage für das Upgrade beschrieben angeben.
Komponenten aktualisiert; weitere Informationen finden Sie unter Komponentenversion
- Die neueste kompatible Tanzu Standard-Repository-Version ist v2023.10.16. Sie hat eigene Versionshinweise in der Dokumentation zu Tanzu-Paketen. Weitere Informationen finden Sie in den Versionshinweisen zu Tanzu Standard-Repository v2023.10.16
Fehlerkorrekturen.

Tanzu Kubernetes Grid v2.3.0

Neue Funktionen in Tanzu Kubernetes Grid v2.3.0:

Neuer Verteilungsmechanismus für eigenständige Tanzu CLI-Plug-Ins, einschließlich eigenständiger Tanzu CLI-Plug-Ins für Tanzu Kubernetes Grid. Darüber hinaus wird die Tanzu Core CLI jetzt separat von Tanzu Kubernetes Grid verteilt. Anweisungen zum Installieren der Tanzu CLI für die Verwendung mit Tanzu Kubernetes Grid finden Sie unter Installieren der Tanzu CLI und Kubernetes-CLI für die Verwendung mit eigenständigen Verwaltungsclustern.
Das Tanzu Standard-Paket-Repository ist versioniert und wird separat von TKG verteilt. Siehe Tanzu Standard-Repository v2023.7.13 unten.
- Die neueste kompatible Tanzu Standard-Repository-Version für TKG v2.3.0 ist Tanzu Standard-Repository v2023.7.13.
Sie können Arbeitslastcluster und eigenständige Verwaltungscluster in mehreren Verfügbarkeitszonen (Availability Zones, AZs) ausführen und die AZs ändern, in denen ihre Knoten ausgeführt werden.
- Wie Sie neue Arbeitslastcluster über mehrere AZs hinweg bereitstellen und vorhandene Verwaltungs- und Arbeitslastcluster so ändern, dass sie in mehreren oder unterschiedlichen AZs ausgeführt werden, erfahren Sie unter Ausführen von Clustern über mehrere Verfügbarkeitszonen hinweg.
- Informationen zur Verwendung der Installationsprogramm-Schnittstelle zur Konfiguration eines neuen eigenständigen Verwaltungsclusters für die Ausführung in mehreren AZs finden Sie unter Konfigurieren von vSphere-Ressourcen.
- Die Unterstützung für mehrere AZs befindet sich im Funktionsstatus Stabil.
Einzelknotencluster sind upgradefähig und werden für Telco Cloud Automation (TCA) unterstützt. Siehe Einzelknotencluster auf vSphere.
- Für das optimierte Bereitstellungsverfahren müssen keine tiny TKrs zum Verwaltungscluster hinzugefügt werden.
- Sie können Tanzu Mission Control (TMC) nicht zum Erstellen und Verwalten von Einzelknotenclustern verwenden, aber diese Funktion ist für eine zukünftige Version von TMC geplant.
Sie können einen clusterweiten Zugangscontroller für Pod-Sicherheit (Pod Security Admission, PSA) mit neuen Cluster-Konfigurationsdateivariablen POD_SECURITY_STANDARD_* und Cluster-spezifischen podSecurityStandard-Einstellungen konfigurieren, wie unter Zugangscontroller für Pod-Sicherheit beschrieben.
- PSA-Unterstützung befindet sich im Funktionszustand Stabil.
(vSphere) Funktionen für die IP-Adressverwaltung (IPAM) in Clustern wurden erweitert. Siehe Knoten-IPAM:
- IPAM für eigenständige Verwaltungscluster zusätzlich zu klassenbasierten Arbeitslastclustern.
- IPv6-Unterstützung.
- Arbeitslastcluster in unterschiedlichen Verwaltungs-Namespaces können IP-Adressen aus demselben globalen IP-Pool zuteilen.
- IP-Pools können nicht zusammenhängende IP-Bereiche enthalten.
- Die IP-Pool-Abfrage kubectl get inclusterippool gibt die Anzahl der FREE- und USED-Adressen aus.
- Clusterkonfigurationsvariablen, die unter Knoten-IPAM in der Variablenreferenz für Konfigurationsdatei beschrieben werden.
- Die Struktur des InClusterIPPool-Objekts unterscheidet sich von früheren TKG-Versionen. Ein Cluster-Upgrade auf v2.3 konvertiert IP-Pools in die neue Struktur.
Cluster, die die Calico-CNI verwenden, führen die IP-Adresserkennung durch. Siehe Calico-CNI unter Pod- und Containernetzwerke.
Edge-Arbeitslastcluster mit isolierten Speicher können ihre eigenen lokal gespeicherten VM-Vorlagen verwenden. Siehe Angeben einer lokalen VM-Vorlage.
Die neue Clusterkonfigurationsdatei-Variable VSPHERE_MTU legt die Größe der maximalen Übertragungseinheit (MTU) für Verwaltungs- und Arbeitslastcluster-Knoten auf vSphere fest. Siehe Konfigurieren der Clusterknoten-MTU.
Sie können Cluster für die Verwendung alternativer Maschinen-Images konfigurieren, indem Sie deren Objektspezifikationen kommentieren und TKrs erstellen oder ändern. Siehe Verwenden eines alternativen Maschinen-Images.
(vSphere) CONTROL_PLANE_NODE_NAMESERVERS und WORKER_NODE_NAMESERVERS befinden sich jetzt im Zustand Stabil. Sie können diese Variablen für Knoten unter Ubuntu oder Photon festlegen; Windows wird nicht unterstützt. Ein Anwendungsbeispiel finden Sie unter Knoten-IPAM.
Sie können jetzt ein Upgrade von Clustern durchführen, die Sie aus einer benutzerdefinierten ClusterClass-Definition in einer früheren Version erstellt haben. Weitere Informationen finden Sie unter Upgrade von benutzerdefinierten Clustern.
Neue Flags für Maschinenintegritätsprüfungen, --max-unhealthy und --machine-deployment. Siehe Verwalten von Maschinenintegritätsprüfungen für Arbeitslastcluster.
Mit der neuen tanzu mc credentials update-Option --vsphere-thumbprint können Sie den TLS-Fingerabdruck Ihrer vCenter Server in Verwaltungsclustern und Arbeitslastclustern auf vSphere mithilfe der Tanzu CLI aktualisieren. Informationen finden Sie unter Aktualisieren von Cluster-Anmeldedaten.
Bei neu erstellten planbasierten Clustern wird das Tanzu Standard-Paketrepositorys nicht standardmäßig hinzugefügt.
Die Pinniped-Komponente verwendet nicht mehr Dex für LDAP-Identitätsanbieter, was zu den folgenden Konfigurationsänderungen führt:
- Neue Konfigurationsvariable: LDAP_GROUP_SEARCH_SKIP_ON_REFRESH
- Aktualisierte Konfigurationsvariablen:
- LDAP_BIND_DN und LDAP_BIND_PASSWORD sind jetzt erforderlich.
- LDAP_GROUP_SEARCH_NAME_ATTRIBUTE ist standardmäßig dn.
- LDAP_USER_SEARCH_FILTER und LDAP_GROUP_SEARCH_FILTER müssen in dem von Pinniped verwendeten Format festgelegt werden.
- Entfernte Konfigurationsvariablen: LDAP_USER_SEARCH_USERNAME, LDAP_USER_SEARCH_EMAIL_ATTRIBUTE und LDAP_GROUP_SEARCH_GROUP_ATTRIBUTE.
Die Entfernung von Dex bedeutet, dass Sie die LDAP-Einstellungen eines Verwaltungsclusters ändern müssen, bevor Sie ihn auf TKG v2.3 aktualisieren. Siehe (nur LDAP) Aktualisieren der LDAP-Einstellungen.
Weitere Informationen zu den neuen und aktualisierten Konfigurationsvariablen finden Sie unter Identitätsanbieter – LDAP in Variablenreferenz für Konfigurationsdatei.
Da das Tanzu Standard-Paketrepositorys getrennt von TKG verteilt wird, wird in der TKG BoM-Datei kein grafana-Container-Image mehr aufgeführt. Es ist geplant, andere Tanzu Standard-Komponenten in einer zukünftigen Version aus dem BoM zu entfernen.
- Eine Liste der Komponenten, die über das Tanzu Standard-Paket-Repository verteilt sind, finden Sie in den Versionshinweisen zu Tanzu Standard-Repository v2023.10.16 in der Dokumentation zu Tanzu-Paketen oder unter Tanzu Standard Repository v2023.7.13 unten.

Tanzu Standard-Repository

Mit TKG v2.3 wird das Tanzu Standard-Paketrepository separat von TKG versioniert und verteilt, und seine Versionierung basiert auf einem Datumsstempel. Weitere Informationen finden Sie unter Tanzu Standard-Repository v2023.7.13 unten.

Für jede TKG v2.3-Patch-Version finden Sie die Versionshinweise für die neueste kompatible Tanzu Standard-Repository-Version:

TKG v2.3.1: Versionshinweise zum Tanzu Standard-Repository v2023.10.16 in der Dokumentation zu Tanzu-Paketen
TKG v2.3.0: Tanzu Standard Repository v2023.7.13 unten.

Unterstützte Kubernetes-, TKG- und Paketversionen

Ab TKG v2.2 änderte sich die Supportrichtlinie von VMware für ältere Patchversionen von TKG und TKrs, 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 ersten beiden Abschnitten unten wird die Unterstützung für alle aktuell unterstützten Versionen von TKG und TKrs unter den jeweils geltenden Supportrichtlinien zusammengefasst.

Im dritten Abschnitt unten sind die Versionen der Pakete im Tanzu Standards-Repository aufgeführt, die von Kubernetes v1.26, v1.25 und v1.24 TKrs unterstützt werden.

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.3 mit Kubernetes v1.26, v1.25 und v1.24 zum Zeitpunkt der Veröffentlichung. Sobald TKG v2.1 den Meilenstein "Ende des allgemeinen Supports" erreicht hat, unterstützt VMware Kubernetes v1.24 mit TKG nicht mehr. Sobald TKG v2.2 den Meilenstein "Ende des allgemeinen Supports" erreicht hat, unterstützt VMware Kubernetes v1.25 mit TKG nicht mehr.

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.

Tanzu Kubernetes Grid-Patchversionen unterstützen oder unterstützte TKr-Patchversionen wie unten aufgeführt.

Version von Tanzu Kubernetes Grid	Kubernetes-Version des Verwaltungsclusters	Bereitgestellte Kubernetes-Versionen (TKr)
2.3.1	1.26.8	1.26.8, 1.25.13, 1.24.17
2.3.0	1.26.5	1.26.5, 1.25.10, 1.24.14
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

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. 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.3.0 endet beispielsweise zwei Monate, nachdem TKG v2.3.1 allgemein zur Verfügung gestellt wurde.

Unterstützte Paketversionen

Für TKG v2.3 sind die Paketversionen im Tanzu Standard-Repository mit den TKrs für Kubernetes-Nebenversionen v1.26, v1.25 und v1.24 wie folgt kompatibel:

Paket	Paketversion	Kubernetes v1.26 TKrs	Kubernetes v1.25 TKrs	Kubernetes v1.24 TKrs
Cert Manager cert-manager.tanzu.vmware.com	1.11.1+vmware.1-tkg.1-20230629	✔	✔	✔
Contour contour.tanzu.vmware.com	1.24.4+vmware.1-tkg.1-20230629	✔	✔	✔
External DNS external-dns.tanzu.vmware.com	0.13.4+vmware.2-tkg.1-20230629	✔	✔	✔
	0.12.2+vmware.5-tkg.2-20230629	✔	✔	✔
	0.11.1+vmware.5-tkg.2-20230629	✖	✖	✔
Fluent Bit fluent-bit.tanzu.vmware.com	2.1.2+vmware.1-tkg.1-20230629	✔	✔	✔
	1.9.5+vmware.1-tkg.3-zshippable	✔	✔	✔
	1.8.15+vmware.1-tkg.1	✖	✖	✔
FluxCD Help Controller fluxcd-helm-controller.tanzu.vmware.com	0.32.0+vmware.1-tkg.2-20230629	✔	✔	✔
	0.21.0+vmware.1-tkg.1-zshippable	✖	✖	✔
FluxCD Source Controller fluxcd-source-controller.tanzu.vmware.com	0.33.0+vmware.2-tkg.1-20230629	✔	✔	✔
Grafana grafana.tanzu.vmware.com	9.5.1+vmware.2-tkg.1-20230629	✔	✔	✔
Grafana grafana.tanzu.vmware.com	7.5.17+vmware.1-tkg.3-zshippable	✖	✖	✔
Harbor harbor.tanzu.vmware.com	2.8.2+vmware.2-tkg.1-20230629	✔	✔	✔
Multus CNI multus-cni.tanzu.vmware.com	3.8.0+vmware.3-tkg.1	✔	✔	✔
Multus CNI multus-cni.tanzu.vmware.com	4.0.1+vmware.1-tkg.1-20230629	✔	✔	✔
Prometheus prometheus.tanzu.vmware.com	2.43.0+vmware.2-tkg.1-20230629	✔	✔	✔
	2.37.0+vmware.3-tkg.1	✔	✔	✔
	2.36.2+vmware.1-tkg.1	✖	✖	✔
Whereabouts whereabouts.tanzu.vmware.com	0.6.1+vmware.2-tkg.1-20230629	✔	✔	✔
Whereabouts whereabouts.tanzu.vmware.com	0.5.4+vmware.2-tkg.1	✔	✔	✔

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

Tanzu Kubernetes Grid v2.3 unterstützt die folgenden Infrastrukturplattformen und Betriebssysteme sowie Clustererstellung und -verwaltung, Netzwerk, Speicher, Authentifizierung, Sicherung und Migration und Beobachtbarkeitskomponenten.

Weitere Paketversionen, die mit TKG v2.3 kompatibel sind, finden Sie in den Versionshinweisen zum Tanzu Standard-Repository v2023.10.16 in der Dokumentation zu Tanzu-Paketen.

Eine vollständige Liste der Komponentenversionen in TKG v2.3 finden Sie unter Komponentenversionen.

	vSphere	AWS	Azure
Infrastrukturplattform	vSphere 7.0, 7.0U1-U3 vSphere 8.0, 8.0U1 VMware Cloud on AWS* v1.20, v1.22 Azure VMware Solution v2.0	Natives AWS	Natives Azure
Tanzu CLI	Tanzu CLI Core v1.0.0**
TKG-API und Paketinfrastruktur	Tanzu Framework v0.30.2
Clustererstellung und -verwaltung	Kerncluster-API (v1.4.5), Cluster-API-Anbieter vSphere (v1.7.1)	Kerncluster-API (v1.4.5), Cluster-API-Anbieter AWS (v2.1.3)	Kerncluster-API (v1.4.5), Cluster-API-Anbieter Azure (v1.9.2)
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.11.2), Calico (v3.25.1), Multus CNI (v4.0.1, v3.8.0)
Containerregistrierung	Harbor (v2.8.4)
Ingress	NSX Advanced Load Balancer Essentials und Avi-Controller **** (v21.1.4-v21.1.6, v22.1.2-v22.1.3), NSX v4.1.0 (vSphere 8.0.u1), v3.2.2 (vSphere 7), Contour (v1.25.2)	Contour (v1.25.2)	Contour (v1.25.2)
Speicher	vSphere Container Storage Interface (v3.0.1*****) und vSphere Cloud Native Storage	Amazon EBS CSI-Treiber (v1.18.0) und Cloud-Anbieter in der Struktur	Azure Disk CSI-Treiber (v1.27.1), Azure File CSI-Treiber (v1.27.0) und Cloud-Anbieter in der Struktur
Authentifizierung	OIDC und LDAP über Pinniped (v0.24.0)
Beobachtbarkeit	Fluent Bit (v2.1.6), Prometheus (v2.45.0, v2.37.0)******, Grafana (v10.0.1)
Diensterkennung	External DNS (v0.13.4)
Sicherung und Migration	Velero (v1.10.3)

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

** Eine vollständige Liste der Tanzu CLI-Versionen, die mit dieser Version von kompatibel sind, finden Sie unter 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.

***** Version von vsphere_csi_driver. Eine vollständige Liste der in dieser Version enthaltenen vSphere Container Storage Interface-Komponenten finden Sie unter Komponentenversionen.

****** Wenn Sie einen Cluster auf Kubernetes v1.25 upgraden, müssen Sie auch ein Upgrade von Prometheus auf mindestens 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.3 enthalten sind, finden Sie unter Unterstützte Kubernetes-Versionen weiter oben.

Komponentenversionen

Die Version TKG v2.3.x enthält die folgenden Softwarekomponentenversionen:

Hinweis
Frühere TKG-Versionen enthielten Komponenten, die jetzt über das Tanzu Standard-Repository verteilt werden. Eine Liste dieser Komponenten finden Sie unter Tanzu Standard-Repository unten.

Komponente	TKG v2.3.1	TKG v2.3.0
aad-pod-identity	v1.8.15+vmware.2	v1.8.15+vmware.2^*
addons-manager	v2.2+vmware.1	v2.2+vmware.1^*
ako-operator	v1.9.0_vmware.1	v1.9.0_vmware.1^*
alertmanager	v0.25.0_vmware.4^*	v0.25.0_vmware.3^*
antrea	v1.11.2_vmware.1^*	v1.11.1_vmware.4^*
antrea-interworking	v0.11.1^*	v0.11.0^*
aws-ebs-csi-driver	v1.18.0+vmware.2	v1.18.0+vmware.2^*
azuredisk-csi-driver	v1.27.1+vmware.3^*	v1.27.1+vmware.2^*
azurefile-csi-driver	v1.27.0+vmware.3^*	v1.27.0+vmware.2^*
calico	v3.25.1+vmware.2	v3.25.1+vmware.2^*
capabilities-package	v0.30.2-capabilities^*	v0.30.2-capabilities^*
carvel-secretgen-controller	v0.14.2+vmware.2	v0.14.2+vmware.2^*
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.10+vmware.1
cloud_provider_vsphere	v1.24.6+vmware.1, v1.26.2+vmware.1, v1.25.3+vmware.1	v1.24.6+vmware.1^, v1.26.2+vmware.1^, v1.25.3+vmware.1^*
cluster-api-provider-azure	v1.9.2+vmware.1	v1.9.2+vmware.1^*
cluster_api	v1.4.5+vmware.1^*	v1.4.2+vmware.3^*
cluster_api_aws	v2.1.3+vmware.0	v2.1.3+vmware.0^*
cluster_api_vsphere	v1.7.1+vmware.0^*	v1.7.0+vmware.0^*
cni_plugins	v1.1.1+vmware.28^*	v1.1.1+vmware.23^*
configmap-reload	v0.8.0+vmware.3^*	v0.8.0+vmware.2^*
containerd	v1.6.18+vmware.1	v1.6.18+vmware.1
coredns	v1.9.3+vmware.16^*	v1.9.3+vmware.11^*
crash-diagnostics	v0.3.7+vmware.7	v0.3.7+vmware.7^*
cri_tools	v1.25.0+vmware.10^*	v1.25.0+vmware.6^*
csi_attacher	v4.2.0+vmware.4^*, v4.0.0+vmware.1, v3.5.0+vmware.1, v3.4.0+vmware.1, v3.3.0+vmware.1	v4.2.0+vmware.2^, v4.0.0+vmware.1^, v3.5.0+vmware.1, v3.4.0+vmware.1, v3.3.0+vmware.1
csi_livenessprobe	v2.9.0+vmware.4^*, v2.8.0+vmware.1, v2.7.0+vmware.1, v2.6.0+vmware.1, v2.5.0+vmware.1, v2.4.0+vmware.1	v2.9.0+vmware.2^, v2.8.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.7.0+vmware.4^*, v2.7.0+vmware.2, v2.6.3+vmware.1, v2.6.2+vmware.1, v2.5.1+vmware.1, v2.5.0+vmware.1, v2.3.0+vmware.1	v2.7.0+vmware.1^, v2.7.0+vmware.2^, v2.6.3+vmware.1^, v2.6.2+vmware.1^, v2.5.1+vmware.1, v2.5.0+vmware.1, v2.3.0+vmware.1
csi_provisioner	v3.4.1+vmware.3^, v3.4.0+vmware.4^, v3.3.0+vmware.1, v3.2.1+vmware.1, v3.1.0+vmware.2	v3.4.1+vmware.2^, v3.4.0+vmware.2^, v3.3.0+vmware.1^*, v3.2.1+vmware.1, v3.1.0+vmware.2
dex	Nicht verfügbar	Entfernt
Envoy	v1.25.9+vmware.1^*	v1.25.6+vmware.1^*
external-snapshotter	v6.2.1+vmware.4^*, v6.1.0+vmware.1, v6.0.1+vmware.1, v5.0.1+vmware.1	v6.2.1+vmware.2^, v6.1.0+vmware.1^, v6.0.1+vmware.1, v5.0.1+vmware.1
etcd	v3.5.6+vmware.20^*	v3.5.6+vmware.14^*
guest-cluster-auth-service	v1.3.0_tkg.2	v1.3.0_tkg.2
image-builder	v0.1.14+vmware.1	v0.1.14+vmware.1^*
image-builder-resource-bundle	v1.26.8+vmware.1-tkg.2^*	v1.26.5+vmware.2-tkg.1^*
imgpkg	v0.36.0+vmware.2	v0.36.0+vmware.2^*
jetstack_cert-manager (cert-manager)	v1.11.1+vmware.1	v1.11.1+vmware.1^*
k8s-sidecar	v1.22.4+vmware.2^*	v1.22.0+vmware.2^*, v1.15.6+vmware.5, v1.12.1+vmware.6
k14s_kapp (kapp)	v0.55.0+vmware.2	v0.55.0+vmware.2^*
k14s_ytt (ytt)	v0.45.0+vmware.2	v0.45.0+vmware.2^*
kapp-controller	v0.45.2+vmware.1	v0.45.2+vmware.1^*
kbld	v0.37.0+vmware.2	v0.37.0+vmware.2^*
kube-state-metrics	v2.8.2+vmware.1	v2.8.2+vmware.1^*
kube-vip	v0.5.12+vmware.1	v0.5.12+vmware.1
kube-vip-cloud-provider	v0.0.5+vmware.1, v0.0.4+vmware.4	v0.0.5+vmware.1^*, v0.0.4+vmware.4
kubernetes	v1.26.8+vmware.1^, v1.25.13+vmware.1^, v1.24.17+vmware.1^*	v1.26.5+vmware.2^, v1.25.10+vmware.2^, v1.24.14+vmware.2
kubernetes-csi_external-resizer	v1.7.0+vmware.4^*, v1.6.0+vmware.1, v1.5.0+vmware.1, v1.4.0+vmware.1	v1.7.0+vmware.2^, v1.6.0+vmware.1^, v1.5.0+vmware.1^*, v1.4.0+vmware.1
kubernetes-sigs_kind	v1.26.8+vmware.1-tkg.2_v0.17.0^, v1.25.13+vmware.2-tkg.1_v0.17.0^, v1.24.17+vmware.2-tkg.1_v0.17.0^*	v1.26.5+vmware.2-tkg.1_v0.17.0^, v1.25.10+vmware.2-tkg.1_v0.17.0^, v1.24.14+vmware.2-tkg.1_v0.17.0^*
kubernetes_autoscaler	v1.26.2+vmware.1	v1.26.2+vmware.1^*
load-balancer-and-ingress-service (AKO)	v1.9.3+vmware.2-tkg.1	v1.9.3+vmware.2-tkg.1^*
metrics-server	v0.6.2+vmware.1	v0.6.2+vmware.1
pinniped	v0.24.0+vmware.1-tkg.1	v0.24.0+vmware.1-tkg.1^*
pinniped-post-deploy	v0.24.0+vmware.1	v0.24.0+vmware.1^*
prometheus_node_exporter	v1.5.0+vmware.3^*	v1.5.0+vmware.2^*
pushgateway	v1.5.1+vmware.3^*	v1.5.1+vmware.2^*
sonobuoy	v0.56.16+vmware.2	v0.56.16+vmware.2^*
tanzu-framework	v0.30.2^*	v0.30.2^*
tanzu-framework-addons	v0.30.2^*	v0.30.2^*
tanzu-framework-management-packages	v0.30.2^*	v0.30.2^*
tkg-bom	v2.3.1^*	v2.3.0^*
tkg-core-packages	v1.26.8+vmware.1-tkg.2^*	v1.26.8+vmware.2-tkg.1^*
tkg-standard-packages	v2023.10.16^*	v2023.7.13^*
tkg-storageclass-package	v0.30.2^*	v0.30.2^*
tkg_telemetry	v2.3.1+vmware.3^*	v2.3.0+vmware.2^*
velero	v1.10.3+vmware.1	v1.10.3+vmware.1^*
velero-mgmt-cluster-plugin^*	v0.2.0+vmware.1	v0.2.0+vmware.1^*
velero-plugin-for-aws	v1.6.2+vmware.1	v1.6.2+vmware.1^*
velero-plugin-for-csi	v0.4.3+vmware.1	v0.4.3+vmware.1^*
velero-plugin-for-microsoft-azure	v1.6.2+vmware.1	v1.6.2+vmware.1^*
velero-plugin-for-vsphere	v1.5.1+vmware.1	v1.5.1+vmware.1^*
vendir	v0.33.1+vmware.2	v0.33.1+vmware.2^*
vsphere_csi_driver	v3.0.1+vmware.4^*	v3.0.1+vmware.2^*

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

Eine Liste der Softwarekomponentenversionen, die im Lieferumfang von TKG v2.3 enthalten sind, erhalten Sie, indem Sie mithilfe von imgpkg Repository-Pakete abrufen und dann deren Inhalt auflisten. Um beispielsweise die Komponentenversionen aufzulisten, die im Lieferumfang des Tanzu Standard-Repository für TKG v2.3.1 enthalten sind, führen Sie den folgenden Befehl aus:

imgpkg pull -b projects.registry.vmware.com/tkg/packages/standard/repo:v2023.10.16 -o standard-2023.10.16

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.3.1.yaml
~/.config/tanzu/tkg/bom/tkr-bom-v1.26.8+vmware.2-tkg.1.yaml

Unterstützte Upgrade-Pfade

Im TKG-Upgrade-Pfad folgt v2.3 unmittelbar auf v2.2.0.

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

Veröffentlichungsdaten

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

v2.3.1: 9. November 2023
v2.3.0: 1. August 2023

Verhaltensänderungen in Tanzu Kubernetes Grid v2.3

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

Die Carvel-Tools werden in einem dedizierten Download-Paket ausgeliefert. Weitere Informationen finden Sie unter Installieren der Carvel-Tools.
Wenn Sie einen OIDC-Identitätsanbieter (IDP) für die Identitäts- und Zugriffsverwaltung über Pinniped verwenden, muss der OIDC-IDP so konfiguriert sein, dass er ein Aktualisierungstoken ausgibt.
- Dies kann eine zusätzliche Konfiguration im OIDC-IDP erfordern.
- Ein Okta-Beispiel finden Sie unter Konfigurieren der Identitätsverwaltung.
- Wenn Ihr OIDC-IDP zusätzliche Geltungsbereiche oder Parameter benötigt, um ein Aktualisierungstoken zurückzugeben, konfigurieren Sie OIDC_IDENTITY_PROVIDER_SCOPES und OIDC_IDENTITY_PROVIDER_ADDITIONAL_AUTHORIZE_PARAMS mit den erforderlichen Geltungsbereichen oder Parametern.
Tanzu Kubernetes Grid verwendet Dex nicht mehr für LDAP-Identitätsanbieter. Jede Konfigurationsvariable, die im Abschnitt Identitätsanbieter – LDAP unter Variablenreferenz für Konfigurationsdatei aufgeführt ist, entspricht nun einer Konfigurationseinstellung in der benutzerdefinierten Ressource LDAPIdentityProvider von Pinniped. Aktualisieren Sie vor dem Upgrade eines Verwaltungsclusters, der für die Verwendung eines LDAP-Identitätsanbieters für Tanzu Kubernetes Grid v2.3 konfiguriert ist, Ihre LDAP-Einstellungen wie unter (Nur LDAP) Aktualisieren der LDAP-Einstellungen beschrieben. Alle vorhandenen LDAP-Einstellungen werden während des Upgrades des Verwaltungsclusters auf Version 2.3 automatisch in das neue Pinniped-Format migriert.
Velero v1.10 führt Breaking Changes im Vergleich zu den Versionen von Velero ein, die mit früheren Versionen von TKG ausgeliefert wurden. Informationen darüber, wie Sie diese Breaking Changes beim Upgrade von Velero v1.9.x auf v1.10 abmildern können, finden Sie unter Upgrade von Velero.
Beim Upgrade von Tanzu Kubernetes Grid auf v2.3 auf AWS müssen Sie nach dem Upgrade der Tanzu CLI, aber vor dem Upgrade des Verwaltungsclusters tanzu mc permissions aws set ausführen. Weitere Informationen finden Sie auf der Registerkarte AWS in Vorbereitungen für das Upgrade von Clustern.
Beim Erstellen von benutzerdefinierten ClusterClass-Objektdefinitionen laden Sie nicht mehr das Standardmanifest aus dem Tanzu Framework-Repository herunter. Das Standardmanifest wird zur Verfügung gestellt, wenn Sie einen Verwaltungscluster erstellen oder die Tanzu CLI installieren, oder Sie können es aus dem TKG-Image-Repository abrufen. Weitere Informationen finden Sie unter Erstellen einer benutzerdefinierten ClusterClass.
Wenn Sie einen Arbeitslastcluster mit einer Kubernetes-Patch-Version bereitstellen, die älter ist als der neueste unterstützte Patch für seine Nebenversion, müssen Sie ein ConfigMap-Objekt für sein TKr erstellen, bevor Sie den Cluster bereitstellen. Weitere Informationen finden Sie unter Bereitstellen des Kubernetes-Clusters auf der Seite Mehrere Kubernetes-Versionen.

Hinweise zu künftigen Verhaltensänderungen

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

Hinweise zu veralteten Funktionen

Der Befehl tanzu login wird in zukünftigen TKG-Versionen entfernt. Der Befehl wird durch den tanzu context-Befehl ersetzt. Weitere Informationen finden Sie in der VMware Tanzu CLI-Dokumentation unter Tanzu-Kontext.

Benutzerdokumentation

Unter Bereitstellen und Verwalten eigenständiger TKG 2.3-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.

Behoben in v2.3.1

Tanzu Kubernetes Grid v2.3.1 behebt nicht dokumentierte Probleme und Fehler von Kunden.

Behoben in v2.3.0

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

IPv6-Netzwerke werden auf vSphere 8 nicht unterstützt

TKG v2.3 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.
Automatische Clusterskalierung fügt nicht die erwarteten Schlüssel zur MachineDeployment hinzu

Wenn Sie einen Cluster mit aktivierter automatischer Clusterskalierung erstellen, werden die erwarteten Schlüssel cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size und cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size nicht zu metadata.annotations im MachineDeployment hinzugefügt.
Die Rollout-Variable des Worker-Knotens fehlt in ClusterClass-Konfigurationen

Die WORKER_ROLLOUT_STRATEGY -Variable, die Sie zum Festlegen der Rollout-Strategie für Arbeitslastcluster MachineDeployments verwenden, fehlte in den ClusterClass-Konfigurationen für alle Zielplattformen. Sie können jetzt die WORKER_ROLLOUT_STRATEGY-Variable sowohl auf klassenbasierten als auch auf Legacy-Plan-basierten Clustern festlegen. Weitere Informationen finden Sie unter GPU-fähige Cluster in der Variablenreferenz für Konfigurationsdatei.
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.
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.
Der Harbor-CVE-Export schlägt möglicherweise fehl, wenn die Ausführungs-ID 1.000.000 überschreitet

Harbor v2.7.1, die Version, die für TKG v2.2 gepackt wurde, 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.
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.
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 nicht in den MachineDeployment-Objekten des Clusters festgelegt und müssen manuell hinzugefügt werden.
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.

Bekannte Probleme

Im Folgenden sind bekannte Probleme in Tanzu Kubernetes Grid v2.3.x aufgeführt. Alle bekannten Probleme, die in v2.3.0 vorhanden waren und in einer nachfolgenden Patchversion von v2.3.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

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

In AWS und Azure schlägt das Erstellen eines Arbeitslastclusters mit Objektspezifikation mit einem Zonen-/Regionsfehler fehl

In AWS oder Azure führt die Ausführung von tanzu cluster create mit einer klassenbasierten Clusterobjektspezifikation, die an --file übergeben wird, dazu, dass die Tanzu-CLI Regions- und Zonenüberprüfungen durchführt, die nur für vSphere Verfügbarkeitszonen relevant sind.

Problemumgehung Führen Sie beim Erstellen eines klassenbasierten Clusters in AWS oder Azure einen der folgenden Schritte aus, je nachdem, ob Sie den einstufigen oder den unter Erstellen eines klassenbasierten Clusters beschriebenen zweistufigen Vorgang verwenden:
- Einstufig: Befolgen Sie den einstufigen Prozess wie beschrieben, indem Sie features.cluster.auto-apply-generated-clusterclass-based-configuration auf true festlegen und --dry-run nicht an den Befehl tanzu cluster create übergeben.
- Zweistufig: Bevor Sie tanzu cluster create mit der Objektspezifikation als zweiten Schritt ausführen, legen Sie SKIP_MULTI_AZ_VERIFY in Ihrer lokalen Umgebung auf true fest:
```
export SKIP_MULTI_AZ_VERIFY=true
```
Komponenten können bei Clustern mit begrenzter Kapazität nicht geplant werden

Wenn Sie bei Verwaltungsclustern und Arbeitslastclustern Cluster mit einem einzelnen Steuerungsebenenknoten, einem einzelnen Worker-Knoten oder kleinen oder mittleren Clustern bereitstellen, kann es zu Konflikten bei der Ressourcenplanung kommen.

Problemumgehung: Verwenden Sie entweder Einzelknotencluster oder Cluster mit insgesamt drei oder mehr Knoten.
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.26.8, 1.25.13 oder 1.24.17 ausgeführt wird. Das Kubernetes-Projekt empfiehlt, dass Sie Komponenten auf der neuesten Patchversion einer aktuellen Nebenversion ausführen.
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.

Netzwerk

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

Einige NSX ALB-Konfigurationsvariablen funktionieren nicht

In TKG v2.3 funktionieren die Konfigurationsvariablen AVI_DISABLE_INGRESS_CLASS, AVI_DISABLE_STATIC_ROUTE_SYNC und AVI_INGRESS_DEFAULT_INGRESS_CONTROLLER des Verwaltungsclusters nicht.

Um eine der zugrunde liegenden Eigenschaften auf den nicht standardmäßigen Wert true festzulegen, müssen Sie die beiden Konfigurationsobjekte AKODeploymentConfig des Verwaltungsclusters wie unten beschrieben manuell bearbeiten, nachdem der Verwaltungscluster erstellt wurde.

Problemumgehung: Bearbeiten Sie die Objekte install-ako-for-all und install-ako-for-management-cluster im Verwaltungscluster:
1. Legen Sie den Kontext kubectl auf den Verwaltungscluster fest:
```
kubectl config use-context MGMT-CLUSTER-CONTEXT
```
2. Bearbeiten Sie die Konfigurationen install-ako-for-all und install-ako-for-management-cluster:
```
kubectl edit adc install-ako-for-all
```
```
kubectl edit adc install-ako-for-management-cluster
```
3. Legen Sie in den Konfigurationen die folgenden Eigenschaften nach Bedarf fest:
  - extraConfigs.ingress.disableIngressClass – für config var AVI_DISABLE_INGRESS_CLASS
  - extraConfigs.disableStaticRouteSync – für config var AVI_DISABLE_STATIC_ROUTE_SYNC
  - extraConfigs.ingress.defaultIngressController – für config var AVI_INGRESS_DEFAULT_INGRESS_CONTROLLER
4. Speichern und beenden Sie die Bearbeitung.
Diese Einstellungen gelten für Arbeitslastcluster, die der Verwaltungscluster anschließend erstellt.
NSX ALB-Ingress-Modus NodePortLocal wird für Verwaltungscluster nicht unterstützt

In TKG v2.3 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.

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.

vSphere

Die Bereitstellung von Verwaltungsclustern auf vSphere 7 schlägt fehl, wenn auf die Verfügbarkeit der Cluster-Steuerungsebene gewartet wird

Wenn Sie bei der Bereitstellung eines Verwaltungsclusters auf vSphere 7 das VM-Netzwerk angeben, schlägt die Bereitstellung mit der Fehlermeldung unable to set up management cluster: unable to wait for cluster control plane available: control plane is not available yet fehl.

Problemumgehung: Netzwerk „VM-Netzwerk“ verfügt dann über mehrere konfigurierte Subnetze mit statischen IPs für VsVip und ServiceEngine. Legen Sie exclude_discovered_subnets im VM-Netzwerk auf „True“ fest, um die entdeckten Subnetze zu ignorieren und die Platzierung von virtuellen Diensten auf den Dienst-Engines zu ermöglichen.
Verfügbarkeitszonen können gelöscht werden, während ihnen VMs zugewiesen sind

Wenn Sie eine Verfügbarkeitszone löschen, die VMs enthält, können die VMs anschließend nicht mehr gelöscht werden.

Problemumgehung: Entfernen Sie alle VMs aus einer Verfügbarkeitszone, bevor Sie sie löschen.
Das Erstellen von Arbeitslastclustern schlägt aufgrund einer ausgeschöpften VPXD-Sitzung fehl.

Beim Erstellen von Arbeitslastclustern auf vSphere schlägt die Erstellung mit dem folgenden Fehler fehl:
```
vSphere config validation failed: failed to get VC client: failed to create vc client: Post "https://address/sdk": EOF ". VCenter vpxd.log report error: Out of HTTP sessions: Limited to 2000
```
Dies geschieht aufgrund einer ausgeschöpften vCenter Server-Sitzung.

Problemumgehung: Siehe VMware KB 50114010.
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.

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.

Tanzu Standard-Repository v2023.7.13

Mit TKG v2.3 wird das Tanzu Standard-Paketrepository separat von TKG versioniert und verteilt, und seine Versionierung basiert auf einem Datumsstempel.

Für TKG v2.3.0 und v2.3.1 werden die TKG-Patch-Version und die neueste kompatible Tanzu Standard-Repository-Version zum selben Datum veröffentlicht.

Zukünftige Tanzu Standard Repository-Versionen können häufiger veröffentlicht werden als TKG-Versionen, aber bei allen Patchversionen wird die bestehende Kompatibilität zwischen Nebenversionen von TKG und Tanzu Standard beibehalten.

Für jede TKG v2.3-Patch-Version lautet die neueste kompatible Tanzu Standard-Repository-Version wie folgt:

TKG v2.3.1: Tanzu Standard v2023.10.16
- Versionshinweise: Weitere Informationen finden Sie in den Versionshinweisen zum Tanzu Standard-Repository v2023.10.16 in der Dokumentation zu Tanzu-Paketen
TKG v2.3.0: Tanzu Standard v2023.7.13
- Versionshinweise: Siehe unten

Unterstützung für Tanzu Standard Repository-Pakete

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.
VMware bietet Unterstützung auf Laufzeitebene für die von VMware unterstützten Pakete Harbor, Contour und Velero, wenn diese auf Tanzu Kubernetes Grid bereitgestellt werden.

Cert-manager v1.11.1

Neuheiten

Weitere Informationen finden Sie in den Versionshinweisen zu cert-manager v1.11.1
Das vmware_cert-manager-Paket enthält die Komponente acmesolver aus dem Upstream-jetstack_cert-manager.

Unterstützte Versionen


TKG-Version	jetstack_cert-manager-Version	vmware cert-manager-Paketversion	Kubernetes-Versionskompatibilität
2.3	v1.11.1	v1.11.1+vmware.1	1.21-1.27

Komponentenversionen

cert manager v1.11.1 enthält folgende Komponenten-Image-Versionen:

quay.io/jetstack/cert-manager-cainjector:v1.11.1
quay.io/jetstack/cert-manager-controller:v1.11.1
quay.io/jetstack/cert-manager-webhook:v1.11.1
quay.io/jetstack/cert-manager-acmesolver:v1.11.1

Auslaufende Versionen

Die folgenden cert-manager-Versionen sind in TKG v2.3 veraltet:

v1.5.3
v1.7.2
v1.10.2

Contour v1.24.4

Neuheiten

Weitere Informationen finden Sie in den Versionshinweisen zu Contour v1.24.0-4:
Sie können Envoy so konfigurieren, dass es als Bereitstellung mit einer bestimmten Anzahl von Replikaten und nicht als DaemonSet (Standard) installiert wird, indem Sie Datenwerte wie die folgenden verwenden:
```
envoy: 
  workload: 
    type: Deployment 
    replicas: 3
```

Sie können Ressourcenanforderungen oder -grenzen für jeden Container innerhalb der Contour- und Envoy-Arbeitslasten angeben, indem Sie Datenwerte wie die folgenden verwenden:

contour: 
  resources: 
    contour: 
      requests: 
        cpu: 250m 
        memory: 128Mi 
      limits: 
        cpu: 1 

        memory: 512Mi
envoy:
  resources:
    envoy:
# include requests and limits as desired
    shutdown-manager:
# include requests and limits as desired

data-values-Datei-Konfigurationswerte werden überprüft. Die Angabe eines nicht unterstützten Werts in den Datenwerten führt zu einem Fehler.

Unterstützte Kubernetes-Versionen

Contour v1.24.4 wird auf Kubernetes v1.24-v1.26 unterstützt. Weitere Informationen finden Sie in der Contour-Kompatibilitätsmatrix.

Auslaufende Versionen

Alle Contour-Versionen vor v1.24.4 wurden aus Tanzu Standard-Repository v2023.7.13 entfernt.
Contour-Paketdateien für data-values akzeptieren keine null-Werte mehr. Für jedes Konfigurationsfeld, dessen Wert auf null festgelegt ist, sollten Sie den Wert vollständig weglassen.

External-csi-snapshot-webhook v6.1.0

Neuheiten

external-csi-snapshot-webhook ist ein neues Paket für TKG v2.3
TKG v2.3 mit einem vSphere 8.0U2-Supervisor unterstützt CSI-Snapshots für Supervisor und die von ihm bereitgestellten Arbeitslastcluster. Sie müssen jedoch zuerst explizit external-csi-snapshot-webhook v6.1.0 mithilfe der Tanzu CLI installieren.

Unterstützte Versionen


TKG-Version	`external-csi-snapshot-webhook`-Version	Erwartete Kubernetes-Versionskompatibilität	Getestet auf Kubernetes-Version
2.3.0	6.1.0	1.18 – neueste Version	1.24

Abhängigkeiten

external-csi-snapshot-webhook erfordert cert-manager für eine sichere X509-Kommunikation mit dem Kubernetes-API-Server.

Komponentenversionen

external-csi-snapshot-webhook enthält die folgende Komponenten-Image-Version:

registry.k8s.io/sig-storage/snapshot-validation-webhook:v6.1.0

External DNS v0.13.4

Neuheiten

Weitere Informationen finden Sie in den Versionshinweisen zu External DNS v0.13.4
Neues Konfigurationsfeld createNamespace. Legen Sie diese Eigenschaft auf true fest, um den Namespace zu erstellen, in dem external-dns-Komponenten installiert werden. Wenn auf „false“ festgelegt, werden die Paketkomponenten in einen vorhandenen Namespace installiert.

Fluent-bit v2.1.2

Neuheiten

Weitere Informationen finden Sie in den Versionshinweisen zu Fluent Bit v2.1.2.

Einschränkungen/Bekannte Probleme

Unterstützt keine Umgebungsvariablen für AWS-Anmeldedaten im Fluent-Bit-Paket ConfigMap für den Zugriff auf AWS S3.
- Die Unterstützung von AWS-Anmeldedaten ist für eine zukünftige Version geplant.

Fluxcd-Controller

Neuheiten

Weitere Informationen finden Sie in den folgenden Versionshinweisen zum Fluxcd-Controller-Paket:

Fluxcd-helm-controller
- Versionshinweise zu fluxcd-helm-controller v0.21.0
- Versionshinweise zu fluxcd-helm-controller v0.28.1
Fluxcd-kustomize-controller
- Versionshinweise zu fluxcd-kustomize-controller v0.24.4
- Versionshinweise zu fluxcd-kustomize-controller v0.32.0
Fluxcd-source-controller
- Versionshinweise zu fluxcd-source-controller v0.24.4
- Versionshinweise zu fluxcd-source-controller v0.33.0

Grafana v9.5.1

Neuheiten

Weitere Informationen finden Sie in den Versionshinweisen zu Grafana v9.5.1

Komponentenversionen

Grafana v9.5.1 enthält die folgenden Komponenten-Image-Versionen:

grafana/grafana:9.5.1
kiwigrid/k8s-sidecar:1.22.0

Harbor v2.8.2

Neuheiten

Weitere Informationen finden Sie in den Versionshinweisen zu Harbor v2.8.2
Aufgrund von CVEs wurde die TKG v2.3-Kompatibilität mit den folgenden Harbor-Versionen entfernt:
- v2.2.3_vmware.1-tkg.1
- v2.2.3_vmware.1-tkg.2
- v2.3.3_vmware.1-tkg.1
- v2.5.3_vmware.1-tkg.1
- v2.7.1_vmware.1-tkg.1

Komponentenversionen

Harbor v2.8.2 enthält die folgenden Komponenten-Image-Versionen:

harbor-core:v2.8.2
harbor-db:v2.8.2
harbor-exporter:v2.8.2
harbor-jobservice:v2.8.2
harbor-portal:v2.8.2
harbor-registryctl:v2.8.2
registry-photon:v2.8.2
notary-server-photon:v2.8.2
notary-signer-photon:v2.8.2
redis-photon:v2.8.2
trivy-adapter-photon:v2.8.2

Multus-CNI v4.0.1

Neuheiten

Einführung einer Thick-Plugin-Bereitstellung und -Architektur. Weitere Informationen finden Sie unter Neue Funktion Multus-CNI v4.0.1

Ändert die Standardwerte wie folgt:

namespace: kube-system 
#! DaemonSet related configuration 
daemonset: 
  resources: 
    limits: 
      cpu: 100m 
      memory: 50Mi 
    requests: 
      cpu: 100m 
      memory: 50Mi 
configmap: 
  cniVersion: 0.3.1 
  multusConfigFile: auto

Prometheus v2.43.0

Neuheiten

Weitere Informationen finden Sie in den Versionshinweisen zu Prometheus v2.43.0

Komponentenversionen

Prometheus v2.43.0 enthält die folgenden Komponenten-Image-Versionen:

prom/prometheus:v2.43.0
prom/alertmanager:v0.25.0
Prom/pushgateway:v1.5.1
jimmidyson/configmap-reload:v0.8.0
bitnami/kube-state-metrics:2.8.2
quay.io/prometheus/node-exporter:v1.5.0

Velero v1.10.0

Neuheiten

Weitere Informationen finden Sie in den Versionshinweisen zu Velero v1.10.0
Kopia ersetzt Restic als Uploader. Dies führt zu den folgenden Breaking Changes. Weitere Informationen finden Sie unter Breaking Changes im Velero v1.10 Änderungsprotokoll:
- restic daemonset wurde in node-agent umbenannt
- ResticRepository-CR wurde in BackupRepository umbenannt
- velero restic repo-Befehl wurde in velero repo umbenannt
- Geheimer Schlüssel velero-restic-credentials wurde in velero-repo-credentials umbenannt
- Parameter default-volumes-to-restic wurde in default-volumes-to-fs-backup umbenannt
- Parameter restic-timeout wurde in fs-backup-timeout umbenannt
- Parameter default-restic-prune-frequency wurde in default-repo-maintain-frequency umbenannt
Vereinheitlicht das Sicherungs-Repository und entkoppelt es von Data Movern. Siehe Unified Repository & Kopia Integration Design.
Refaktoriert die Dateisystem-Sicherung, indem ein Kopia-Pfad neben dem vorhandenen Restic-Pfad hinzugefügt wird, wobei beide durch einen uploader-type-Konfigurationsparameter unterstützt werden.
- Weitere Informationen finden Sie unter Dateisystemsicherung und Upgrade auf Velero 1.10.
- Informationen zur Auswahl zwischen Kopia und Restic finden Sie im Velero File System Backup Performance Guide.
Verschiebt die Plug-Ins BackupItemAction, RestoreItemAction und VolumeSnapshotterAction in Version v1, um zukünftige Plug-In-Änderungen zuzulassen, die möglicherweise keine Abwärtskompatibilität unterstützen, wie z. B. komplexe Datenverschiebungsaufgaben. Weitere Informationen finden Sie unter Plugin Versioning.
Fügt Optionen zum Speichern von Anmeldedaten für bestimmte Speicherorte von Volume-Snapshots hinzu. Weitere Informationen finden Sie unter Sichern von Speicherorten und Volume-Snapshot-Speicherorten.
Verbessert die Robustheit des CSI-Snapshots durch Schutzcodes für die Fehlerbehandlung und die Möglichkeit, Ausschlussprüfungen zu überspringen, sodass der CSI-Snapshot mit verschiedenen Filtern für Sicherungsressourcen funktioniert.
Unterstützt das Anhalten/Fortsetzen des Sicherungsplans:
- Übergeben des Flag -paused an velero schedule create, um einen pausierten Zeitplan zu erstellen.
- Mit velero schedule pause und velero schedule unpause werden ein vorhandener Zeitplan angehalten und fortgesetzt.

Unterstützte Versionen


TKG-Version	Velero-Version	Erwartete Kubernetes-Versionskompatibilität	Getestet auf Kubernetes-Version
2.3(Halifax)	1.10	1.18 – neueste Version	1.22.5, 1.23.8, 1.24.6 und 1.25.1

Komponentenversionen

Velero v1.10.3 enthält die folgenden Komponenten-Image-Versionen:

velero/velero:v1.10.3
velero/velero-plugin-for-aws:v1.6.2
velero/velero-plugin-for-csi:v0.4.3
velero/velero-plugin-for-microsoft-azure:v1.6.2
vsphereveleroplugin/velero-plugin-for-vsphere:v1.5.1

Um CVEs zu beheben, werden die Velero-Laufzeit- und Abhängigkeitsversionen wie folgt aktualisiert:

Go-Laufzeit v1.18.8
Kompiliert Restic v0.13.1 mit Go 1.18.8 anstelle der Verpackung der offiziellen Restic-Binärdatei
Aktualisierte Versionen von abhängigen Kernbibliotheken

Upgrades

Vorherige Upgrade-Vorgänge funktionieren aufgrund von Änderungen der Dateisystemsicherung nicht. Die neuen Upgrade-Schritte finden Sie unter Upgrade auf Velero 1.10.

Einschränkungen/Bekannte Probleme

Kopia-Sicherung unterstützt kein selbstsigniertes Zertifikat für S3-kompatiblen Speicher. Informationen zum Nachverfolgen dieses Problems finden Sie unter Velero-Problem #5123 und Kopia-Problem #1443.
Funktioniert nicht mit dem neuesten vSphere-Plug-In für Velero-Version, wie in vSphere-Plug-In für Velero, Problem #485 beschrieben. Bis dieses Problem behoben ist, führen Sie kein Upgrade des vSphere-Plug-Ins durch, damit es mit Velero v1.1.0 funktioniert.

Whereabouts v0.6.1

Neuheiten

Unterstützt ipRanges für die Konfiguration von Dual-Stack-IP-Zuweisungen. Siehe Example IPv6 Config im Whereabouts-Repository README.