Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten

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

  • 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 | 18. APRIL 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 – In dieser Version wird Kubernetes 1.25 neu 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 Creation wird eingestellt

    Die Erstellung der eingebetteten Harbor-Instanz vRegistry wird eingestellt. 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 vSphere with Tanzu 8.x-Versionen.

  • 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 vSphere with Tanzu 8 Supervisor-Versionen. 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 von vSphere with Tanzu 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 vSphere with Tanzu 8.0.0 GA bereitgestellt haben, müssen Sie vor dem Upgrade auf vSphere with Tanzu 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 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 with Tanzu 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 with Tanzu 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 with Tanzu-Dokumentation verfügt nun über eine verbesserte Struktur, die die Workflows mit dem Produkt besser widerspiegelt und Ihnen eine genauere Erfahrung mit den Inhalten ermöglicht. Sie können auch auf der neuen Zielseite für vSphere with Tanzu-Dokumentation auf alle verfügbaren technischen Dokumentationen für vSphere with Tanzu zugreifen.


Installation und Upgrades für diese Version

Weitere Anweisungen zum Installieren und Konfigurieren von vSphere with Tanzu finden Sie in der Dokumentation Installieren und Konfigurieren von vSphere with Tanzu. Informationen zum Aktualisieren von vSphere with Tanzu finden Sie in der Dokumentation Warten von vSphere with Tanzu.

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 with Tanzu Version 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 Verwenden von Tanzu Kubernetes Grid 2 mit vSphere with Tanzu.

Bekannte Probleme

Bekannte Probleme bei Supervisor

  • 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 with Tanzu 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

  • 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 with Tanzu 8.0.0a auf

    Aufgrund von Problemen mit Dienstkontoberechtigungen bleibt der tanzu-capabilities-controller-manager-Pod im Tanzu Kubernetes-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 eines v1.23.8-TKR in vSphere with Tanzu 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.

Netzwerk

  • 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 with Tanzu 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.

Speicher

  • 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