Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten

Neuerungen zum 25. Juni 2024

VMware vSphere 8.0 Update 3 | 25. Juni 2024 

vCenter Server 8.0 Update 3 | 25. Juni 2024 | ISO-Build 24022515

VMware ESXi 8.0 Update 3 | 25. Juni 2024 | ISO-Build 24022510

VMware NSX Advanced Load Balancer avi-22.1.5 | 11. Oktober 2023

HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0

Tanzu Kubernetes Grid 3.0 | 25. Juni 2024

vSphere IaaS Control Plane 8.0 Update 3 enthält folgende neue Funktionen und Verbesserungen:

  • Automatische Supervisor- und TKG-Zertifikatrotation – Diese Version bietet einen neuen Mechanismus für die Zertifikatrotation. Supervisor- und TKG-Clusterzertifikate werden automatisch rotiert, bevor sie ablaufen. Wenn die automatische Rotation fehlschlägt, werden Sie in vCenter benachrichtigt und müssen die Zertifikate manuell erneuern.

  • Unterstützung für Supervisor- und vSphere-Pod und TKG-Cluster auf Stretched vSAN-Cluster – Ab dieser Version können Sie den Supervisor so konfigurieren, dass er auf einem vSAN Stretched Cluster ausgeführt wird. Diese Konfiguration wird nur in einer Greenfield-Umgebung unterstützt. Dies bedeutet, dass Ihr vSAN-Cluster ausgeweitet werden sollte und die Arbeitslastverwaltung und die Inhaltsbibliothek noch nicht konfiguriert wurden. Diese beiden Komponenten müssen mit vSAN Stretched Cluster-Speicherrichtlinien konfiguriert werden. Weitere Informationen finden Sie in der Dokumentation.

  • VM-Klasse für VM-Dienst-VMs ist jetzt Namespace-beschränkt – Wenn Sie in dieser Version kubectl zum Auflisten von VM-Klassen verwenden, können Sie nur die VM-Klassen anzeigen, die auf den spezifischen vSphere-Namespace zugeschnitten sind. Bisher waren VM-Klassen eine clusterbezogene Ressource, und es war schwierig zu ermitteln, welche VM-Klassen einem bestimmten Namespace zugewiesen und verfügbar waren.

  • Supervisor-Sicherung und -Wiederherstellung – Die Sicherung und Wiederherstellung des Supervisors wird jetzt auf vSphere unterstützt. Sie können jetzt Sicherungen für einen Supervisor als Teil einer vCenter-Sicherung konfigurieren und einen Supervisor bei einer Notfallwiederherstellung, einem Upgrade-Fehler, einem Ausfall und bei anderen Wiederherstellungsszenarien aus einer Sicherung wiederherstellen. Weitere Informationen finden Sie unter Sichern und Wiederherstellen der Supervisor-Steuerungsebene.

  • Sichern und Wiederherstellen von VM-Dienst-VM – Die Sicherung und Wiederherstellung von VM-Dienst-VMs wird jetzt auf vSphere unterstützt. Sie können jetzt einen beliebigen VADP-basierten Sicherungsanbieter verwenden, um Ihre VM-Dienst-VMs zu schützen. Bei einem Ausfall oder anderen Szenarien im Zusammenhang mit Datenverlust können Sie die VMs im vSphere-Namespace aus einer Sicherung wiederherstellen.

  • Die VM-Operator-API v1alpha2 ist jetzt verfügbar – Mit der Veröffentlichung von VM Operator v1alpha2 steht die nächste Version der VM-Operator-API zur Verfügung. Diese Version bietet erweiterte Unterstützung für Bootstrap-Anbieter, einschließlich Inline-Unterstützung für Cloud-Init und Windows, verbesserte Gastnetzwerkkonfiguration, erweiterte Statusfunktionen, Unterstützung für benutzerdefinierte Readiness-Gates, neue VirtualMachineWebConsoleRequest-API, verbesserte API-Dokumentation und andere Funktionen. 

  • Nutzen von Fluent Bit für die Protokollweiterleitung auf dem Supervisor – Die Unterstützung der Protokollweiterleitung von Supervisor-Steuerungsebenenprotokollen und -Systemprotokollen an eine externe Protokollüberwachungsplattform ist jetzt verfügbar. Weitere Informationen finden Sie in der Dokumentation.

  • Unterstützung der privaten Registrierung für Supervisor-Dienste – Sie können jetzt Details zu einer privaten Registrierung definieren, mit denen Arbeitslasten, die als Supervisor-Dienst bereitgestellt werden, Images und Pakete aus einer privaten Registrierung abrufen können. Dies ist eine gemeinsame Anforderung für die Unterstützung einer Air-Gap-Umgebung. Weitere Informationen finden Sie in der Dokumentation.

  • Verbesserungen des Supervisor-Upgrade-Workflows – Sie können jetzt Vorabprüfungen für das Supervisor-Upgrade initiieren, wenn Sie ein Upgrade der Supervisor-Kubernetes-Version initiieren. Erst wenn alle Vorabprüfungen erfolgreich sind, wird das tatsächliche Update durchgeführt. Diese Version bietet die Möglichkeit, den Komponenten-Upgrade-Vorgang von dem Punkt aus fortzusetzen, an dem er zuvor fehlgeschlagen ist. Weitere Informationen finden Sie unter Update des Supervisor.

  • Supervisor-Unterstützung für Kubernetes 1.28 – Ab dieser Version wird Kubernetes 1.28 unterstützt und die Unterstützung für Kubernetes 1.25 eingestellt.

Unterstützte Kubernetes-Versionen für Supervisor:

Unterstützt werden in dieser Version die Kubernetes-Versionen 1.28, 1.27 und 1.26. Für Supervisor, die auf Kubernetes Version 1.25 ausgeführt werden, wird automatisch ein Upgrade auf Version 1.26 durchgeführt, um sicherzustellen, dass alle Supervisor auf den unterstützten Versionen von Kubernetes ausgeführt werden.

Tanzu Kubernetes Grid Service for vSphere

  • TKG-Dienst als Supervisor-Dienst – Diese Version entkoppelt die TKG-Dienstkomponenten von vCenter und packt sie als Supervisor-Dienst, den Sie unabhängig von vCenter- und Supervisor-Versionen aktualisieren und verwalten können. Die Versionshinweise des TKG-Diensts finden Sie hier.

  • Unterstützung für die Bereitstellung von TKG-Dienstclustern auf Stretched vSAN Cluster – Diese Version unterstützt die Bereitstellung von TKG-Dienstclustern in vSAN Stretched Cluster-Topologie. Weitere Informationen zum Konfigurieren von HA für TKG-Dienstcluster auf vSAN Stretched Cluster finden Sie in der Dokumentation.

  • Automatische Skalierung von TKG-Dienstclustern – Diese Version unterstützt die Installation des Cluster-Autoscaler-Pakets auf einem TKG-Dienstcluster, um die automatisierte horizontale Skalierung von Worker-Knoten zu ermöglichen. 

  • Sicherung und Wiederherstellung von TKG-Clustern – Diese Version unterstützt die Sicherung und Wiederherstellung der Supervisor-Datenbank, die vSphere Namespace-Objekt und TKG-Cluster-VMs umfasst. Beachten Sie, dass TKG-Clusterarbeitslasten separat gesichert und wiederhergestellt werden müssen.

  • Unterstützung für die Integration von Antrea-NSX und den NSX Management Proxy-Dienst – Diese Version unterstützt die Integration von TKG-Clustern mithilfe der Antrea-CNI mit NSX Manager zur Beobachtbarkeit und Steuerung des Clusternetzwerks.

  • Konfigurierbare MachineHealthCheck – Diese Version unterstützt die Konfiguration von MachineHealthCheck für v1beta1-Cluster.

  • Clusterweite PSA-Konfiguration – Diese Version unterstützt die Konfiguration von PSA auf clusterweiter Basis während der Clustererstellung oder -aktualisierung.

  • Updates für Standardpaketinstallationen – Diese Version enthält Dokumentationsaktualisierungen für die Installation von Standardpaketen auf TKG-Dienstclustern. 

  • Updates der v1beta1-API für die Bereitstellung von TKG-Clustern – Diese Version enthält die folgenden v1beta1-API-Änderungen:

    • podSecurityStandard wurde für clusterweite PSA-Implementierung hinzugefügt

    • controlPlaneCertificateRotation wurde aktualisiert 

  • Unterstützung für die Skalierung von Knotenvolumes der Steuerungsebene für einen TKG-Cluster.

Internationalisierungs-Updates

Ab der nächsten Hauptversion werden wir die Anzahl der unterstützten Lokalisierungssprachen reduzieren. Folgende drei Sprachen werden unterstützt:

  • Japanisch

  • Spanisch

  • Französisch

Folgende Sprachen werden nicht mehr unterstützt:

  • Italienisch, Deutsch, brasilianisches Portugiesisch, traditionelles Chinesisch, Koreanisch, vereinfachtes Chinesisch

Auswirkung:

  • Benutzer, die die veralteten Sprachen verwendet haben, erhalten keine Updates oder keinen Support mehr in diesen Sprachen.

  • Alle Benutzeroberflächen, Hilfedokumentationen und der Kundensupport sind nur in Englisch oder in den drei oben genannten unterstützten Sprachen verfügbar.

Neuerungen zum 26. März 2024

VMware vSphere 8.0 Update 2c | 26. März 2024 

ESXi 8.0 Update 2b | 29. Februar 2024 | ISO-Build 23305546

vCenter Server 8.0 Update 2c | 26. März 2024 | ISO-Build 23504390

VMware NSX Advanced Load Balancer avi-22.1.5 | 11. Oktober 2023

HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 18. MAI 2023

vSphere IaaS Control Plane 8.0 Update 2c enthält folgende neue Funktionen und Verbesserungen:

Neue Funktionen

  • Unterstützung für TKr 1.27 – Diese Version enthält Änderungen, die für die Unterstützung von TKr 1.27 auf vSphere 8.x erforderlich sind, wenn diese in Zukunft veröffentlicht wird. Weitere Informationen finden Sie unter Versionshinweise zu VMware Tanzu Kubernetes.

  • Unterstützung für Upgrade von vCenter 7.x auf vCenter 8.x – Für Benutzer, die TKr 1.27.6 auf vSphere 7.x verwenden, bietet diese Version einen Pfad für das Upgrade auf vCenter 8.x. Bisher war TKr 1.27.6, das für vSphere 7.x veröffentlicht wurde, nicht mit vCenter 8.x kompatibel. Weitere Informationen finden Sie im KB-Artikel 96501.

Behobene Probleme

  • Nach dem Upgrade auf vCenter 8.0 Update 2b befindet sich der von vmon verwaltete Dienst-wcp möglicherweise im Zustand n STOPPED, und das vCenter Patching schlägt möglicherweise fehl.

  • Beim Aufheben der Verknüpfung mit einer Bibliothek oder beim Löschen eines Namespace mit einer gemeinsam genutzten Bibliothek werden zugehörige Elemente aus der Inhaltsbibliothek gelöscht.

Neuerungen zum 29. Februar 2024

VMware vSphere 8.0 Update 2b | 29. Februar 2024 

ESXi 8.0 Update 2b | 29. Februar 2024 | ISO-Build 23305546

vCenter Server 8.0 Update 2b | 29. Februar 2024 | ISO-Build 23319993

VMware NSX Advanced Load Balancer avi-22.1.5 | 11. Oktober 2023

HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 18. MAI 2023

vSphere IaaS Control Plane 8.0 Update 2b enthält folgende neue Funktionen und Verbesserungen:

Neue Funktionen

  • Unterstützung für die Konfiguration von VM-Dienst-VM-Klassen über den vSphere Client – Der VM-Dienst auf dem Supervisor unterstützt die Bereitstellung von VMs mit allen Konfigurationen, die derzeit mit vSphere-VMs unterstützt werden. Um CPU, Arbeitsspeicher, Hardware, Sicherheitsgeräte und Passthrough-Geräte für VM-Klassen zu konfigurieren, können Sie jetzt den Assistenten für VM-Klassen im vSphere Client verwenden. Mit dem vSphere Client lässt sich der Prozess, bei dem die VM-Dienst-VMs, die für die Ausführung von KI-/ML-Arbeitslasten verwendet werden, vereinfachen.

  • Supervisoren unterstützen die Avi-Cloud-Einstellung – Wenn Sie den NSX Advanced Load Balancer verwenden, der auch als Avi Load Balancer bezeichnet wird, können Sie jetzt eine Avi-Cloud für jeden Supervisor konfigurieren. Auf diese Weise können mehrere vCenter Server-Instanzen und Datencenter eine einzelne Avi-Instanz verwenden, sodass keine Avi-Instanz für jeden vCenter Server oder jedes Datencenter eingerichtet werden muss, der/das einen Supervisor bereitstellt.

  • Unterstützung der FQDN-Anmeldung – Für Supervisor- und TKG-Cluster können Sie jetzt die IP in der generierten kubeconfigs durch einen gültigen FQDN ersetzen. Der FQDN und die IP-Adresse müssen dem DNS hinzugefügt werden, um eine ordnungsgemäße Auflösung des Hostnamens sicherzustellen.

  • Supervisoren unterstützen Kubernetes 1.27 – Supervisor unterstützt jetzt Kubernetes 1.27, und die Unterstützung für Kubernetes 1.24 wird eingestellt.

Unterstützte Kubernetes-Versionen

  • Unterstützte Kubernetes-Versionen in dieser Version sind 1.27, 1.26 und 1.25. Supervisoren, die auf Kubernetes 1.24 ausgeführt werden, führen ein automatisches Upgrade auf Version 1.25 durch, um die Kompatibilität sicherzustellen.

Upgrade auf 8.0 Update 2b

Beim Upgrade von allen vSphere 8.x-Versionen vor 8.0 Update 2 auf Version 8.0 Update 2b wird ein paralleles Update aller bereitgestellten TKGS-Cluster initiiert, um die folgenden Änderungen zu propagieren:

  • Version 8.0 Update 2 enthält Änderungen sowohl für vSphere 7- als auch für vSphere 8-TKRs im TKGS-Controller als Teil der ClusterClass.

  • Da TKGS-Cluster ab Version 1.23 mit Version 8.0 Update 2b kompatibel sind, werden alle TKGS-Cluster einem parallelen Upgrade unterzogen.

Behobene Probleme

  • Supervisor-Upgrade-Vorgang bleibt bei 20 % hängen.

Neuerungen am 21. September 2023

VMware vSphere 8.0.2 | 21. September 2023

ESXi 8.0.2 | 21. September 2023 | Build 22380479

vCenter Server 8.0.2 | 21. September 2023 | Build 22385739

VMware NSX Advanced Load Balancer avi-22.1.3 | 31. Januar 2023

HAProxy Community Edition 2.2.2, Data Plane API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 18. MAI 2023

vSphere IaaS Control Plane 8.0 Update 2 enthält folgende neue Funktionen und Verbesserungen:

Supervisor

  • Der VM-Dienst bietet Unterstützung für VMs mit einem Windows-Betriebssystem, GPUs und alle anderen für herkömmliche vSphere-VMs verfügbaren Optionen – Der VM-Dienst unterstützt jetzt die Bereitstellung von VMs mit einer beliebigen derzeit bei vSphere-VMs unterstützten Konfiguration. Dadurch wird die vollständige Parität mit herkömmlichen VMs unter vSphere hergestellt, jedoch für VMs, die im Rahmen von Infrastructure as a Service auf dem Supervisor bereitstellt werden. Dies beinhaltet die Unterstützung für die Bereitstellung von Windows-VMs zusammen mit Linux-VMs sowie die Unterstützung für beliebige Hardware, Sicherheit, Geräte, benutzerdefinierte oder Multi-NICs und Passthrough-Geräte, die unter vSphere unterstützt werden. Sie haben jetzt die Möglichkeit, Arbeitslast-VMs durch Verwendung von GPUs zur Unterstützung von KI/ML-Arbeitslasten bereitzustellen.

  • VM-Imagedienst – DevOps-Teams, Entwickler und andere VM-Verbraucher können VM-Images mithilfe des VM-Imagediensts per Self-Service veröffentlichen und verwalten. Mithilfe des Diensts können Verbraucher Images veröffentlichen, ändern und löschen, indem sie K8s-APIs innerhalb einer auf den Supervisor-Namespace beschränkten Image-Registrierung verwenden. Der VM-Imagedienst wird automatisch in jeder CCS-Region und jedem CCS-Projekt erstellt, und das Befüllen der Images in der Image-Registrierung wird – entweder auf globaler oder Projektebene – nach Person oder Verbrauchsstufe beschränkt. Images können für die Bereitstellung von VMs über den VM-Dienst verwendet werden.

    Beachten Sie, dass mit dieser Funktion ein neues Format für den VM-Image-Namen eingeführt wird. Informationen zum Beheben potenzieller Probleme, die durch die Namensänderung verursacht werden, finden Sie unter Änderungen beim Format des VM-Image-Namens in vSphere 8.0 U2.

  • Importieren und Exportieren der Supervisor-Konfiguration – In früheren Versionen war die Aktivierung des Supervisors ein manueller, schrittweiser Prozess ohne die Möglichkeit zum Speichern von Konfigurationen. In der aktuellen Version können Sie jetzt die Supervisor-Konfiguration in einem für den Menschen lesbaren Format oder innerhalb eines Quellcodeverwaltungssystems exportieren und für Peers freigeben, Konfigurationen in einen neuen Supervisor importieren und eine Standardkonfiguration über mehrere Supervisoren hinweg replizieren. Weitere Informationen zum Exportieren und Importieren der Supervisor-Konfiguration finden Sie in der Dokumentation.

  • Verbesserte GPU-Nutzung durch geringere Fragmentierung – Die Platzierung der Arbeitslast ist jetzt GPU-fähig, und DRS versucht, Arbeitslasten mit ähnlichen Profilanforderungen auf demselben Host zu platzieren. Dadurch wird die Ressourcennutzung verbessert. Dies senkt die Kosten, da weniger GPU-Hardwareressourcen erworben werden müssen, um ein gewünschtes Leistungsniveau zu erreichen.

  • Supervisoren unterstützen Kubernetes 1.26 – In dieser Version wird Unterstützung für Kubernetes 1.26 hinzugefügt und die Unterstützung für Kubernetes 1.23 eingestellt. Unterstützt werden in dieser Version die Kubernetes-Versionen 1.26, 1.25 und 1.24. Supervisoren, die auf Kubernetes Version 1.23 ausgeführt werden, werden automatisch auf Version 1.24 aktualisiert, um sicherzustellen, dass alle Supervisoren auf den unterstützten Versionen von Kubernetes ausgeführt werden.

  • Unterstützung von NSX Advanced Load Balancer für einen Supervisor, der mit NSX-Netzwerk konfiguriert ist – Sie können jetzt einen Supervisor mit NSX Advanced Load Balancer (Avi Networks) für L4-Lastausgleich aktivieren, außerdem Lastausgleich für die Steuerungsebenenknoten von Supervisor- und Tanzu Kubernetes Grid-Clustern mit NSX-Netzwerk. Auf der Dokumentationsseite finden Sie Anleitungen zum Konfigurieren des NSX Advanced Load Balancer mit NSX.

  • Telegraf-Unterstützung für Metrik- und Ereignis-Streaming – Sie können Telegraf jetzt über Kubernetes-APIs konfigurieren, um Supervisor-Metriken an alle Metrikdienste zu übertragen, die mit der eingebetteten Telegraf-Version kompatibel sind. Informationen zum Konfigurieren von Telegraf finden Sie in der Dokumentation.

Tanzu Kubernetes Grid auf Supervisor

  • STIG-Konformität für TKRs unter vSphere 8.0 – Mit vSphere U2 sind alle Tanzu Kubernetes Grid-Cluster über 1.23.x mit dem Technischen Sicherheitsimplementierungshandbuch (Security Technical Implementation Guide, STIG) konform und enthalten die Dokumentation für Ausnahmen, die Sie hier finden. Diese Verbesserungen stellen einen wichtigen Schritt zur Vereinfachung des Konformitätsprozesses dar und erleichtern Ihnen die Erfüllung von Konformitätsanforderungen, sodass Sie Tanzu Kubernetes Grid auf dem bundesweiten Markt der USA und in anderen regulierten Branchen schnell und sicher einsetzen können.

  • Rollout der Steuerungsebene für ablaufende Zertifikate aktivieren – Die v1beta1-API für die Bereitstellung von TKG-Clustern auf Grundlage einer ClusterClass wird aktualisiert, damit Cluster die VM-Zertifikate des Steuerungsebenenknotens erneuern können, bevor sie ablaufen. Diese Konfiguration kann als Variable zur Clusterspezifikation hinzugefügt werden. Weitere Informationen

    finden Sie in der Dokumentation Cluster-API „v1beta1“.

  • Unterstützung von CSI-Snapshots für TKRs – TKG-Cluster, die mit Tanzu Kubernetes 1.26.5 und höher bereitgestellt werden, unterstützen CSI-Volume-Snapshots und helfen Ihnen, die Anforderungen an die Datensicherheit zu erfüllen. Volume-Snapshots bieten Ihnen eine standardisierte Möglichkeit, den Inhalt eines Volumes zu einem bestimmten Zeitpunkt zu kopieren, ohne einen völlig neuen Datenträger zu erstellen. 

  • Installieren und Verwalten von Tanzu-Paketen – Ein neues konsolidiertes Repository und eine Veröffentlichung zum Installieren und Verwalten von Tanzu-Paketen in TKG-Clustern. Informationen zu allen Paketanforderungen finden Sie in der Publikation „Installieren und Verwenden von VMware Tanzu-Paketen“.

  • Verbesserungen bei der benutzerdefinierten ClusterClass – Der Workflow zur Implementierung benutzerdefinierter ClusterClass-Cluster wurde für vSphere 8 U2 vereinfacht.

  • Parallele Updates für TKG-Cluster – Beim Upgrade auf vSphere 8 U2 können Sie in folgenden Szenarien mit parallelen Updates für bereitgestellte TKG-Cluster rechnen:

    • Beim Upgrade einer zuvor veröffentlichten vSphere 8-Version auf vSphere 8 U2. Grund:

      • vSphere 8 U2 enthält STIG-Änderungen auf Kubernetes-Ebene für TKRs als Teil der Clusterclass

      • Für TKG-Cluster ab Version 1.23 wird ein paralleles Update durchgeführt, um Kompatibilität mit v8.0 U2 herzustellen.

    • Beim Upgrade einer beliebigen vSphere 7-Version auf vSphere 8 U2:

      • Zugrunde liegende CAPI-Anbieter müssen von CAPW zu CAPV verschoben werden

      • Vorhandene Cluster müssen von klassenlosen CAPI-Clustern zu klassenbasierten CAPI-Clustern migriert werden

Behobene Probleme

  • Überwachungsprotokolldateien unter „/var/log/audit/“ auf den Supervisor-Steuerungsebenen-VMs werden möglicherweise sehr groß, und die Root-Festplatte füllt sich. In journald-Protokollen, sollten Fehler des Typs „Kein Speicherplatz frei auf Gerät“ angezeigt werden, die diesen Zustand widerspiegeln. Dies kann dazu führen, dass verschiedene Aspekte der Funktionalität der Supervisor-Steuerungsebene (wie Kubernetes-APIs) fehlschlagen.

Neue Funktionen zum 27. Juli 2023

VMware vSphere 8.0.1c | 27. JULI 2023

ESXi 8.0.1c | 27. JULI 2023 | Build 22088125

vCenter Server 8.0.1c | 27. Juli 2023 | Build 22088981

VMware NSX Advanced Load Balancer avi-22.1.3 | 31. Januar 2023

HAProxy Community Edition 2.2.2, Data Plane API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 18. MAI 2023

Neue Funktionen

  • Supervisor unterstützen Kubernetes 1.25 – Ab dieser Version wird Kubernetes 1.25 unterstützt und die Unterstützung für Kubernetes 1.22 eingestellt.

  • Tanzu Kubernetes Grid 2.2.0 auf Supervisor – Verwalten Sie Tanzu Kubernetes Grid 2.2.0-Cluster auf Supervisor.

Unterstützte Kubernetes-Versionen

  • Unterstützt werden in dieser Version die Kubernetes-Versionen 1.25, 1.24 und 1.23. Supervisoren, die auf Kubernetes Version 1.22 ausgeführt werden, werden automatisch auf Version 1.23 aktualisiert, um sicherzustellen, dass alle Supervisoren auf den unterstützten Versionen von Kubernetes ausgeführt werden.

Support

  • vRegistry-Erstellung wird eingestellt – Die Erstellung der eingebetteten Harbor-Instanz vRegistry wird nicht mehr unterstützt. Vorhandene vRegistry-Instanzen funktionieren weiterhin, aber die Erstellung neuer vRegistry-Instanzen wird eingestellt. Die APIs zum Erstellen von vRegistry-Instanzen wurden als veraltet markiert. Die Möglichkeit der Bereitstellung von neuen vRegistry-Instanzen wird in einer kommenden Version entfallen. Stattdessen wird empfohlen, Harbor als Supervisor-Dienst zu verwenden, um Container-Images und Repositorys bei verbesserter Leistung und Funktionalität zu verwalten. Informationen zum Migrieren des vorhandenen vRegistry zu Harbor als Supervisor-Dienst finden Sie unter „Migrieren von Images aus der eingebetteten Registrierung zu Harbor“.

Behobene Probleme

  • Eine neue Warnmeldung wird im vSphere Client angezeigt, um auf den bevorstehenden Ablauf des Zertifikats auf den Supervisor- oder TKG-Clustern hinzuweisen. Die Warnung enthält detaillierte Informationen, darunter den Namen des Supervisors und das Ablaufdatum des Zertifikats. Darüber hinaus enthält sie einen Link zu KB 90627, in dem das Verfahren zum Ersetzen betroffener Zertifikate schrittweise erläutert wird.

  • Der Befehl kubectl get clustervirtualmachineimages gibt einen Fehler oder die Meldung No resources found zurück. In früheren Versionen ist bei Verwendung des Befehls kubectl get clustervirtualmachineimages ein Fehler aufgetreten. Nach dem Upgrade auf 8.0 Update 1c gibt der Befehl nun jedoch die folgende Meldung zurück: No resources found. Verwenden Sie zum Abrufen von Informationen zu VM-Images stattdessen den folgenden Befehl: kubectl get virtualmachineimages

  • Die Antrea-NSX-geroutete CNI funktioniert nicht mit v1alpha3 Tanzu Kubernetes-Clustern in Versionen von vSphere IaaS Control Plane 8.x.

  • Zeitüberschreitung bei Knotenleerung wird für v1beta1-Cluster nicht korrekt propagiert.

Neuheiten 18. April 2023

VMware vSphere 8.0.1 | 18. April 2023

ESXi 8.0.1 | 18. April 2023 | Build 21495797

vCenter Server 8.0.1 | 18. April 2023 | Build 21560480

VMware NSX Advanced Load Balancer avi-22.1.3 | 31. Januar 2023

HAProxy Community Edition 2.2.2, Data Plane API 2.1.0

Tanzu Kubernetes Grid 2.0 | 11. OKTOBER 2022

Neue Funktionen

Supervisor

  • Supervisor-Dienste sind jetzt auf VDS-basierten Supervisoren verfügbar – Bisher waren Supervisor-Dienste ausschließlich auf NSX-basierten Supervisoren verfügbar. Mit der aktuellen Version können Sie Harbor-, Contour-, S3-Objektspeicher- und Velero-Supervisor-Dienste auf VDS-basierten Supervisoren bereitstellen. Hinweis: Supervisor-Dienstfunktionen auf VDS-basierten Supervisoren erfordern ein ESXi-Update auf 8.0 U1.

  • VM-Dienstunterstützung für alle Linux-Images – Sie können CloudInit jetzt verwenden, um jedes Linux-Image im OVF-Format anzupassen, das der Image-Spezifikation des VM-Diensts entspricht, und OVF-Vorlagen über vAppConfig zu verwenden, um die Bereitstellung von Legacy-Linux-Images zu ermöglichen.

  • Webkonsolenunterstützung für VM-Dienst-VMs – Nach der Bereitstellung einer VM-Dienst-VM haben Sie als DevOps-Ingenieur jetzt die Möglichkeit, eine Webkonsolensitzung für diese VM zu starten, indem Sie die kubectl-CLI verwenden, um Fehlerbehebung und Debugging innerhalb des Gastbetriebssystems zu ermöglichen, ohne dass der vSphere Administrator Zugriff auf die Gast-VM erhalten muss.

  • Supervisor-Konformität – Technische Sicherheitsimplementierungshandbücher (Security Technical Implementation Guides, STIG) für die Supervisor-Versionen von vSphere IaaS Control Plane 8. Weitere Informationen finden Sie unter Tanzu STIG-Härtung.

Tanzu Kubernetes Grid 2.0 auf Supervisor

  • Benutzerdefinierte Clusterklasse – Bringen Sie Ihre eigene Clusterklasse für TKG-Cluster auf Supervisor mit. Weitere Informationen finden Sie unter https://kb.vmware.com/s/article/91826.

  • Benutzerdefiniertes Image für TKG-Knoten – Erstellen Sie Ihre eigenen benutzerdefinierten Knoten-Images mithilfe von vSphere TKG Image Builder (Ubuntu und Photon).

    Hinweis: Um eine bestimmte TKR mit der v1alpha1-API zu verwenden, verwenden Sie fullVersion.

  • Neue TKR-Images: Weitere Informationen finden Sie in den Versionshinweisen zu Tanzu Kubernetes-Versionen.

KRITISCHE ANFORDERUNG für Kunden der vSphere IaaS-Steuerungsebene 8.0.0 GA

Hinweis: Diese Anforderung gilt nicht für Inhaltsbibliotheken, die Sie für über den VM-Dienst bereitgestellte VMs verwenden. Sie gilt nur für die TKR-Inhaltsbibliothek.

Wenn Sie die vSphere IaaS Control Plane 8.0.0 GA bereitgestellt haben, müssen Sie vor dem Upgrade auf vSphere IaaS Control Plane 8 U1 eine temporäre TKR-Inhaltsbibliothek erstellen, um ein bekanntes Problem zu vermeiden, das dazu führt, dass TKG-Controller-Pods in CrashLoopBackoff wechseln, wenn TKG 2.0 TKrs in die vorhandene Inhaltsbibliothek übertragen werden. Um dieses Problem zu vermeiden, führen Sie die folgenden Schritte durch:

  1. Erstellen Sie eine neue abonnierte Inhaltsbibliothek mit einer temporären Abonnement-URL, die auf https://wp-content.vmware.com/v2/8.0.0/lib.json verweist.

  2. Synchronisieren Sie alle Elemente in der temporären Inhaltsbibliothek.

  3. Verknüpfen Sie die temporäre Inhaltsbibliothek mit jedem vSphere Namespace, in dem Sie einen TKG 2-Cluster bereitgestellt haben.

  4. Führen Sie den Befehl kubectl get tkr aus und überprüfen Sie, ob alle TKrs erstellt wurden.

  5. Zu diesem Zeitpunkt sollte sich der TKG-Controller in einem ausgeführten Zustand befinden. Sie können den Zustand überprüfen, indem Sie die Pods im Supervisor-Namespace auflisten.

  6. Wenn sich der TKG-Controller im Zustand „CrashLoopBackOff (CLBO)“ befindet, starten Sie die TKG-Controller-Bereitstellung mit dem folgenden Befehl neu:

    kubectl rollout restart deployment -n vmware-system-tkg vmware-system-tkg-controller-manager

  7. Führen Sie ein Upgrade auf vSphere IaaS Control Plane 8 Update 1 durch.

  8. Aktualisieren Sie jeden vSphere-Namespace, um die ursprüngliche abonnierte Inhaltsbibliothek auf https://wp-content.vmware.com/v2/latest/lib.json zu verwenden.

Behobene Probleme

  • Tanzu Kubernetes Grid 2.0 Cluster, die mit v1beta1-API bereitgestellt werden, müssen auf der Standard-ClusterClass basieren

    Wenn Sie einen Tanzu Kubernetes Grid 2.0-Cluster auf Supervisor mithilfe der v1beta1-API erstellen, muss der Cluster auf der Standard-ClusterClass tanzukubernetescluster basieren. Das System gleicht keinen Cluster ab, der auf einer anderen ClusterClass basiert.

Neuigkeiten am 30. März 2023

ESXi 8.0.0c | 30. März 2023 | Build 21493926

vCenter Server 8.0.0c | 30. März 2023 | Build 21457384

VMware NSX Advanced Load Balancer avi-22.1.3 | 31. Januar 2023

HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0

Tanzu Kubernetes Grid 2.0 | 11. OKTOBER 2022

Behobene Probleme:

  • Problem mit unsicherer Harbor-Standardkonfiguration

    In dieser Version wird das Problem mit der unsicheren Standardkonfiguration von Harbor, das vorlag, wenn Sie die eingebettete Harbor-Registrierung auf Supervisor 7.0 oder 8.0 aktivierten, behoben.

    In dieser vCenter-Version 8.0.0c behoben. Weitere Details zu diesem Problem und dazu, wie Sie es beheben, indem Sie entweder die vorliegende Version installieren oder eine vorübergehende Problemumgehung anwenden, finden Sie im VMware Knowledgebase-Artikel 91452.

  • Nach einem Upgrade auf vCenter Server 8.0b schlagen Anmeldeversuche bei einem Supervisor und TKG-Clustern fehl

    Komponenten, die in vCenter Server 8.0b ausgeführt werden, sind nicht abwärtskompatibel mit Supervisoren, die mit vCenter Server in früheren Versionen bereitgestellt wurden.

    Problemumgehung: Führen Sie ein Upgrade von vCenter Server auf eine neuere Version durch oder aktualisieren Sie alle bereitgestellten Supervisoren.

Neue Funktionen zum 14. Februar 2023

ESXi 8.0.0b | 14. Februar 2023 | Build 21203435

vCenter Server 8.0.0b | 14. Februar 2023 | Build 21216066

VMware NSX Advanced Load Balancer avi-22.1.1-9052 | 15. Juli 2022

HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0

Tanzu Kubernetes Grid 2.0 | 11. OKTOBER 2022

Neue Funktionen:

  • Unterstützung für CA-Aussteller im Cert-Manager-Cluster wurde hinzugefügt – Ermöglicht Administratoren, einen clusterbezogenen CA-Aussteller in einem Supervisor als Supervisor-Dienst zu definieren und bereitzustellen. Durch die Bereitstellung eines clusterbezogenen CA-Ausstellers können Verbraucher des Supervisor-Namespace Zertifikate anfordern und verwalten, die vom CA-Aussteller signiert wurden. 

Zusätzlich zu dieser neuen Funktion enthält die Version Fehlerbehebungen.

Behobene Probleme:

  • Root-Festplatte der Supervisor-Steuerungsebenen-VMs füllt sich

    Überwachungsprotokolldateien unter „/var/log/audit/“ auf den Supervisor-Steuerungsebenen-VMs werden möglicherweise sehr groß und die Root-Festplatte füllt sich. In journald-Protokollen, sollten Fehler des Typs „Kein Speicherplatz frei auf Gerät“ angezeigt werden, die diesen Zustand widerspiegeln. Dies kann dazu führen, dass verschiedene Aspekte der Funktionalität der Supervisor-Steuerungsebene (wie Kubernetes-APIs) fehlschlagen.

    In dieser Version, vSphere 8.0.0b, behoben

Neuigkeiten am 15. Dezember 2022

ESXi 8.0 | 11. Oktober 2022 | Build 20513097

vCenter Server 8.0.0a | 15. Dezember 2022 | Build 20920323

VMware NSX Advanced Load Balancer avi-22.1.1-9052 | 15. Juli 2022

HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0

Tanzu Kubernetes Grid 2.0 | 11. OKTOBER 2022

Neue Funktionen

  • Harbor wurde als Supervisor-Dienst hinzugefügt – Stellt eine Harbor-Instanz mit vollem Funktionsumfang (OCI-Image-Registrierung) bereit, die auf dem Supervisor ausgeführt wird. Die Harbor-Instanz bietet Harbor-Administratoren die Möglichkeit, Projekte und Benutzer zu erstellen und zu verwalten sowie Image-Scans einzurichten.

  • Veraltete vRegistry-Instanz – Die eingebettete Harbor-Instanz mit der Bezeichnung „vRegistry“ wird in einer zukünftigen Version entfernt. An deren Stelle können Sie Harbor als Supervisor-Dienst verwenden. Weitere Details zur Migration finden Sie unter Migrieren von Images aus der eingebetteten Registrierung zu Harbor.

  • Supervisors unterstützen Kubernetes 1.24 – In dieser Version wird Unterstützung für Kubernetes 1.24 hinzugefügt und Unterstützung für Kubernetes 1.21 eingestellt. Zu den unterstützten Versionen von Kubernetes in dieser Version gehören 1.24, 1.23 und 1.22. Supervisor-Cluster, die unter Kubernetes in der Version 1.21 ausgeführt werden, werden automatisch auf Version 1.22 aktualisiert, um sicherzustellen, dass alle Supervisor-Cluster auf unterstützten Versionen ausgeführt werden.

  • vSphere-Zonen-APIs – Mithilfe einer vSphere-Zone können Sie vSphere-Clustern Verfügbarkeitsbereiche zuweisen, um hochverfügbare Supervisor- und Tanzu Kubernetes-Cluster zu erstellen. In vSphere 8.0 stand die Funktion zum Erstellen und Verwalten der vSphere-Zonen über den vSphere Client zur Verfügung. Ab vSphere 8.0.0a können Benutzer vSphere-Zonen mithilfe der DCLI oder des vSphere Client-API-Explorers erstellen und verwalten. Vollständige Unterstützung für SDK-Bindungen (z. B. Java, Python usw.) wird in einer zukünftigen Version zur Verfügung gestellt.

Überlegungen zu Upgrades:

  • In den folgenden Supervisor-Upgrade-Szenarien wird ein paralleles Update von Tanzu Kubernetes-Clustern durchgeführt:

    • Beim Upgrade von 8.0 auf 8.0.0a und anschließendem Upgrade eines Supervisors von einer beliebigen Kubernetes-Version auf Supervisor Kubernetes 1.24 und bei Erfüllung einer dieser Bedingungen.

      • Bei Verwendung von Proxy-Einstellungen mit einer nicht leeren NoProxy-Liste in einem Tanzu Kubernetes-Cluster

      • Bei Aktivierung von vRegistry auf dem Supervisor. Dieses Setup ist nur auf NSX-basierten Supervisoren verfügbar.

    • Beim Upgrade von vSphere 7.0 auf vSphere 8.0.0a.

Behobene Probleme:

  • Tanzu 7-Lizenzschlüssel werden in vSphere 8 anstelle von Tanzu 8-Lizenzschlüsseln unterstützt

    vCenter 8.0 unterstützt die Tanzu 7-Lizenzschlüssel anstelle von Tanzu 8-Lizenzschlüsseln. Dieses Problem hat keine Auswirkungen auf die vollständige Nutzung der Tanzu-Funktionen in vCenter 8.0. Beschäftigen Sie sich mit den Informationen im VMware-Knowledgebase-Artikel 89839, bevor Sie Tanzu-Lizenzen in Ihrer vCenter 8.0-Bereitstellung ändern.

  • LoadBalancers und Gast-Cluster werden nicht erstellt, wenn zwei SE-Gruppen unter NSX-ALB vorhanden sind.

    Wenn eine zweite SE-Gruppe zu NSX-ALB hinzugefügt wird, ohne dass dieser SEs oder virtuelle Dienste zugewiesen werden, schlägt das Erstellen neuer Supervisor- oder Gast-Cluster fehl, und die vorhandenen Supervisor-Cluster können nicht aktualisiert werden. Das Erstellen des virtuellen Diensts auf dem NSX-ALB-Controller schlägt mit dem folgenden Fehler fehl:

    get() returned more than one ServiceEngineGroup – it returned 2

    Infolgedessen können neue Lastausgleichsdienste nicht verwendet werden, und Sie können keine neuen Arbeitslastcluster erstellen. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 90386.

Neuigkeiten am 11. Oktober 2022

VMware vSphere 8.0 | 11. Oktober 2022

ESXi 8.0 | 11. Oktober 2022 | Build 20513097

vCenter 8.0 | 11. Oktober 2022 | Build 20519528

VMware NSX Advanced Load Balancer 21.1.4 | 07. April 2022

HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0

Tanzu Kubernetes Grid 2.0 | 11. OKTOBER 2022

vSphere IaaS Control Plane 8.0 enthält folgende neue Funktionen und Verbesserungen:

  • Überwachung der Konfiguration des Arbeitslastmanagements – Sie können jetzt den Status der Aktivierung, Deaktivierung und des Upgrades des Supervisors genauer verfolgen. Nachdem Sie eine Aktivierung, Deaktivierung oder ein Upgrade des Supervisors initiiert haben, versucht der Supervisor, den gewünschten Zustand zu erreichen, indem er verschiedene Bedingungen erreicht, die verschiedenen Komponenten des Supervisors zugeordnet sind, z. B. VMs der Steuerungsebene. Sie können den Status jeder Bedingung verfolgen, die zugehörigen Warnungen ansehen, den Status erneut versuchen sowie die erreichten Bedingungen und deren Zeitstempel anzeigen.

  • vSphere-Zonen – Eine vSphere-Zone ist ein neues Konstrukt, mit dem Sie vSphere-Clustern Verfügbarkeitszonen zuweisen können. Durch die Bereitstellung eines Supervisors über vSphere-Zonen hinweg können Sie Tanzu Kubernetes Grid-Cluster in bestimmten Verfügbarkeitszonen und Fehlerdomänen bereitstellen. Dadurch können sich Arbeitslasten über mehrere Cluster erstrecken. Dies wiederum erhöht die Stabilität gegenüber Hardware- und Softwarefehlern.

  • Multi-Cluster Supervisor – Mithilfe von vSphere-Zonen können Sie einen Supervisor über mehrere vSphere-Cluster hinweg bereitstellen, um Hochverfügbarkeit und Fehlerdomänen für Tanzu Kubernetes Grid-Cluster bereitzustellen. Sie können einen vSphere-Cluster zu einer separaten vSphere-Zone hinzufügen und einen Supervisor aktivieren, der sich über mehrere vSphere-Zonen erstreckt. Dies bietet Failover und Ausfallsicherheit für lokalisierte Hardware- und Softwarefehler. Wenn eine Zone oder ein vSphere-Cluster offline geschaltet wird, erkennt der Supervisor den Fehler und startet Arbeitslasten in einer anderen vSphere-Zone neu. Sie können vSphere-Zonen in Umgebungen verwenden, die sich über weite Entfernungen erstrecken, solange die Maximalwerte für die Latenz nicht überschritten werden. Weitere Informationen zu den Latenzanforderungen finden Sie unter Voraussetzungen für die zonale Supervisor-Bereitstellung.

  • Supervisor unterstützen Kubernetes 1.23 – In dieser Version wird Kubernetes 1.23 neu unterstützt und die Unterstützung für Kubernetes 1.20 eingestellt. Die unterstützten Versionen von Kubernetes in dieser Version sind 1.23, 1.22 und 1.21. Supervisoren, die auf Kubernetes in der Version 1.20 ausgeführt werden, werden automatisch auf Version 1.21 aktualisiert, um sicherzustellen, dass alle Supervisoren auf den unterstützten Versionen von Kubernetes ausgeführt werden.

  • Mit SecurityPolicy-CRDs einheitliche Netzwerkrichtlinien bereitstellen – Die benutzerdefinierte SecurityPolicy-Ressourcendefinition bietet die Möglichkeit, Netzwerksicherheitskontrollen für VMs und vSphere Pods in einem Supervisor-Namespace zu konfigurieren.

  • Tanzu Kubernetes Grid 2.0 auf Supervisor – Von Tanzu Kubernetes Grid gibt es jetzt die Version 2.0. Tanzu Kubernetes Grid 2.0 ist der Höhepunkt einer enormen Innovation in der Tanzu- und Kubernetes-Community und bietet die Grundlage für einen gemeinsamen Satz von Schnittstellen über Private und Public Clouds hinweg mit Tanzu Kubernetes Grid. Neu in dieser Version sind folgende zwei Hauptfunktionen:

    • ClusterClass – Tanzu Kubernetes Grid 2.0 unterstützt jetzt ClusterClass. ClusterClass bietet eine Upstream-ausgerichtete Schnittstelle, die den Tanzu Kubernetes-Cluster ersetzt, wodurch Anpassungsfunktionen auf unsere Tanzu Kubernetes Grid-Plattform übertragen werden. Mit ClusterClass können Administratoren Vorlagen definieren, die mit ihren Unternehmensumgebungsanforderungen funktionieren, während die Textvorlage reduziert und die delegierte Anpassung aktiviert wird.

    • Carvel – Carvel bietet eine Reihe zuverlässiger, zusammenstellbarer Single-Purpose-Tools, die beim Erstellen, Konfigurieren und Bereitstellen von Anwendungen in Kubernetes helfen. Insbesondere bieten kapp und kapp-controller Paketverwaltung, Kompatibilität und Lebenszyklus über einen Satz deklarativer, Upstream-ausgerichteter Tools. In Kombination mit ytt für die Vorlagenerstellung führt dies zu einer flexiblen, aber verwaltbaren Paketverwaltungsfunktion.

  • Neue Dokumentationsstruktur und Zielseite in vSphere 8 – Die vSphere IaaS Control Plane-Dokumentation verfügt nun über eine verbesserte Struktur, die die Workflows mit dem Produkt besser widerspiegelt und es Ihnen ermöglicht, die Inhalte gezielter zu nutzen. Sie können auch auf der neuen Zielseite für die Dokumentation von vSphere IaaS Control Plane auf alle verfügbaren technischen Dokumentationen für vSphere IaaS Control Plane zugreifen.


Installation und Upgrades für diese Version

Weitere Anweisungen zum Installieren und Konfigurieren von vSphere IaaS Control Plane finden Sie in der Dokumentation Installing and Configuring vSphere IaaS Control Plane. Informationen zum Aktualisieren von vSphere IaaS Control Plane finden Sie in der Dokumentation Updating vSphere IaaS Control Plane.

Beachten Sie beim Vornehmen Ihrer Upgrades Folgendes:

  • Stellen Sie vor dem Update auf vCenter Server 8.0 sicher, dass die Kubernetes-Version aller Supervisors mindestens 1.21 und vorzugsweise die neueste unterstützte Version ist. Die Tanzu Kubernetes-Version der Tanzu Kubernetes Grid-Cluster muss 1.21 und vorzugsweise die neueste unterstützte Version sein.

  • Upgrades von veralteten TKGS TKr auf TKG 2 TKr sind ab vSphere IaaS Control Plane 8.0 MP1 zulässig. Die Matrix der unterstützten Versionen finden Sie in den Versionshinweisen zu Tanzu Kubernetes. Upgrade-Informationen finden Sie in der Dokumentation Using TKG on Supervisor with vSphere IaaS Control Plane.

Bekannte Probleme

Bekannte Probleme bei Supervisor

  • In vSphere 8.0 Update 3 sind die Optionen für die Netzwerküberschreibung auf der Seite für die vSphere-Namespace-Erstellung nicht mehr vorhanden

    Vor Version 8.0 Update 3 konnte ein vSphere-Administrator eine benutzerdefinierte Netzwerkkonfiguration anstelle der Standardnetzwerkkonfiguration bereitstellen, die beim Erstellen eines vSphere-Namespace verwendet wird. In Version 8.0 Update 3 ist die Benutzeroberflächenoption zum Überschreiben der Netzwerkkonfiguration nicht verfügbar.

    Problemumgehung: Sie können DCLI verwenden, um den vSphere Namespace mit benutzerdefinierter Netzwerkkonfiguration zu erstellen.

  • Gelegentlich können ESXi-Hosts einem Supervisor-Cluster nicht beitreten, da das vds-vsip-Modul nicht geladen werden kann

    Wenn die ESXi-Hosts dem Supervisor-Cluster nicht beitreten können, sehen Sie den folgenden Fehler in der ESXi-Host-Protokolldatei /var/run/log/spherelet.log:

    cannot load module vds-vsip: cmd '/bin/vmkload_mod /usr/lib/vmware/vmkmod/vds-vsip' failed with status 1: stderr: '', stdout:'vmkmod: VMKModLoad: VMKernel_LoadKernelModule(vds-vsip): Failure\nCannot load module /usr/lib/vmware/vmkmod/vds-vsip: Failure\n'

    Dieses Problem kann während eines Supervisor-Cluster-Upgrades, eines Zertifikatsupgrades oder einer anderen Supervisor-Konfigurationsänderung auftreten, die Spherelet neu startet.

    Problemumgehung: Starten Sie die ESXi-Hosts neu, die das vds-vsip-Modul nicht laden können.

  • Versuche, ein Upgrade Ihrer vSphere IaaS-Steuerungsebenenumgebung von 7.0 Update 3o auf 8.0 Update 3 mit einem Supervisor mit sehr kleinen Steuerungsebenen-VMs durchzuführen, schlagen mit einem Fehler fehl

    Nach dem Upgrade vCenter von 7.0 Update 3o auf 8.0 Update 3 kann der mit sehr kleinen Steuerungsebenen-VMs konfigurierte Supervisor kein Upgrade von Kubernetes v1.26.8 auf v1.27.5 durchführen.

    Sie erhalten folgende Fehler: Waiting for deployment \"snapshot-validation-deployment\" rollout to finish: 2 out of 3 new replicas have been updated...'kubectl get pods' in namespaces starting with the name 'vmware-system-' show pods in OutOfCpu state.

    Problemumgehung: Skalieren Sie vor dem Upgrade die Größe der Steuerungsebenen-VMs von Sehr klein auf Klein oder höher. Siehe Ändern der Größe der Steuerungsebene eines Supervisors.

  • Nach dem Upgrade von vCenter und Ihrer vSphere IaaS-Steuerungsebenenumgebung auf vSphere 8.0 U3 schlagen Versuche, vSphere Pods zu erstellen, fehl, wenn der Supervisor Kubernetes-Version 1.26 verwendet

    Nach dem Upgrade Ihrer Umgebung auf vSphere 8.0 U3 und dem Upgrade Ihres Supervisors auf Kubernetes Version 1.26 schlagen die Erstellungsvorgänge für die vSphere Pods fehl, während das System versucht, das Image abzurufen. Sie können den Fehler failed to configure device eth0 with dhcp: getDHCPNetConf failed for interface sehen, obwohl der Cluster mit statischem Netzwerk aktiviert ist.

    Problemumgehung: Führen Sie ein Upgrade der vSphere IaaS-Steuerungsebene und des Supervisors auf Kubernetes Version 1.27 oder höher durch.

  • Wenn Sie versuchen, gleichzeitig einen Volume-Snapshot zu löschen und einen PVC-Wiederherstellungsvorgang durchzuführen, werden die Vorgänge aufgrund interner Abhängigkeiten gelegentlich nicht abgeschlossen

    Die Probleme können unter den folgenden Umständen auftreten. Sie starten einen Wiederherstellungsvorgang für einen Volume-Snapshot. Der Wiederherstellungsvorgang dauert länger oder wird aus verschiedenen internen Gründen erneut versucht. In der Zwischenzeit lösen Sie das Löschen des Quell-Snapshots aus. Dies führt dazu, dass beide Vorgänge kollidieren und unvollständig bleiben. Das Löschen des Snapshots schlägt aufgrund eines laufenden Wiederherstellungsvorgangs für diesen Snapshot weiterhin fehl, während der Wiederherstellungsvorgang fehlschlägt, weil das Löschen des Snapshots ausgelöst wurde.

    Problemumgehung: Um dieses Problem zu beheben, müssen Sie die wiederhergestellte PVC löschen, um den Wiederherstellungsvorgang zu beenden und das Löschen des Snapshots fortzusetzen. In diesem Fall gehen die Snapshot-Daten verloren und können nicht wiederhergestellt werden, da der Snapshot gelöscht wird, nachdem Sie die wiederhergestellte PVC gelöscht haben.

  • VM-Dienst-VMs können keine PVCs verwenden, bei denen der Parameter volumeBindingMode in der Speicherklasse auf WaitForFirstConsumer festgelegt ist

    Wenn Sie diese Art von PVCs für VM-Dienst-VMs verwenden, kommt es zu unvorhersehbarem Verhalten und zu Fehlern. Beispielsweise wird ein Fehler wie Waiting for first consumer to be created before binding angezeigt.

    Problemumgehung: VM-Dienst-VMs unterstützen PVCs mit sofortigem volumeBidingMode in der Speicherklasse, unterstützen aber nicht WaitForFirstConsumer.

  • Ein neues Lizenzmodell ändert das Verhalten von NSX Container Plugin (NCP) in der Umgebung der VMware vSphere IaaS-Steuerungsebene

    In Version 8.0 Update 3 wird die NSX Distributed Firewall-Lizenz (DFW) als separate Add-On-Lizenz angeboten. Ohne diese Lizenz passt NCP in der Umgebung der VMware vSphere IaaS-Steuerungsebene DFW-Regeln auf NSX an, was zu unvorhersehbarem Verhalten führt.

    Ohne die DFW-Lizenz funktionieren beispielsweise neue Sicherheits- und Netzwerkrichtlinien, die für die VMware vSphere IaaS-Steuerungsebene erstellt wurden, nicht, da NCP keine Regeln für NSX Manager hinzufügen kann. Darüber hinaus können Ressourcen wie Pods in einem neu erstellten Namespace von einem anderen Namespace aus erreichbar sein. Im Gegensatz sollte mit der DFW-Lizenz ein neu erstellter Namespace standardmäßig nicht von einem anderen Namespace aus zugänglich sein.

    Problemumgehung: Die NSX Distributed Firewall-Lizenz (DFW) wird als separate Add-On-Lizenz auf NSX Manager angeboten. Um Probleme zu vermeiden, fügen Sie die Lizenz zu NSX Manager hinzu.

  • Velero vSphere Operator wird erfolgreich installiert, aber Versuche, eine Instanz von Velero zu instanziieren, schlagen möglicherweise fehl

    Velero vSphere Operator stellt seine Operator-Pods auf den Steuerungsebenen-VMs bereit, während Instanzen von Velero als vSphere Pods bereitgestellt werden.

    Das Bereitstellungsproblem kann auftreten, wenn für vCenter ein Upgrade auf 8.x durchgeführt wird und der Supervisor das VDS-Netzwerk verwendet. Für die ESXi-Hosts für diesen Supervisor wurde jedoch kein Upgrade durchgeführt, und sie verwenden eine asynchrone Version vor 8.x. In diesem Szenario können die ESXi-Hosts keine vSphere Pods bereitstellen. Dies führt dazu, dass Velero vSphere Operator erfolgreich installiert wird, eine Instanz von Velero aber nicht instanziiert werden kann, wenn der Administrator versucht, sie zu verwenden.

    Problemumgehung: Um sicherzustellen, dass der Velero-Supervisor-Dienst ordnungsgemäß funktioniert, müssen Sie zuerst ein Upgrade von ESXi auf Version 8.x durchführen und dann ein Upgrade von vCenter und des Supervisors auf dieselbe 8.x-Version.

  • Der VM-Operator-Pod stürzt bei umfangreichen Ressourcen aufgrund von unzureichendem Speicher ab

    Wenn die Realisierung umfangreicher VirtualMachine-Ressourcen viel Zeit in Anspruch nimmt, zum Beispiel bei Tausenden von VMs, könnte dies daran liegen, dass der VM-Operator-Pod aufgrund von unzureichendem Arbeitsspeicher abstürzt.

    Problemumgehung: Die Problemumgehung und weitere Informationen finden Sie im Knowledge-Base-Artikel 88442.

  • Nach dem Upgrade auf vCenter 8.0 Update 2b befindet sich der von vmon verwaltete wcp-Dienst möglicherweise im Zustand STOPPED, und das vCenter Patching schlägt möglicherweise fehl

    Dieses Problem tritt nur auf, wenn Sie ein Upgrade von vCenter 8.0 Update 1 oder höher auf vCenter 8.0 Update 2b durchführen und über mindestens einen Supervisor verfügen, der die VDS-Netzwerktopologie verwendet und sich auf Kubernetes 1.24 befindet.

    Problemumgehung: Um dieses Problem zu vermeiden, führen Sie ein Upgrade des Supervisors auf Kubernetes 1.25 oder höher durch, bevor Sie ein Upgrade von vCenter auf Version 8.0 Update 2b durchführen. Weitere Informationen erhalten Sie beim Kundensupport.

  • Supervisor-Vorgänge schlagen fehl, wenn benutzerdefinierte vCenter-Zertifikate größer als 8 K sind

    In vSphere 8.0 Update 2b ist die maximale Schlüsselgröße einer CSR in einem vCenter-System von 16384 Bit auf 8192 Bit gesunken. Wenn die Schlüsselgröße Ihres Zertifikats mehr als 8192 Bit beträgt, können Sie ein unvorhersehbares Verhalten von Supervisor-Vorgängen beobachten. Beispielsweise können Vorgänge wie Supervisor-Aktivierungen oder -Upgrades fehlschlagen.

    Problemumgehung:

    Generieren Sie jedes vCenter-Zertifikat, das eine Schlüsselgröße von mehr als 8192 Bit aufweist, neu.

    1. Ermitteln Sie alle Zertifikate mit einer Schlüsselgröße von mehr als 8192 Bit.

      for store in TRUSTED_ROOTS MACHINE_SSL_CERT vpxd-extension wcp ; do echo $store; /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store "$store" --text | grep Public-Key; done

    2. Ersetzen Sie alle Zertifikate, deren Schlüsselgröße 8192 Bit überschreitet.

    3. Registrieren Sie vCenter erneut in NSX, wenn Sie NSX verwenden.

    4. Starten Sie den WCP-Dienst neu.

    Weitere Informationen finden Sie im Knowledge-Base-Artikel 96562.

  • Vorlagen werden möglicherweise aus der Inhaltsbibliothek in vCenter gelöscht, wenn die Bibliothek mit mehreren vSphere-Namespaces verknüpft ist

    Dieses Problem können Sie feststellen, wenn eine Bibliothek mit mehreren Namespaces in vSphere IaaS Control Plane verbunden ist und entweder die Verknüpfung der Bibliothek mit einem Namespace aufgehoben wird oder ein Namespace gelöscht wird.

    Problemumgehung:

    Verwenden Sie möglichst keine lokale Bibliothek, wenn Sie die Bibliothek mit mehreren Namespaces verknüpfen möchten. Erstellen Sie stattdessen eine veröffentlichte Bibliothek in vCenter und laden Sie alle Vorlagen in die veröffentlichte Bibliothek hoch. Erstellen Sie dann eine abonnierte Bibliothek, die die Vorlagen aus der veröffentlichten Bibliothek im selben vCenter synchronisiert und diese abonnierte Bibliothek mit mehreren Namespaces verknüpft. Selbst wenn die Verknüpfung einer Bibliothek mit einem beliebigen Namespace aufgehoben oder ein Namespace gelöscht wird, werden die Bibliothekselemente in diesem Fall nicht aus vCenter gelöscht.

  • Es treten Fehler auf, wenn Sie VMware vSphere Automation REST APIs verwenden, um eine VM-Klasse zu erstellen oder zu aktualisieren und Ganzzahlfelder in die configSpec aufzunehmen

    Sie können die folgenden Fehler feststellen, wenn die configSpec Ganzzahlfelder wie numCPU oder memoryMB enthält:

    Unbekannter Fehler – vcenter.wcp.vmclass.configspec.invalid: json: nicht unterstützter Diskriminator Typ: struct.

    Unbekannter Fehler – vcenter.wcp.vmclass.configspec.invalid: json: Unmarshalling von Zeichenfolge in Go struct-Feld VirtualMachineConfigSpec.<Feldname> des Typs int32 nicht möglich.

    Dieses Problem tritt aufgrund eines bekannten Problems im VAPI-Endpoint auf, der Raw REST configSpec JSON mit Ganzzahlen analysiert und Ganzzahlen als Zeichenfolgen übergibt, die Fehler verursachen. Das Problem tritt nur auf, wenn Sie die REST APIs über das VMware Developer Center verwenden.

    Problemumgehung: Verwenden Sie anstelle der REST APIs DCLI oder den vSphere Client, um die VM-Klassen zu erstellen oder zu aktualisieren.

    Alternativ können Sie das vSphere Automation SDK für Python/Java verwenden. Das folgende Beispiel zeigt, wie Sie den öffentlichen Protokoll-Transcoder-Dienst verwenden, um ein VirtualMachineConfigSpec-Objekt (vim.vm.ConfigSpec) zu konvertieren, das von vCenter mithilfe von pyvmomi bezogen wurde. Der letzte Eintrag des Beispiels zeigt, wie eine manuell gestaltete JSON-Datei analysiert wird. Das Objekt kann dann an die VirtualMachineClasses-API gesendet werden.

  • Nachdem Sie eine gültige vSphere VMware Foundation-Lizenz auf einen Supervisor angewendet haben, wird auf der Seite „Arbeitslastverwaltung“ weiterhin die alte Evaluierungslizenz mit einer Ablaufwarnung angezeigt

    Dieses Problem kann auftreten, wenn Sie den Supervisor mit einer Evaluierungslizenz aktiviert haben und die vSphere VMware Foundation-Lizenz auf den Supervisor anwenden. Die neue Lizenz wird jedoch nicht auf der Seite „Arbeitslastverwaltung“ im vSphere Client unter vCenter > Arbeitslastverwaltung > Supervisoren > Supervisor angezeigt. Der vSphere Client zeigt weiterhin die Warnung mit dem Ablaufdatum der alten Evaluierungslizenz an, obwohl der neue Lizenzschlüssel erfolgreich angewendet wurde.

    Problemumgehung: Keine. Die neue Lizenz wird im vSphere Client unter Administration > Lizenzen > Assets > Supervisoren korrekt angezeigt.

  • Die aktualisierte Sicherheitsrichtlinienregel in der Sicherheitsrichtlinien-CRD wird nicht wirksam, wenn es sich bei der hinzugefügten oder gelöschten Regel nicht um die letzte Regel handelt

    Als DevOps können Sie die Sicherheitsrichtlinien-CRD so konfigurieren, dass eine NSX-basierte Sicherheitsrichtlinie auf einen Supervisor-Cluster-Namespace angewendet wird. Wenn Sie die CRD aktualisieren und eine Sicherheitsrichtlinienregel hinzufügen oder löschen, wird die aktualisierte Regel nur wirksam, wenn sie die letzte Regel in der Regelliste ist.

    Problemumgehung: Fügen Sie die Regel am Ende der Regelliste hinzu oder verwenden Sie eine separate Sicherheitsrichtlinie zum Hinzufügen oder Löschen von Regeln.

  • Änderungen beim Format des VM-Image-Namens in vSphere 8.0 U2 führen möglicherweise zu Problemen, wenn alte VM-Image-Namen verwendet werden

    Vor vSphere 8.0 Update 2 wurde der Name einer VM-Image-Ressource vom Namen eines Inhaltsbibliothekselements abgeleitet. Wenn beispielsweise ein Element der Inhaltsbibliothek den Namen photonos-5-x64 hatte, wurde die entsprechende VirtualMachineImage-Ressource auch als photonos-5-x64 bezeichnet. Dies führte zu Problemen, wenn Bibliothekselemente aus verschiedenen Bibliotheken dieselben Namen hatten.

    In vSphere 8.0 Update 2 wurde der VM-Image-Dienst eingeführt, um VM-Images auf Self-Service-Weise zu verwalten. Weitere Informationen finden Sie unter Erstellen und Verwalten von Inhaltsbibliotheken für eigenständige VMs in vSphere IaaS Control Plane.

    Diese neue Funktion ermöglicht die Zuordnung von Inhaltsbibliotheken zu einem Namespace oder zum gesamten Supervisor-Cluster und verlangt, dass die Namen der VM-Image-Ressourcen in Kubernetes-Clustern eindeutig und deterministisch sind. Um potenzielle Konflikte bei Namen von Bibliothekselementen zu vermeiden, kommt bei den VM-Images daher jetzt das neue Benennungsformat vmi-xxx zur Anwendung. Diese Änderung kann jedoch zu Problemen bei der Version vSphere 8.0 Update 2 führen, wenn Sie vorherige VM-YAMLs verwenden, die auf alte Image-Namen wie photonos-5-x64 oder centos-stream-8 verweisen.

    Problemumgehung:

    1. Rufen Sie Informationen über VM-Images mithilfe der folgenden Befehle ab:

      • Um Images anzuzeigen, die ihren Namespaces zugeordnet sind, führen Sie kubectl get vmi -n <namespace> aus.

      • Um die im Cluster verfügbaren Images abzurufen, führen Sie kubectl get cvmi aus.

    2. Aktualisieren Sie nach dem Abrufen des Image-Ressourcennamens, der in der Spalte NAME aufgeführt ist, den Namen in Ihrer VM-Bereitstellungsspezifikation.

  • Während eines automatischen Supervisor-Upgrades löst der WCP-Dienstprozess auf vSphere unter Umständen eine Panik aus und stoppt unerwartet

    Sie können feststellen, dass eine Core-Dump-Datei für den WCP-Dienstprozess generiert wurde.

    Problemumgehung: Keine. Der VMON-Prozess startet den WCP-Dienst automatisch neu, und der WCP-Dienst setzt das Upgrade ohne weitere Probleme fort.

  • Supervisor-Upgrade wird mit „ErrImagePull“ und dem Status „Anbieter fehlgeschlagen“ in vSphere-Pods angehalten. Dauerhafte Volumes, die an vSphere-Pods (einschließlich Supervisor-Dienste) angehängt sind, werden bei ErrImagePull-Fehlern möglicherweise nicht getrennt.

    Dauerhafte Volumes werden für vSphere-Pods, die mit „ErrImagePull“ fehlschlagen, möglicherweise nicht getrennt. Dies kann dazu führen, dass eine Reihe von vSphere-Pods fehlschlägt, weil die erforderlichen dauerhaften Volumes an die fehlgeschlagene Instanz angehängt sind. Während des Supervisor-Upgrades wechseln vSphere-Pods innerhalb des Supervisors unter Umständen in den Status provider failed und reagieren nicht mehr.

    Problemumgehung: Löschen Sie die Instanzen der fehlgeschlagenen vSphere-Pods, die mit dauerhaften Volumes verbunden sind. Beachten Sie unbedingt, dass Beanspruchungen von dauerhaften Volumes (PVC) und mit vSphere-Pods verknüpfte dauerhafte Volumes beibehalten werden können. Erstellen Sie im Anschluss an das Upgrade die vSphere-Pods mithilfe derselben PodSpecPVC neu, um die Datenintegrität und -funktionalität aufrechtzuerhalten. Erstellen Sie zur Vermeidung dieses Problem Sie vSphere-Pods mithilfe von ReplicaSets (DaemonSet, Bereitstellung), um eine stabile Gruppe von vSphere-Pods aufrechtzuerhalten, die jederzeit ausgeführt werden.

  • Das Supervisor-Upgrade bleibt bei 50 % hängen, und das Pinniped-Upgrade schlägt aufgrund der Leader-Auswahl fehl

    Pinniped-Pods verbleiben während der Bereitstellung im Status „Ausstehend“, und das Supervisor-Upgrade schlägt während des Upgrades der Pinniped-Komponente fehl.

    Schritte zur Problemumgehung:

    1. Führen Sie kubectl get pods -n vmware-system-pinniped aus, um den Status der Pinniped-Pods zu überprüfen.

    2. Führen Sie kubectl get leases -n vmware-system-pinniped pinniped-supervisor -o yaml aus, um sicherzustellen, dass holderIdentity nicht zu den Pinniped-Pods im Status „Ausstehend“ gehört.

    3. Führen Sie kubectl delete leases -n vmware-system-pinniped pinniped-supervisor aus, um das Lease-Objekt für den Pinniped-Supervisor mit einem inaktiven Port wie holderIdentity zu entfernen.

    4. Führen Sie kubectl get pods -n vmware-system-pinniped erneut aus, um sicherzustellen, dass alle Pods unter „vmware-system-pinniped“ aktiviert sind und ausgeführt werden.

  • Ein ESXi-Hostknoten kann nicht in den Wartungsmodus wechseln, wenn die VM der Supervisor-Steuerungsebene eingeschaltet ist

    In einer Supervisor-Einrichtung mit NSX Advanced Load Balancer kann der ESXi-Host nicht in den Wartungsmodus versetzt werden, wenn die VM der Avi-Dienst-Engine eingeschaltet ist. Dies wirkt sich auf das ESXi-Host- und NSX-Upgrade mit dem Wartungsmodus aus.

    Problemumgehung: Schalten Sie die VM der Avi-Dienst-Engine aus, damit ESXi in den Wartungsmodus wechseln kann.

  • Es kann kein Loopback-Datenverkehr mithilfe von ClusterIP mit vSphere Pods auf VDIS empfangen werden

    Wenn eine Anwendung innerhalb eines vSphere Pods versucht, eine Cluster-IP zu erreichen, die innerhalb desselben vSphere-Pods (in einem anderen Container) bereitgestellt wird, kann der DLB innerhalb von VSIP den Datenverkehr nicht zurück an den vSphere Pod weiterleiten.

    Problemumgehung: Keine.

  • Netzwerkrichtlinien werden in einem VDS-basierten Supervisor nicht erzwungen

    Vorhandene Dienst-YAML, die NetworkPolicy verwendet, erfordert keine Änderungen. Die NetworkPolicy wird nicht erzwungen, wenn sie in der Datei vorhanden ist.

    Problemumgehung: Sie müssen richtlinienbasierte Regeln für das Netzwerk für VDS festlegen. Für die NetworkPolicy-Unterstützung ist NSX-Netzwerkunterstützung erforderlich.

  • Der Namespace eines Carvel-Diensts wird möglicherweise weiterhin im vSphere Client angezeigt, nachdem Sie den Dienst vom Supervisor deinstalliert haben

    Wenn die Deinstallation des Carvel-Diensts auf dem Supervisor über 20 Minuten dauert, wird der zugehörige Namespace möglicherweise weiterhin im vSphere Client angezeigt, nachdem der Dienst deinstalliert wurde.

    Versuche, den Dienst auf demselben Supervisor neu zu installieren, schlagen fehl, bis der Namespace gelöscht wird. Und die Meldung ns_already_exist_error wird während der Neuinstallation angezeigt.

    Der folgende Eintrag wird in der Protokolldatei angezeigt:

    /var/log/vmware/wcp/wcpsvc.log should have the message - "Time out for executing post-delete operation for Supervisor Service with serviceID '<service-id>' from cluster '<cluster-id>'. Last error: <error>"

    Problemumgehung: Löschen Sie den Namespace manuell aus dem vSphere Client.

    1. Wählen Sie im vSphere Client-Startmenü die Option Arbeitslastverwaltung aus.

    2. Klicken Sie auf die Registerkarte Namespaces.

    3. Wählen Sie in der Liste der Namespaces den nicht gelöschten Namespace aus und klicken Sie auf die Schaltfläche ENTFERNEN, um den Namespace zu löschen.

  • Das Upgrade von ESXi-Hosts von 7.0 Update 3 auf 8.0 ohne Supervisor-Upgrade führt dazu, dass ESXi-Hosts als „Nicht bereit“ angezeigt werden und Arbeitslasten offline geschaltet werden

    Wenn Sie ein Upgrade der ESXi-Hosts, die Teil eines Supervisors sind, von vSphere 7.0 Update 3 auf vSphere 8.0 durchführen und kein Upgrade der Kubernetes-Version des Supervisors, werden die ESXi-Hosts als „Nicht bereit“ angezeigt, und die auf den Hosts ausgeführten Arbeitslasten werden offline geschaltet.

    Problemumgehung: Führen Sie ein Upgrade der Kubernetes-Version des Supervisors auf mindestens 1.21, 1.22 oder 1.23 durch.

  • Beim One-Click-Upgrade von vCenter Server wird der Supervisor nicht automatisch aktualisiert

    Wenn die Kubernetes-Version des Supervisors eine Version vor 1.22 hat, kann der Supervisor beim One-Click-Upgrade von vCenter Server auf 8.0 kein automatisches Upgrade auf die unterstützte Mindestversion von Kubernetes für 8.0 (1.23) durchführen.

    Problemumgehung: Führen Sie vor dem Upgrade von vCenter Server für 8.0 ein Upgrade der Kubernetes-Version des Supervisors auf 1.22 durch. Wenn Sie für vCenter Server bereits ein Upgrade auf 8.0 durchgeführt haben, führen Sie ein manuelles Upgrade der Kubernetes-Version des Supervisors auf Version 1.23 durch.

  • Wenn Sie Regeln in einer benutzerdefinierten Ressource für Sicherheitsrichtlinien ändern, werden veraltete Regeln möglicherweise nicht gelöscht

    Dieses Problem kann beim Aktualisieren der Sicherheitsrichtlinie auftreten. Beispiel: Sie erstellen eine benutzerdefinierte Ressource für Sicherheitsrichtlinien, die die Regeln A und B enthält, und aktualisieren die Richtlinie dann, indem Sie die Regeln in B und C ändern. Dies führt dazu, dass Regel A nicht gelöscht wird. Die NSX Management Plane zeigt die Regel A zusätzlich zu B und C weiterhin an.

    Problemumgehung: Löschen Sie die Sicherheitsrichtlinie und erstellen Sie sie dann erneut.

  • Nach einem Upgrade von vCenter Server und vSphere IaaS Control Plane kann ein Tanzu Kubernetes Grid-Cluster das Upgrade aufgrund von Volumes, die als an die Knoten des Clusters angehängt erscheinen, nicht abschließen

    Wenn der Tanzu Kubernetes Grid-Cluster nicht aktualisiert werden kann, ist ein Volume vorhanden, das als an die Knoten des Clusters angehängt erscheint und nicht gelöscht wird. Dieses Problem kann durch ein Problem im vorgeschalteten Kubernetes verursacht werden.

    Problemumgehung:

    1. Mit dem folgenden Befehl erhalten Sie Informationen über den TKG-Clusterknoten, für den die Planung deaktiviert wurde:

      kubectl get node tkc_node_name -o yaml

      Beispiel:

      # kubectl get node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 -o yaml
apiVersion: v1
kind: Node
metadata:
  annotations:
    cluster.x-k8s.io/cluster-name: gcm-cluster-antrea-1
    cluster.x-k8s.io/cluster-namespace: c1-gcm-ns
    cluster.x-k8s.io/machine: gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95
    cluster.x-k8s.io/owner-kind: MachineSet
    cluster.x-k8s.io/owner-name: gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7
    csi.volume.kubernetes.io/nodeid: '{"csi.vsphere.vmware.com":"gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95"}'
    kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock
    node.alpha.kubernetes.io/ttl: "0"
    volumes.kubernetes.io/controller-managed-attach-detach: "true"
….
….
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd

      Überprüfen Sie, ob dieser Knoten über vSphere CSI-Volumes in der Eigenschaft status.volumeAttached verfügt. Wenn Volumes vorhanden sind, fahren Sie mit dem nächsten Schritt fort.

    2. Stellen Sie sicher, dass auf dem in Schritt 1 identifizierten Knoten keine Pods ausgeführt werden. Verwenden Sie diesen Befehl:

      kubectl get pod -o wide | grep tkc_node_name

      Beispiel:

      kubectl get pod -o wide | grep gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95

      Die leere Ausgabe dieses Befehls gibt an, dass keine Pods vorhanden sind. Fahren Sie mit dem nächsten Schritt fort, da die Ausgabe in Schritt 1 ein Volume anzeigt, das an den Knoten angehängt ist, der über keine Pods verfügt.

    3. Rufen Sie Informationen zu allen Knotenobjekten ab, um sicherzustellen, dass dasselbe Volume an einen anderen Knoten angehängt ist:

      kubectl get node -o yaml

      Beispiel:

      Derselbe Volume-Name wird in zwei TKG-Clusterknotenobjekten angezeigt.

      On old node - "gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95"
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd

On new node "gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88"
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
    ...
  volumesInUse:
  - kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
  ...

    4. Suchen Sie das PV basierend auf dem Volume-Handle im Volume-Namen.

      Im obigen Beispiel lautet der Volume-Name kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd und der Volume-Handle lautet 943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd.

      Rufen Sie alle PVs ab und suchen Sie mithilfe des folgenden Befehls nach dem oben genannten Volume-Handle:

      kubectl get pv -o yaml

      Im obigen Beispiel lautet das PV mit diesem Volume-Handle pvc-59c73cea-4b75-407d-8207-21a9a25f72fd.

    5. Verwenden Sie den Befehl volumeattachment, um nach dem PV zu suchen, das im vorherigen Schritt gefunden wurde:

      kubectl get volumeattachment | grep pv_name

      Beispiel:

      # kubectl get volumeattachment | grep pvc-59c73cea-4b75-407d-8207-21a9a25f72fd
NAME                                                                   ATTACHER                 PV                                         NODE                                                 ATTACHED   AGE
csi-2ae4c02588d9112d551713e31dba4aab4885c124663ae4fcbb68c632f0f46d3e   csi.vsphere.vmware.com   pvc-59c73cea-4b75-407d-8207-21a9a25f72fd   gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88   true       3d20h

      Sie können einen Volume-Anhang beobachten, der an den Knoten gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88 angehängt ist, anstelle des Knotens gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95. Dies weist darauf hin, dass status.volumeAttached in gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 falsch ist.

    6. Löschen Sie den veralteten volumeAttached-Eintrag aus dem Knotenobjekt:

      kubectl edit node tkc_node_name

      Beispiel:

      kubectl edit node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95

      Entfernen Sie den veralteten Volume-Eintrag aus status.volumeAttached.

    7. Wiederholen Sie die obigen Schritte für alle veralteten Volumes in der Eigenschaft status.volumeAttached.

    8. Wenn WCPMachines noch vorhanden ist, löschen Sie den Eintrag manuell und warten Sie einige Minuten, bis der Cluster abgeglichen ist.

      # kubectl get wcpmachines -n c1-gcm-ns
NAMESPACE   NAME                                       ZONE   PROVIDERID                                       IPADDR
c1-gcm-ns   gcm-cluster-antrea-1-workers-jrc58-zn6wl          vsphere://423c2281-d1bd-9f91-0e87-b155a9d291a1   192.168.128.17

# kubectl delete wcpmachine gcm-cluster-antrea-1-workers-jrc58-zn6wl -n c1-gcm-ns
wcpmachine.infrastructure.cluster.vmware.com "gcm-cluster-antrea-1-workers-jrc58-zn6wl" deleted

  • Wenn ein vSphere-Administrator eine Self-Service-Namespace-Vorlage mit Ressourcengrenzwerten konfiguriert, die die Clusterkapazität überschreiten, wird keine Warnung ausgelöst.

    Wenn vSphere-Administratoren Ressourcengrenzwerte konfigurieren, die die Clusterkapazität überschreiten, verwenden DevOps-Ingenieure möglicherweise die Vorlage, um vSphere Pods mit hohen Ressourcen bereitzustellen. Infolgedessen schlägt die Arbeitslast möglicherweise fehl.

    Problemumgehung: Keine

  • Wenn Sie einen Supervisor-Namespace löschen, der einen Tanzu Kubernetes Grid-Cluster enthält, bleiben im Supervisor vorhandene Beanspruchungen eines persistenten Volumes möglicherweise im Abbruchzustand

    Sie können dieses Problem beobachten, wenn ein Ressourcenkonflikt auftritt, während das System den Namespace löscht und Volumes von den Pods im Tanzu Kubernetes Grid-Cluster trennt.

    Das Löschen des Supervisor-Namespace bleibt unvollständig, und der vSphere Client zeigt den Namespace-Status als beendet an. Beanspruchungen eines persistenten Volumes, die an Pods im Tanzu Kubernetes Grid-Cluster angehängt wurden, verbleiben ebenfalls im Abbruchzustand.

    Wenn Sie die folgenden Befehle ausführen, wird der Fehler Operation cannot be fulfilled on persistentvolumeclaims angezeigt:

    kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME

    kubectl logs vsphere-csi-controller-pod-name -n vmware-system-csi -c vsphere-syncer

    failed to update PersistentVolumeClaim: \\\"<pvc-name>\\\" on namespace: \\\"<supervisor-namespace>\\\". Error: Operation cannot be fulfilled on persistentvolumeclaims \\\"<pvc-name>\\\": the object has been modified; please apply your changes to the latest version and try again\

    Problemumgehung:

    Verwenden Sie die folgenden Befehle zur Behebung des Problems:

    kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME

    kubectl patch pvc <pvc-name> -n <supervisor-namespace> -p '{"metadata":{"finalizers":[]}}' --type=merge

  • Beim Löschen mehrerer FCDs und Volumes aus gemeinsam genutzten Datenspeichern wie vSAN treten möglicherweise Leistungsänderungen auf

    Die Leistungsänderungen können durch ein behobenes Problem verursacht werden. Solange das Problem nicht behoben wurde, blieben veraltete FCDs und Volumes nach einem fehlgeschlagenen FCD-Löschvorgang im Datenspeicher.

    Problemumgehung: Keine. Der Löschvorgang funktioniert trotz der Leistungsänderung wie gewohnt.

  • Wenn ein DevOps-Benutzer Volume-Vorgänge oder statusbehaftete Anwendungsbereitstellungen startet, während vCenter Server neu startet, schlagen die Vorgänge möglicherweise fehl

    Das Problem tritt auf, weil das Benutzerkonto für die Arbeitslastspeicherverwaltung gesperrt wird und das auf dem Supervisor ausgeführte vSphere CSI-Plug-In nicht authentifiziert werden kann. Dies führt dazu, dass die Volume-Vorgänge mit InvalidLogin-Fehlern fehlschlagen.

    Die Protokolldatei /var/log/vmware/vpxd/vpxd.log enthält die folgende Fehlermeldung:

    Authentication failed: The account of the user trying to authenticate is locked. :: The account of the user trying to authenticate is locked. :: User account locked: {Name: workload_storage_management-<id>, Domain: <domain>})

    Problemumgehung:

    1. Rufen Sie die Entsperrzeit des Kontos ab.

      1. Navigieren Sie im vSphere Client zu „Verwaltung“ und klicken Sie unter „Single Sign-On“ auf „Konfiguration“.

      2. Klicken Sie auf die Registerkarte der designierten Konten.

      3. Rufen Sie unter „Sperrrichtlinie“ die Entsperrzeit in Sekunden ab.

    2. Authentifizieren Sie sich mithilfe des vSphere-Plug-Ins für kubectl beim Supervisor.

      kubectl vsphere login –server IP-ADDRESS --vsphere-username USERNAME

    3. Notieren Sie sich die ursprüngliche Replikatanzahl für die Bereitstellung von vsphere-csi-controller im Namespace vmware-system-csi-.

      kubectl get deployment vsphere-csi-controller -n vmware-system-csi -o=jsonpath='{.spec.replicas}'

      original-replica-count

    4. Skalieren Sie die Anzahl der vsphere-csi-controller-Bereitstellungsreplikate auf null herunter.

      kubectl scale --replicas=0 deployment vsphere-csi-controller -n vmware-system-csi

    5. Warten Sie, bis die Anzahl der Sekunden, die unter „Entsperrzeit“ angegeben ist, verstrichen ist.

    6. Skalieren Sie die Anzahl der vsphere-csi-controller-Bereitstellungsreplikate auf den ursprünglichen Wert hoch.

      kubectl scale --replicas=original-replica-count deployment vsphere-csi-controller -n vmware-system-csi

Bekannte Probleme mit TKG bei Supervisor

  • Wenn Sie ein Upgrade Ihrer vSphere IaaS Control Plane 7.0.x-Umgebung auf vSphere 8.0.x durchführen, werden alle TKG-Cluster der Version v1.27.6 inkompatibel

    vSphere 8.0.x bietet keine Unterstützung für TKR 1.27.6.

    Dies führt dazu, dass die TKG-Cluster von v1.27.6 inkompatibel werden, nachdem Sie vSphere IaaS Control Plane 7.0.x auf vSphere 8.0.x aktualisiert haben. Sie erhalten während des Supervisor-Upgrades keine Warnungen bei der Vorabprüfung.

    Problemumgehung:

    • Wenn Sie auf vSphere 7.0.x ausgeführte TKGS-Cluster der Version v1.27.6 verfügen, führen Sie kein Upgrade auf vCenter 8.0.x durch, insbesondere nicht auf vCenter 8.0 Update 2b. Weitere Informationen finden Sie in den Versionshinweisen zu VMware Tanzu Kubernetes-Versionen und in KB-Artikel 96501.

    • Wenn Sie ein Upgrade Ihrer vSphere 7.x-Umgebung auf vCenter 8.x durchführen möchten, führen Sie kein Upgrade auf TKR 1.27.6 durch.

  • Worker-Knoten des TKG-Clusters können nicht eingeschaltet werden und es wird folgende Meldung im Fehlerprotokoll des nsx-ncp-Pod ausgegeben: VIF restore activity already completed for attachment ID

    Worker-Knoten des TKG-Clusters können nicht eingeschaltet werden. Dabei wird folgende Fehlermeldung ausgegeben:

    nsx-container-ncp Generic error occurred during realizing network for VirtualNetworkInterface

    NCP protokolliert einen Fehler:

    VIF restore activity already completed for attachment ID

    Wenn eine VM eines TKG-Clusterknotens, der nach einer NSX-Sicherung erstellt wurde, unmittelbar nach der NSX-Wiederherstellung mit vMotion migriert wird, kann NCP den Port für die VM nicht wiederherstellen, da die Anhangs-ID in vMotion wiederverwendet wird und die NCP-Wiederherstellungsanforderung blockiert wird.

    Problemumgehung:

    1. Navigieren Sie zu NSX Manager, um die zu löschenden Segmentports abzurufen. Sie weisen einen Anzeigenamen im folgenden Format auf: <vm name>.vmx@<attachment id>

    2. Suchen Sie vor dem Löschen des neu erstellten Ports den Host, auf dem die VM ausgeführt wird, und deaktivieren Sie ops-agent, indem Sie /etc/init.d/nsx-opsagent stop auf dem Host ausführen.

    3. Löschen Sie den Port mithilfe von NSX API: https://<nsx-mgr>/api/v1/logical-ports/<logical switch port id>?detach=true

    4. Aktivieren Sie ops-agent, indem Sie /etc/init.d/nsx-opsagent start auf dem Host ausführen.

    5. Warten Sie, bis NCP den Port wiederhergestellt hat.

  • Pods, PVs und PVCs in einem TKG-Cluster bleiben während der TKG-Clusterbereinigung oder der Wiederherstellung nach Ausfällen von ESXi-Hosts unter Umständen mit dem Status Terminating hängen

    Im Rahmen des normalen Lösch- und Bereinigungsvorgangs des TKG-Clusters werden alle Bereitstellungen, StatefulSets, PVCs, PVs und ähnliche Objekte gelöscht. Bei TKG-Clustern, die auf TKR v1.24 und früher basieren, bleiben jedoch einige der PVs aufgrund von DetachVolume-Fehlern unter Umständen mit dem Status Terminating hängen. Dieses Problem tritt auf, wenn DetachVolume-Fehler in einem VolumeAttachment-Objekt dazu führen, dass die Finalisierer auf dem VolumeAttachment nicht entfernt werden und es somit zu einem Fehler beim Löschen verwandter Objekte kommt. Dieses Szenario ist auch möglich, wenn auf den ESXi-Hosts Ausfallzeiten auftreten.

    Problemumgehung: Führen Sie den folgenden Befehl im TKG-Cluster aus, um die Finalisierer aus Volumeattachments mit einem detachError zu entfernen:

    kubectl get volumeattachments \
-o=custom-columns='NAME:.metadata.name,UUID:.metadata.uid,NODE:.spec.nodeName,ERROR:.status.detachError' \
--no-headers | grep -vE '<none>$' | awk '{print $1}' | \
xargs -n1 kubectl patch -p '{"metadata":{"finalizers":[]}}' --type=merge volumeattachments

  • TGK-Cluster nach Sicherung und Wiederherstellung nicht erreichbar

    Wenn ein vSphere-Namespace nach einer NSX-Sicherung erstellt und mit einem angepassten Ingress-/Egress-CIDR konfiguriert wird, kann NCP nach der Wiederherstellung von NSX aus einer Sicherung den Wiederherstellungsvorgang nicht abschließen und TKG-Cluster im vSphere-Namespace sind nicht verfügbar. NCP schlägt während des Wiederherstellungsvorgangs mit einem Fehler ähnlich dem folgenden fehl:

    NSX IP Pool ipp_<supervisor_namespace_id>_ingress not found in store

    Problemumgehung: Wenn eine Sicherung des Supervisors ungefähr zur gleichen Zeit wie die NSX-Sicherung, aber vor der Erstellung des betroffenen vSphere-Namespace durchgeführt wurde, stellen Sie den Supervisor ebenfalls aus der Sicherung wieder her. Löschen Sie alternativ den vSphere-Namespace und die zugehörigen TKG-Cluster, warten Sie, bis NCP neu synchronisiert wurde, und erstellen Sie die gelöschten Ressourcen dann neu.

  • TKG-Cluster ist nach NSX-Sicherung und -Wiederherstellung nicht erreichbar

    Wenn ein Supervisor mit einem angepassten Ingress-CIDR konfiguriert ist, sind TKG-Cluster nach einer NSX-Sicherung/-Wiederherstellung unter Umständen nicht mehr verfügbar, da die NCP-Komponente die Ingress-VIP der TKG-Cluster nicht ordnungsgemäß validieren kann.

    Problemumgehung: Führen Sie mithilfe der NSX-API eine manuelle Konfiguration der VIPs für TKG-Cluster in NSX durch, um den Zugriff wiederherzustellen.

  • Für vorhandene Tanzu Kubernetes Grid-Cluster mit einem Proxyserver kann kein Upgrade auf einen vSphere 8 Supervisor durchgeführt werden

    BEHOBEN: Dieses bekannte Problem wurde in der Version vSphere 8 with Tanzu MP1 behoben.

    Wenn Sie einen vorhandenen Tanzu Kubernetes Grid-Cluster mit einem Proxyserver konfiguriert haben, können Sie für diesen Cluster kein Upgrade von einem vSphere 7 Supervisor auf Tanzu Kubernetes Grid 2.0 auf vSphere 8 Supervisor durchführen.

    Problemumgehung: Der Inhalt des Felds „noProxy“ steht in Konflikt mit Upgrade-Prüfungen. Da dieses Feld erforderlich ist, wenn die Proxy-Appliance zur Clusterspezifikation hinzugefügt wird, müssen Sie die Proxy-Konfiguration vollständig entfernen, bevor Sie ein Upgrade auf vSphere 8 durchführen.

  • Der Pod „antrea-resource-init“ bleibt im Status „Ausstehend“ hängen

    Nach dem Upgrade der Tanzu Kubernetes-Version eines Tanzu Kubernetes Grid-Clusters befindet sich der Pod „antrea-resource-init“ möglicherweise im Status „Ausstehend“.

    Problemumgehung: Starten Sie den Pod auf dem Supervisor neu.

  • Tanzu Kubernetes Grid-Cluster v1.21.6 wechseln möglicherweise in den Status FALSE. Einige Maschinen werden möglicherweise nicht migriert

    Nach dem Upgrade auf vCenter Server 8 und der Supervisor-Aktualisierung wechseln Tanzu Kubernetes Grid-Cluster in v1.21.6 möglicherweise in den Status FALSE, und einige WCPMachines werden möglicherweise nicht zu vSphereMachines migriert.

    Problemumgehung: Keine

  • Standardmäßig läuft das Kennwort für das Konto „vmware-system-user“ für TKG-Cluster, auf denen die TKR-Version v1.23.8---vmware.2-tkg.2-zshippable ausgeführt wird, in 60 Tagen ab

    Im Rahmen der STIG-Härtung ist für TKG-Cluster, auf denen TKR-Version v1.23.8---vmware.2-tkg.2-zshippable ausgeführt wird, das Konto „vmware-system-user“ so konfiguriert, dass es in 60 Tagen abläuft. Dies kann sich auf Benutzer auswirken, die das Konto „vmware-system-user“ für SSH auf Clusterknoten verwenden.

    Informationen zum Aktualisieren des Ablaufs des Kennworts für „vmware-system-user“, damit bei Bedarf SSH-Sitzungen für TKG-Clusterknoten zugelassen werden können, finden Sie im folgenden Knowledgebase-Artikel: https://kb.vmware.com/s/article/90469

  • Der tanzu-capabilities-controller-manager-Pod wird ständig neu gestartet, und es tritt ein CLBO im TKC in vSphere IaaS Control Plane 8.0.0a auf

    Aufgrund von Problemen mit Dienstkontoberechtigungen bleibt der tanzu-capabilities-controller-manager-Pod im TKG-Cluster bei CLBO (Crash Loop Back Off) hängen, wenn die TKR-Version „v1.23.8+vmware.2-tkg.2-zshippable“ verwendet wird.

    Problemumgehung: Fügen Sie dem Funktionsdienstkonto „tanzu-capabilities-manager-sa“ im TKC die erforderlichen Berechtigungen hinzu.

    1. Halten Sie den Abgleich des Funktionspakets im TKC an:

      kubectl patch -n vmware-system-tkg pkgi tkc-capabilities -p '{"spec":{"paused": true}}' --type=merge

    2. Erstellen Sie eine neue Datei „capabilities-rbac-patch.yaml“:

      apiVersion: v1
kind: Secret
metadata:
  name: tanzu-capabilities-update-rbac
  namespace: vmware-system-tkg
stringData:
  patch-capabilities-rbac.yaml: |
    #@ load("@ytt:overlay", "overlay")
    #@overlay/match by=overlay.subset({"kind":"ClusterRole", "metadata": {"name": "tanzu-capabilities-manager-clusterrole"}}),expects="1+"
    ---
    rules:
      - apiGroups:
        - core.tanzu.vmware.com
        resources:
          - capabilities
        verbs:
          - create
          - delete
          - get
          - list
          - patch
          - update
          - watch
      - apiGroups:
          - core.tanzu.vmware.com
        resources:
          - capabilities/status
        verbs:
          - get
          - patch
          - update-rbac

    3. Patchen Sie die Cluster-Rolle für Funktionen im TKC:

      //Replace tkc with the name of the Tanzu Kubernetes Grid cluster: kubectl patch -n vmware-system-tkg pkgi tkc-capabilities -p '{"metadata":{"annotations":{"ext.packaging.carvel.dev/ytt-paths-from-secret-name.0":"tanzu-capabilities-update-rbac"}}}' --type=merge

    4. Löschen Sie den tanzu-capabilities-controller-manager im TKC.

  • Tanzu Kubernetes Grid 2.0-Cluster auf einem Supervisor mit einer Bereitstellung über drei vSphere-Zonen unterstützen keine VMs mit vGPU und Instanzspeicher.

    Tanzu Kubernetes Grid 2.0-Cluster, die auf einer Supervisor-Instanz mit einer Bereitstellung über drei vSphere Zonen bereitgestellt werden, unterstützen keine VMs mit vGPU und Instanzspeicher.

    Problemumgehung: Keine

  • TKR-Version v1.22.9 ist im Image der Inhaltsbibliothek, aber nicht im kubectl-Befehl aufgeführt

    Die Inhaltsbibliothek für TKR-Images führt TKR v1.22.9 auf. Der Befehl kubectl get tkr führt dieses Image nicht als verfügbar auf, da TKR v1.22.9 nicht zur Verwendung zur Verfügung steht und nicht verwendet werden sollte. Dieses Image wird fälschlicherweise in der Inhaltsbibliothek angezeigt.

    Problemumgehung: Verwenden Sie einen anderen TKR als TKR v1.22.9. Eine Liste der verfügbaren TKRs finden Sie in den TKR-Versionshinweisen.

  • Ein TKC kann nicht mit der v1alpha1-API und einem v1.23.8-TKR in vSphere IaaS Control Plane 8.0.0a bereitgestellt werden

    Bei Verwendung der TKC-v1alpha1-API zur Bereitstellung des TKC mit Version v1.23.8. Die Anfrage schlägt mit der Meldung fehl, dass keine kompatible Vollversion mit dem Versionshinweis „1.23.8“ und den Standardbezeichnungen des Betriebssystems gefunden werden kann: "os-arch=amd64,os-name=photon,os-type=linux,os-version=3.0".

    Problemumgehung: Bei der Bereitstellung von TKCs zu TKC-v1alpha2- oder -v1alpha3-APIs wechseln

  • Tanzu Kubernetes Grid 2.0 Cluster, die mit v1beta1-API bereitgestellt werden, müssen auf der Standard-ClusterClass basieren

    Wenn Sie einen Tanzu Kubernetes Grid 2.0-Cluster auf Supervisor mithilfe der v1beta1-API erstellen, muss der Cluster auf der Standard-ClusterClass tanzukubernetescluster basieren. Das System gleicht keinen Cluster ab, der auf einer anderen ClusterClass basiert.

    Problemumgehung: Ab Version vSphere 8 U1 können Sie einen v1beta1-Cluster basierend auf einer benutzerdefinierten ClusterClass bereitstellen. Weitere Informationen finden Sie im KB-Artikel https://kb.vmware.com/s/article/91826.

Bekannte Probleme im Zusammenhang mit Netzwerken

  • In einem NSX Advanced Load Balancer-Setup gibt es keinen Abschnitt vom Typusage.ingressCIDRUsage in der Ausgabe clusternetworkinfo oder namespacenetworkinfo

    In einem NSX Advanced Load Balancer-Setup wird die Ingress-IP vom Avi-Controller zugeteilt. Die Nutzung für ingressCIDR wird in der Ausgabe clusternetworkinfo oder namespacenetworkinfo nicht angezeigt.

    Problemumgehung: Rufen Sie die ingressCIDR-Nutzung über die Avi-Controller-Benutzeroberfläche unter Anwendungen > VS-VIPs ab.

  • Pod-CIDR in der Tier-0-Präfixliste wird nach dem Löschen des Namespace für einen gerouteten Supervisor nicht entfernt

    Unter „Gerouteter Supervisor“ wird das Pod-CIDR in einer Tier-O-Präfixliste nach dem Löschen des Namespace nicht entfernt.

    Problemumgehung: Löschen Sie das Objekt in der Präfixliste:

    curl -k -u ‘admin:U2.HzP7QZ9Aw’ -X PATCH -d ‘{“prefixes”:[{“network” : “10.246.0.0/16”,“le” : 28,“action” : “PERMIT”}]}’ https://<IP ADDRESS>/policy/api/v1/infra/tier-0s/ContainerT0/prefix-lists/pl_domain-c9:45c1ce8d-d2c1-43cb-904f-c526abd8fffe_deny_t1_subnets -H ‘X-Allow-Overwrite: true’ -H ‘Content-type: application/json

  • Die Kubernetes-Ressourcen clusternetworkinfo und namespacenetworkinfo enthalten bei Verwendung von NSX Advanced Load Blanacer keine Felder vom Typ usage.ingressCIDRUsage.

    Wenn Sie NSX Advanced Load Balancer in einem NSX-basierten Supervisor verwenden, enthalten die Kubernetes-Ressourcen clusternetworkinfo und namespacenetworkinfo nicht mehr die Felder vom Typ usage.ingressCIDRUsage. Dies bedeutet, dass bei Ausführung von kubectl get clusternetworkinfo <supervisor-cluster-name> -o json oder kubectl get namespacenetworkinfo <namespace-name> -n <namespace-name> -o json kein ingressCIDR-Nutzungsobjekt in der Ausgabe enthalten ist.

    Problemumgehung: Verwenden Sie die Seite „Avi-Controller-Benutzeroberfläche“, um auf die ingressCIDR-Nutzung zuzugreifen.

  • Nach NSX-Sicherung und -Wiederherstellung sind für bestimmte Namespaces veraltete Tier-1-Segmente vorhanden

    Nach einer NSX-Sicherung- und -Wiederherstellung werden veraltete Tier-1-Segmente, die Dienst-Engine-Netzwerkkarten aufweisen, nicht bereinigt.

    Wenn ein Namespace nach einer NSX-Sicherung gelöscht wird, stellt der Wiederherstellungsvorgang veraltete Tier-1-Segmente wieder her, die den Dienst-Engine-Netzwerkkarten des NSX Advanced Load Balancer Controller zugeordnet sind.

    Problemumgehung: Löschen Sie die Tier-1-Segmente manuell.

    1. Melden Sie sich beim NSX Manager an.

    2. Wählen Sie Netzwerk > Segmente aus.

    3. Suchen Sie die veralteten Segmente, die mit dem gelöschten Namespace verknüpft sind.

    4. Löschen Sie die veralteten Dienst-Engine-Netzwerkkarten aus dem Abschnitt Ports/Schnittstellen.

  • Die Lastausgleichsüberwachung funktioniert möglicherweise nicht mehr, der Supervisor bleibt im vSphere Client unter Umständen im Status „Wird konfiguriert“ hängen

    Bei aktiviertem NSX Advanced Load Balancer kann NCP den Status des Lastausgleichsdiensts aufgrund mehrerer Erzwingungspunkte in NSX möglicherweise nicht abrufen. Dies betrifft vorhandene Supervisoren, die mit NSX Advanced Load Balancer konfiguriert sind, sobald dieser in NSX aktiviert wird. Dieses Problem wirkt sich auf neue Supervisoren aus, die NSX Advanced Load Balancer nutzen. Von diesem Problem betroffene Supervisoren sind mit Ausnahme der LB-Überwachungsfunktion weiterhin funktionsfähig.

    Problemumgehung: Deaktivieren Sie NSX Advanced Load Balancer in NSX. Dadurch kann die Bereitstellung von Supervisoren mit NSX Advanced Load Balancer in WCP-Umgebungen mit vorhandenen Supervisoren unter NSX Advanced Load Balancer eingeschränkt werden.

  • Sie können NSX Advanced Load Balancer nicht mit einem vCenter Server verwenden, der eine Topologie im eingebetteten verknüpften Modus verwendet.

    Wenn Sie den NSX Advanced Load Balancer-Controller konfigurieren, können Sie ihn in mehreren Clouds konfigurieren. Sie haben jedoch keine Möglichkeit, mehrere Clouds auszuwählen, während Sie vSphere IaaS Control Plane aktivieren, da dieses Produkt nur die Option Standard-Cloud unterstützt. Dies führt dazu, dass Sie NSX Advanced Load Balancer nicht mit einem vCenter Server verwenden können, der eine Topologie im eingebetteten verknüpften Modus verwendet.

    Konfigurieren Sie NSX Load Balancer für jeden vCenter Server.

Bekannte Probleme im Zusammenhang mit Speicher

  • In einer Umgebung, in der ein Datenspeicher von mehreren vCenter-Systemen gemeinsam genutzt wird, werden mehrere CNS-Volume-Synchronisierungsfehler beobachtet

    Die vCenter-übergreifende Migration wird von CNS nicht unterstützt. Die periodische CNS-Synchronisierung wird jedoch automatisch durchgeführt und führt zu Sperrkonflikten für Volumes im gemeinsam genutzten Datenspeicher.

    Problemumgehung: Um dieses Problem zu vermeiden, richten Sie ein großes Zeitintervall für die periodische CNS-Synchronisierung ein.

    1. Suchen Sie die CNS-Konfigurationsdatei in vCenter:

      /usr/lib/vmware-vsan/VsanVcMgmtConfig.xml

    2. Navigieren Sie zur folgenden Zeile:

      <newSyncInterval>60</newSyncInterval>

      Standardmäßig wird die periodische Synchronisierung auf 60 Sekunden festgelegt.

    3. Ändern Sie den Zeitraum in einen längeren Zeitraum, z. B. 31536000 für 1 Jahr.

  • Der Volume-Zuteilungstyp kann für die Festplatten in einem vSAN Direct-Datenspeicher nicht geändert werden

    Nachdem Sie den Volume-Zuteilungstyp für die Festplatten im vSAN Direct-Datenspeicher festgelegt haben, können Sie ihn nicht mehr ändern. Dies liegt daran, dass die zugrunde liegenden Schichten die Typkonvertierung nicht unterstützen. Die Änderung des Volume-Zuteilungstyps für die neue Festplatte ist jedoch für Vorgänge wie Klonen und Verlagern zulässig.

    Problemumgehung: Keine

  • Gelöschte VM haben zur Folge, dass CNS-Aufgaben in der Warteschlange hängen blieben.

    An CNS gesendete Vorgänge geben eine Aufgaben-ID zurück. Der Aufgabenstatus verbleibt jedoch unverändert im Status „In der Warteschlange“. Die Aufgaben gelten für Volumes, die mit einer soeben gelöschten VM verbunden sind.

    Problemumgehung: Wenn die Anwendungsschicht die Reihenfolge der Aufrufe korrigieren kann, müssen CNS-seitig keine Maßnahmen ergriffen werden. Deaktivieren Sie andernfalls die neue CNS-Serialisierung, indem Sie die folgenden Schritte ausführen:

    1. Öffnen Sie /usr/lib/vmware-vsan/VsanVcMgmtConfig.xml in vCenter.

    2. Ändern Sie die folgende Konfiguration in „false“: <newSerializationEnabled>true</newSerializationEnabled>

    3. Neustart von vsan-health mit vmon-cli -r vsan-health

    Weitere Informationen finden Sie im KB-Artikel 93903.

  • PVs verbleiben nach erfolgreichem Löschen von PVCs im Status „Beendet“

    Nachdem Sie ein PersistentVolumeClaim (PVC) gelöscht haben, verbleibt das entsprechende PersistentVolume (PV) im Supervisor möglicherweise im Status „Beendet“. Darüber hinaus zeigt der vSphere Client möglicherweise mehrere fehlgeschlagene deleteVolume-Aufgaben an.

    Problemumgehung:

    1. Authentifizieren Sie sich beim Supervisor:

      kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME

    2. Rufen Sie den Namen des dauerhaften Volumes im Status „Wird beendet“ ab:

      kubectl get pv

    3. Notieren Sie sich den Volume-Handle aus dem persistenten Volume:

      kubectl describe pv <pv-name>

    4. Löschen Sie mithilfe des Volume-Handle aus dem vorherigen Schritt die benutzerdefinierte CnsVolumeOperationRequest-Ressource im Supervisor:

      kubectl delete cnsvolumeoperationrequest delete-<volume-handle>

    Hinweis:

    Stellen Sie vor dem Löschen eines PV sicher, dass es nicht von anderen Ressourcen im Cluster verwendet wird.

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