This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

Inhalt dieser Versionshinweise

Stand: 6. Juli 2023

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten am 6. Juli 2023

Build-Informationen am 6. Juli 2023

ESXi 7.0 Update 3m | 03 Mai 2023 | ISO-Build 21686933

vCenter Server 7.0 Update 3n | 06. Juli 2023 | ISO-Build 21958406

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

Neue Funktionen

  • Supervisor-Cluster unterstützen Kubernetes 1.24 – In dieser Version wird Kubernetes 1.24 neu unterstützt und die Unterstützung für Kubernetes 1.21 eingestellt.

Unterstützte Kubernetes-Versionen für Supervisor-Cluster:

Die unterstützten Versionen von Kubernetes in dieser Version sind 1.24, 1.23 und 1.22. Supervisoren, die auf Kubernetes in der Version 1.21 ausgeführt werden, werden automatisch auf Version 1.22 aktualisiert, um sicherzustellen, dass alle Supervisoren auf den unterstützten Versionen von Kubernetes ausgeführt werden.

Neuigkeiten am 30. März 2023

Build-Informationen am 30. März 2023

ESXi 7.0 Update 3l | 30. März 2023 | ISO-build 21424296

vCenter Server 7.0 Update 3l | 30. März 2023 | ISO-Build 21477706

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

Neue Funktionen:

  • Keine, es handelt sich hierbei lediglich um eine Version zur Fehlerkorrektur.

Unterstützte Kubernetes-Versionen für Supervisor-Cluster

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 einer unterstützten Version von Kubernetes ausgeführt werden.

Behobene Probleme

Mit diesem Patch werden folgende Fehler behoben.

  • Mit der Aktivierung von Large Receive Offload (LRO) können bei Tanzu Kubernetes Grid Cluster-VMs, die Antrea-ENCAP verwenden, zu Problemen mit der Netzwerkleistung auftreten.

  • Die Aktivierung der eingebetteten Harbor-Registrierung auf Supervisor kann zu einer unsicheren Standardkonfiguration führen.

Neuigkeiten am 23. Februar 2023

Build-Informationen am 23. Februar 2023

ESXi 7.0 Update 3i | 8. Dezember 2022 | ISO-Build 20842708

vCenter Server 7.0 Update 3k | 23. Februar 2023 | ISO-Build 21290409

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

Neue Funktionen:

Supervisor

  • Supervisor-Cluster 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 einer unterstützten Version von Kubernetes ausgeführt werden.

Neuigkeiten am 8. Dezember 2022

Build-Informationen vom 8. Dezember 2022

ESXi 7.0 Update 3i | 8. Dezember 2022 | ISO-Build 20842708

vCenter Server 7.0 Update 3i | 8. Dezember 2022 | ISO-Build 20845200

VMware NSX Advanced Load Balancer avi-21.1.4-9009 | 7. April 2022

Neue Funktionen:

Neue SecurityPolicy-CRD: vSphere 7.0 Update 3i führt eine SecurityPolicy-CRD ein, mit der Benutzer NSX-basierte Sicherheitsrichtlinien auf VMs und Pods im Supervisor anwenden können. Dies bietet die Möglichkeit, die „Kubernetes-Netzwerkrichtlinie“ über Code zu konfigurieren, indem die Kubernetes-Netzwerkrichtlinie über CRD für die Supervisor-Namespaces erweitert wird.

Support: Die in den kube-apiserver-authproxy-svc-Dienst- und -Systempods verwendete TLS-Version wurde auf TLSv1.2 aktualisiert.

Neuigkeiten am 13. September 2022

Build-Informationen am 13. September 2022

ESXi 7.0 Update 3g | 13. September 2022 | ISO-Build 20328353

vCenter Server 7.0 Update 3h | 13. September 2022 | ISO-Build 20395099

VMware NSX Advanced Load Balancer avi-20.1.7-9154 | 29. März 2022

Neue Funktionen

  • Keine, es handelt sich hierbei lediglich um eine Version zur Fehlerkorrektur.

Behobene Probleme:

Dieser Patch behebt das Problem mit dem vCenter Server-Upgrade auf Version 70u3f, das fehlschlug, weil der WCP-Dienst nach dem Upgrade nicht gestartet wurde. Der Fehler ist aufgetreten, wenn Sie versuch haben, ein Upgrade von vCenter Server mit aktivierten vSphere with Tanzu auf Versionen vor 70u3d durchzuführen. Versuche, vCenter Server von einer Version vor 70u3d auf vCenter Server 70u3d und dann auf vCenter Server 70u3f zu aktualisieren, schlugen fehl.

Weitere Informationen zu dem behobenen Problem finden Sie im Knowledgebase-Artikel 89010.

Neuigkeiten am 12. Juli 2022

Build-Informationen am 12. Juli 2022

ESXi 7.0 Update 3f | 12. Juli 2022 | ISO-Build 20036589

vCenter Server 7.0 Update 3f | 12. Juli 2022 | ISO-Build 20051473

VMware NSX Advanced Load Balancer avi-20.1.7-9154 | 29. März 2022

Neue Funktionen

  • Supervisor-Cluster

    • Unterstützung des Zeichenfolgenwerts der LoadBalancer-IP für VM-Dienst – Hiermit kann ein Benutzer einen Zeichenfolgenwert für den Wert „spec.LoadBalancerIP“ bereitstellen, der einen in NSX-T erstellten und getaggten Wert darstellt bzw. diesem entspricht.

    • Sichern und Wiederherstellen von VM-Dienst-VMs – VMware bietet jetzt Unterstützung für die Sicherung und Wiederherstellung auf VM-Dienst-VMs in lokalen vSphere- und VMware Cloud on AWS-Instanzen mithilfe eines umfassenden und vollständig dokumentierten Workflows, der Veeam und andere Sicherungsanbieter basierend auf vADP (vSphere Storage APIs for Data Protection) unterstützt und so eine umfassendere Datenschutzlösung und die allgemeine Verfügbarkeit des VM-Diensts auf VMware Cloud on AWS gewährleistet.

Neuigkeiten am 12. Mai 2022

Build-Informationen am 12. Mai 2022

ESXi 7.0 Update 3d | 29. März 2022 | ISO-Build 19482537

vCenter Server 7.0 Update 3e | 12. Mai 2022 | ISO-Build 19717403

VMware NSX Advanced Load Balancer 20.1.7-9154 | 29. März 2022

Neue Funktionen

  • Weitere Unterstützung für Netzwerksicherheitsrichtlinien für über den VM-Operator-Dienst bereitgestellte VMs: Sicherheitsrichtlinien auf NSX-T können über Sicherheitsgruppen basierend auf Tags erstellt werden. Es ist jetzt möglich, eine NSX-T-basierte Sicherheitsrichtlinie zu erstellen und auf VMs anzuwenden, die über einen VM-Operator basierend auf NSX-T-Tags bereitgestellt werden.

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

Überlegungen zum Upgrade

Wenn Sie ein Upgrade von vCenter Server von einer Version vor 7.0 Update 3c durchgeführt haben und sich Ihr Supervisor-Cluster auf Kubernetes 1.19.x befindet, wechseln die tkg-controller-manager-Pods in den Zustand CrashLoopBackOff, wodurch die Gast-Cluster nicht mehr verwaltet werden können. Es wird eine Fehlermeldung ähnlich der folgenden angezeigt:

Es wurde eine Panik beobachtet: Ungültige Arbeitsspeicheradresse oder Nullzeiger-Dereferenz

Problemumgehung: Weitere Informationen zu diesem Problem und dessen Behebung finden Sie im Knowledgebase-Artikel 88443.

Neuigkeiten am 29. März 2022

Build-Informationen am 29. März 2022

ESXi 7.0 Update 3d | 29. März 2022 | ISO-Build 19482537

vCenter Server 7.0 Update 3d | 29. März 2022 | ISO-Build 19480866

VMware NSX Advanced Load Balancer 20.1.7-9154 | 29. März 2022

Neue Funktionen

  • Keine, es handelt sich hierbei lediglich um eine Version zur Fehlerkorrektur.

Behobene Probleme

  • Spherelet-VIB-Installationen schlagen auf vTPM-Hosts fehl

    • Die Spherelet-VIB-Installation schlägt mit dem Fehler Kein vertrauenswürdiger Signaturgeber gefunden: selbstsigniertes Zertifikat auf einem vTPM-Host fehl.

  • vSphere Upgrade führt dazu, dass der Supervisor-Cluster instabil wird

    • Nach dem Upgrade von vSphere von 7.0 Update 1 auf 7.0 Update 2 wechselt der Supervisor-Cluster in einen Konfigurationszustand.

  • Die Aktivierung des Supervisor-Clusters kommt bei Verwendung von NSX-T Advanced Load Balancer zum Stillstand

    • Das Aktivieren des Supervisor-Clusters mit NSX-T Advanced Load Balancer kann dazu führen, dass die Konfiguration basierend auf der Standardauthentifizierungskonfiguration angehalten wird.

Neuigkeiten am 21. Oktober 2021

Build-Informationen am 21. Oktober 2021

ESXi 7.0 Update 3 | 27. Januar 2022 | ISO-Build 19193900

vCenter Server 7.0 Update 3a | 21. Oktober 2021 | ISO-Build 18778458

VMware NSX Advanced Load Balancer 20.1.7 | 21. Oktober 2021 | ISO-Build 18778458

WICHTIG: VMware hat ESXi 7.0 Update 3, 7.0 Update 3a und 7.0 Update 3b aufgrund eines Problems, das sich auf Upgrades auswirkt, am 19. November 2021 von allen Sites entfernt. Build 19193900 für ESXi 7.0 Update 3c ISO ersetzt Build 18644231. Weitere Informationen finden Sie in den Versionshinweisen zu VMware ESXi 7.0 Update 3c.

Neue Funktionen

  • Tanzu Kubernetes Grid Service for vSphere

    • Aktivieren Sie Containerarbeitslasten, um GPU-Beschleunigung auf Ihrem Tanzu Kubernetes-Cluster zu nutzen – vSphere-Administratoren können jetzt GPU-beschleunigte VMs für Tanzu Kubernetes-Cluster bereitstellen, und Entwickler können jetzt GPU-beschleunigte VMs zu ihren Tanzu Kubernetes Grid-Clustern mit nativen Kubernetes-Befehlen hinzufügen.

    • TKr (Tanzu Kubernetes release) basiert auf Ubuntu 20.04 – Hierbei handelt es sich um die erste TKr-Version, die auf Ubuntu 20.04 basiert. Dieses Image wurde speziell für GPU-Arbeitslasten (KI/ML) optimiert und getestet. Weitere Informationen finden Sie in den Versionshinweisen zu TKr.

Neuigkeiten am 5. Oktober 2021

Build-Informationen am 28. September 2021

ESXi 7.0 Update 3 | 27. Januar 2022 | ISO-Build 19193900

vCenter Server 7.0 Update 3 | 5. Oktober 2021 | ISO-Build 18700403

VMware NSX Advanced Load Balancer 20.1.6 | 5. Oktober 2021 | ISO-Build 18700403

WICHTIG: VMware hat ESXi 7.0 Update 3, 7.0 Update 3a und 7.0 Update 3b aufgrund eines Problems, das sich auf Upgrades auswirkt, am 19. November 2021 von allen Sites entfernt. Build 19193900 für ESXi 7.0 Update 3c ISO ersetzt Build 18644231. Weitere Informationen finden Sie in den Versionshinweisen zu VMware ESXi 7.0 Update 3c.

Neue Funktionen

  • Supervisor-Cluster

    • vSphere Services: Mithilfe des vSphere Services-Frameworks können vSphere-Administratoren Supervisor-Dienste jetzt asynchron verwalten, einschließlich MinIO, Cloudian Hyperstore, Dell ObjectScale und Velero. Da die Supervisor-Dienste entkoppelt sind, können Administratoren dem Dienstkatalog neue Dienste außerhalb einer vCenter Server-Version hinzufügen, wodurch die DevOps-Community noch stärker unterstützt wird. Supervisor-Dienste sind nur in Supervisor-Clustern verfügbar, die mit NSX-T Data Center-Netzwerken konfiguriert sind. Informationen zur Verwaltung von Supervisor-Diensten im vSphere Client finden Sie in der Dokumentation.

    • Unterstützung für vGPU im VM-Dienst: vSphere-Administratoren können Entwicklern jetzt Self-Service-Zugriff zur Nutzung von GPUs über VMs mithilfe von Kubernetes bereitstellen, wobei dies an die durch VM-Klassen erzwungenen Grenzwerte gebunden ist. DevOps-Benutzer können dann mithilfe dieser vordefinierten VM-Klassen und Images schnell VMs mit GPUs erstellen.

    • Aktivieren von Arbeitslastverwaltung mit DHCP-Netzwerk: In dieser Version wird das DHCP-Netzwerk als alternativer Netzwerkeinrichtungspfad hinzugefügt, um die Aktivierung für eine schnellere Machbarkeitsanalyse (Proof-of-Concept, POC) zu vereinfachen. vSphere-Administratoren können das Verwaltungsnetzwerk und das Arbeitslastnetzwerk mit DHCP konfigurieren, indem sie einfach das Netzwerk und die Portgruppe auswählen. Alle anderen Eingaben, einschließlich DNS, NTP und Floating IP, werden automatisch über DHCP abgerufen.

    • Integritätsprüfung von Netzwerk und Lastausgleichsdienst während der Aktivierung: Während der Aktivierung überprüfen Integritätsprüfungen für die Netzwerkkonnektivität, DNS, NTP und die Konnektivität des Lastausgleichsdiensts den Erfolg der Aktivierung Ihres Supervisor-Clusters und geben für den Benutzer lesbare Fehlermeldungen aus, um die Diagnose und Behebung häufig auftretender Probleme zu erleichtern. Weitere Informationen zum Beheben der in den Fehlermeldungen aufgeführten Probleme finden Sie in der Dokumentation.

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

    • Bezeichnungen und Anmerkungen zu Supervisor-Namespaces: Von DevOps-Benutzern über die Namespace-Self-Service-Vorlage erstellte Namespaces können jetzt Kubernetes-Bezeichnungen und -Anmerkungen aufweisen.

    • Bearbeiten der Supervisor-Clusterkonfiguration nach der Aktivierung: Nach dem Aktivieren von Supervisor-Clustern mit dem vSphere-Netzwerk-Stack können vSphere-Administratoren jetzt die folgenden Einstellungen sowohl über die API als auch über den vSphere Client bearbeiten: Benutzername und Kennwort für den Lastausgleichsdienst, DNS-Suchdomänen des Verwaltungsnetzwerks, DNS-Server des Arbeitslastnetzwerks, NTP-Server, Erweiterung des Dienst-IP-Bereichs und Hinzufügen eines neuen Arbeitslastnetzwerks. Für Cluster, die ein vSphere- oder ein NSX-T-Netzwerk verwenden, können Sie die Größe der Steuerungsebene nach der Aktivierung hochskalieren. Beachten Sie, dass Sie die Skalierung des Clusters nur erhöhen können. Eine Reduzierung der Skalierung wird derzeit nicht unterstützt. Informationen zum Ändern der Supervisor-Cluster-Einstellungen über den vSphere Client finden Sie in der Dokumentation.

    • Ablauf des Tanzu-Lizenzschlüssels: vSphere-Administratoren haben jetzt zusätzliche Flexibilität bei der Verwaltung abgelaufener Tanzu Edition-Lizenzschlüssel. Nach Ablauf von Tanzu-Lizenzschlüsseln kommt es nicht automatisch zu harten Erzwingungen, sodass die Administratoren einen neuen Lizenzschlüssel flexibler beschaffen und zuweisen können, ohne normale Vorgänge zu beeinträchtigen.

  • Tanzu Kubernetes Grid Service for vSphere

    • RWX-Unterstützung für persistente vSAN-Volumes: Arbeitslasten, die auf Tanzu Kubernetes-Clustern ausgeführt werden, können jetzt vSAN-basierte persistente Volumes mit RWX mounten.

    • API-Update v1alpha2 für den Tanzu Kubernetes Grid Service: Updates der Tanzu Kubernetes Cluster-API, mit denen neue Felder für eine erweiterte Konfiguration des Tanzu Kubernetes Grid Service bereitgestellt werden, einschließlich Unterstützung für mehrere Worker-Knotenpools. Einstellung der v1alpha1-API zugunsten der neuen v1alpha2-API. Weitere Informationen finden Sie in der Dokumentation.

    • Metrikserver: Metrikserver ist jetzt standardmäßig ab den Tanzu Kubernetes-Versionen 1.20.9+ und 1.21 in Tanzu Kubernetes-Clustern enthalten.

    • Möglichkeit der Unterstützung von (gerouteten) Nicht-NAT-Topologien: Tanzu Kubernetes-Cluster können jetzt mit einer Netzwerktopologie erstellt werden, die das Routen von Clusterknoten außerhalb des Clusternetzwerks zulässt. Weitere Informationen finden Sie in der Dokumentation.

Neuigkeiten am 24. August 2021

Build-Informationen am 24. August 2021

ESXi 7.0 Update 2c | 24. August 2021 | ISO-Build 18426014

vCenter Server 7.0 Update 2c | 24. August 2021 | ISO-Build 18356314

VMware NSX Advanced Load Balancer 20.1.5 | 24. August 2021 | ISO-Build 18379150

Neue Funktionen

  • Supervisor-Cluster

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

    • Velero-Plug-In für vSphere-Unterstützung für vSphere-Pods – Diese Version unterstützt Velero 1.5.1 und das Velero-Plug-In für vSphere 1.1.0 und höher für das Sichern und Wiederherstellen von vSphere-Pods.

  • Tanzu Kubernetes Grid Service for vSphere

    • Harbor und external-dns als neue In-Cluster-Erweiterungen – Plattformbetreiber haben jetzt Zugriff auf zwei zusätzliche unterstützte In-Cluster-Erweiterungen: Harbor und external-dns. Harbor ist die CNCF-kodierte Containerregistrierung, und external-dns ist ein beliebtes Tool für die dynamische Konfiguration von DNS-Datensätzen basierend auf Kubernetes-Diensten mit Lastausgleich.

    • Verbesserte Standardisierung von Steuerungsebenenknoten – Tanzu Kubernetes-Cluster standardisieren jetzt automatisch gemeinsame Knotenausfälle der Steuerungsebene, wodurch eine robustere Kubernetes-Laufzeit erreicht wird.

    • Velero-Plug-In für vSphere-Unterstützung für Tanzu Kubernetes-Clusterarbeitslasten – Diese Version bietet Unterstützung für Velero 1.5.1 und höher sowie das Velero-Plug-In für vSphere 1.1.0 und höher für das Sichern und Wiederherstellen von Arbeitslasten, die auf Tanzu Kubernetes-Clustern ausgeführt werden.

    • Eigenständige Velero-Unterstützung für Tanzu Kubernetes-Clusterarbeitslasten – Diese Version bietet Unterstützung für Velero 1.6 zum Sichern und Wiederherstellen von Tanzu Kubernetes-Clusterarbeitslasten mithilfe des eigenständigen Velero mit Restic.

Neuheiten 27. April 2021

Build-Informationen am 27. April 2021

ESXi 7.0 | 9. März 2021 | ISO-Build 17630552

vCenter Server 7.0 | 27. April 2021 | ISO-Build 17920168

Neue Funktionen

  • Supervisor-Cluster

    • Verwalten von VMs mithilfe von Kubernetes über den Dienst der virtuellen Maschine. In dieser Version wird der Dienst der virtuellen Maschine zu den Infrastrukturdiensten in vSphere with Tanzu hinzugefügt, die Kubernetes-natives VM-Management für Entwickler bereitstellen. Mithilfe des VM-Diensts können Entwickler VMs in einem Namespace mithilfe von Kubernetes-Befehlen bereitstellen und verwalten. Gleichzeitig ist der vSphere-Administrator in der Lage, den Ressourcenverbrauch und die Verfügbarkeit des Diensts zu steuern, während Entwickler gleichzeitig eine cloudnative Erfahrung erhalten.

    • Self-Service-Erstellung von Namespaces für Entwickler. vSphere-Administratoren können jetzt einen Supervisor-Namespace als Self-Service-Namespace-Vorlage erstellen und konfigurieren. Diese Vorlage definiert Ressourcengrenzwerte und Berechtigungen für die Nutzung. Entwickler können diese Vorlage dann verwenden, um einen Namespace zur Verfügung zu stellen und Arbeitslasten innerhalb dieses Namespaces auszuführen, ohne einen anfordern und auf die Genehmigung warten zu müssen.

  • Tanzu Kubernetes Grid Service for vSphere

    • WICHTIGER HINWEIS: CVE-Fix für TKRs: Es stehen neue Tanzu Kubernetes-Versionen zur Verfügung, die CVE-2021-30465 beheben.

    • WICHTIGER HINWEIS: CVE-Fix für die Contour-Ingress-Erweiterung: Es gibt eine neue Envoy-Image-Version, die CVE-2021-28682, CVE-2021-28683 und CVE-2021-29258 behebt. Weitere Informationen finden Sie im zugehörigen KB-Artikel.

    • Neuer Workflow für die Verwendung von Standard-VM-Klassen. Es gibt einen neuen Workflow für die Verwendung der VM-Standardklassen zur Bereitstellung von Tanzu Kubernetes-Clustern. Fügen Sie vor dem Erstellen eines neuen Clusters die VM-Standardklassen dem vSphere Namespace hinzu, in dem Sie den Cluster bereitstellen. Weitere Informationen finden Sie in der Dokumentation.

    • Systemmutierende Webhooks unterstützen jetzt den Testlaufmodus. Benutzer können jetzt beliebte Tools wie den Terraform Kubernetes-Anbieter in den Tanzu Kubernetes Grid Service integrieren. Bisher unterstützten die Systemwebhooks den Testlaufmodus nicht, was eine Anforderung für den Terraform-Befehl „plan“ war.

    • Benutzerdefinierte VM-Klassen. Tanzu Kubernetes-Cluster können die benutzerdefinierten VM-Klassen über den VM-Dienst nutzen. Auf diese Weise können Benutzer verschiedene Mengen an CPU und Arbeitsspeicher konfigurieren, die den virtuellen Maschinen eines Tanzu Kubernetes-Clusters zugeteilt sind.

Neuigkeiten am 9. März 2021

Build-Informationen am 9. März 2021

ESXi 7.0 | 9. März 2020 | ISO-Build 17630552

vCenter Server 7.0 | 9. März 2021 | ISO-Build 17694817

VMware NSX Advanced Load Balancer | 12. Oktober 2020 | 20.1.X

Neue Funktionen

  • Supervisor-Cluster

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

    • Upgrade des Supervisor-Clusters auf Kubernetes 1.19 mit automatischer Aktualisierung eines Supervisor-Clusters, auf dem Kubernetes 1.16 ausgeführt wird. Sie können ein Upgrade des Supervisor-Clusters auf Kubernetes 1.19 durchführen. Mit diesem Update werden die folgenden Supervisor-Clusterversionen unterstützt: 1.19, 1.18 und 1.17. Für Supervisor-Cluster, auf denen Kubernetes 1.16 ausgeführt wird, wird automatisch ein Upgrade auf Version 1.17 durchgeführt, sobald vCenter Server aktualisiert wird. Dadurch wird sichergestellt, dass alle Supervisor-Cluster mit der unterstützten Kubernetes-Version ausgeführt werden.

    • Erweiterung von PersistentVolumeClaims (PVCs). Sie können jetzt vorhandene Volumes erweitern, indem Sie das PersistentVolumeClaim-Objekt ändern, selbst wenn das Volume aktiv verwendet wird. Dies gilt für Volumes im Supervisor-Cluster und in Tanzu Kubernetes-Clustern.

    • Verwaltung des Supervisor-Clusterlebenszyklus mit vSphere Lifecycle Manager. Für Supervisor-Cluster, die mit einem NSX-T-Netzwerk konfiguriert sind, können Sie vSphere Lifecycle Manager für die Infrastrukturkonfiguration und Lebenszyklusverwaltung verwenden.

  • Tanzu Kubernetes Grid Service for vSphere

    • Unterstützung für private Containerregistrierungen. vSphere-Administratoren und Kubernetes-Plattformbetreiber können jetzt zusätzliche Zertifikate von Zertifizierungsstellen (CAs) definieren, die in Tanzu Kubernetes-Clustern für die Vertrauensstellung privater Containerregistrierungen verwendet werden. Mit dieser Funktion können Tanzu Kubernetes-Cluster Container-Images aus Containerregistrierungen mit Unternehmenszertifikaten oder selbstsignierten Zertifikaten abrufen. Sie können private CAs als Standard für Tanzu Kubernetes-Cluster Supervisor-Cluster-weit oder pro Tanzu Kubernetes-Cluster konfigurieren. Weitere Informationen zum Konfigurieren der Unterstützung für private Containerregistrierungen für Tanzu Kubernetes-Cluster finden Sie auf der Dokumentationsseite.

    • Benutzerdefinierte IPs für Diensttyp: LoadBalancer mit NSX-T und NSX Advanced Load Balancer. Kubernetes-Anwendungsoperatoren können jetzt eine benutzerdefinierte LoadBalancerIP bereitstellen, wenn sie einen Diensttyp konfigurieren: LoadBalancer für einen statischen IP-Endpoint für den Dienst. Diese erweiterte Funktion erfordert entweder NSX-T-Lastausgleich oder den NSX Advanced Load Balancer mit dem Supervisor-Cluster. Wie Sie diese Funktion konfigurieren, erfahren Sie auf der Dokumentationsseite.

    • ExternalTrafficPolicy und LoadBalancerSourceRanges für Diensttyp: LoadBalancer mit NSX-T – Kubernetes-Anwendungsoperatoren können jetzt die ExternalTrafficPolicy „local“ für Dienste konfigurieren, um die Client-IP-Adresse an die Endpods weiterzugeben. Sie können auch loadBalancerSourceRanges für Dienste definieren, um einzuschränken, welche Client-IPs auf den Dienst, für den ein Lastausgleich durchgeführt wurde, zugreifen können. Diese beiden erweiterten Funktionen erfordern einen NSX-T-Lastausgleich mit dem Supervisor-Cluster.

    • Kubernetes-Versionsverwaltung und Indications. Sie können „kubectl“ jetzt verwenden, um die Kompatibilität von TanzuKubernetesReleases mit der zugrunde liegenden Supervisor-Clusterumgebung zu überprüfen. Tanzu Kubernetes-Cluster geben jetzt auch an, ob ein Kubernetes-Upgrade verfügbar ist, und empfehlen die nächste(n) TanzuKubernetesRelease(s). Weitere Informationen zur Verwendung dieser neuen Funktion finden Sie auf der Dokumentationsseite .

    • Verbesserter Clusterstatus auf einen Blick. In einer vorherigen Version wurden die WCPCluster- und WCPMachine-CRDs von VMware erweitert, indem bedingte Statusberichte zur Aufarbeitung häufiger Probleme und Fehler bereitgestellt wurden. Mit vSphere Version 7.0 Update 2 haben wir die TanzuKubernetesCluster-CRDs verbessert, um die Berichterstattung über den bedingten Status für Subsystemkomponenten zusammenzufassen, und bieten Ihnen sofortige Antworten und eine fein abgrenzende Anleitung, die Ihnen bei der Untersuchung von Problemen hilft. Wie Sie diese Funktion konfigurieren, erfahren Sie auf der Dokumentationsseite.

    • HTTP-Proxy-Konfiguration pro Tanzu Kubernetes-Cluster. Sie können jetzt die HTTP/HTTPS-Proxy-Konfiguration pro Tanzu Kubernetes-Cluster oder alternativ über eine Standardkonfiguration für den gesamten Supervisor-Cluster definieren. Informationen zum Konfigurieren dieser Funktion finden Sie auf der Dokumentationsseite.

    • Unterstützung für Tanzu Kubernetes Grid Extensions. In-Cluster-Erweiterungen werden jetzt für den Tanzu Kubernetes Grid Service vollständig unterstützt. Dazu gehören Fluent Bit, Contour, Prometheus, AlertManager und Grafana.

Aktualisierungsüberlegungen für Tanzu Kubernetes-Cluster

Die Version vSphere 7.0 Update 2 enthält Funktionalität, mit der automatisch ein Supervisor-Cluster-Upgrade ausgeführt wird, wenn vCenter Server aktualisiert wird. Wenn in Ihrer Umgebung Tanzu Kubernetes-Cluster bereitgestellt wurden, lesen Sie Knowledgebase-Artikel 82592, bevor Sie ein Upgrade auf vCenter Server 7.0 Update 2 ausführen. Der Artikel enthält Anleitungen zum Ausführen einer Vorabprüfung, um zu ermitteln, ob ein Tanzu Kubernetes-Cluster nach dem automatischen Upgrade des Supervisor-Clusters inkompatibel wird.

Behobene Probleme

  • Das SSL-Zertifikat der eingebetteten Containerregistrierung wird nicht an Tanzu Kubernetes-Clusterknoten kopiert

    • Wenn die eingebettete Containerregistrierung für einen Supervisor-Cluster aktiviert ist, wird das Harbor-SSL-Zertifikat in keinem der auf diesem SC erstellten Tanzu Kubernetes-Clusterknoten eingeschlossen, und Sie können keine Verbindung zur Registrierung über diese Knoten herstellen.

  • Nach dem Upgrade von Tanzu Kubernetes Grid 1.16.8 auf 1.17.4 bleibt der Pod „guest-cluster-auth-svc“ auf einem der Knoten der Steuerungsebene im Zustand „Container-Erstellung“

    • Nach dem Upgrade eines Tanzu Kubernetes-Clusters von Tanzu Kubernetes Grid Service 1.16.8 auf 1.17.4 bleibt der Pod „guest-cluster-auth-svc“ auf einem der Steuerungsebenenknoten des Clusters im Zustand „Container-Erstellung“.

  • Der Benutzer kann während oder nach dem Durchführen eines Cluster-Updates vorhandene Pods in einem Tanzu Kubernetes-Cluster nicht verwalten

    • Der Benutzer kann während oder nach dem Durchführen eines Cluster-Updates vorhandene Pods in einem Tanzu Kubernetes-Cluster nicht verwalten.

  • Der Upgradeauftrag des Tanzu Kubernetes Clusters schlägt mit einer Meldung ähnlich der folgenden fehl: „Zeitüberschreitung beim Warten darauf, dass die etcd-Integritätsprüfung erfolgreich abgeschlossen wird“

    • Der Upgradeauftrag im Namespace „vmware-system-tkg“, der dem Upgrade eines Tanzu Kubernetes-Clusters zugeordnet ist, schlägt mit der folgenden Fehlermeldung fehl: „Zeitüberschreitung beim Warten darauf, dass die etcd-Integritätsprüfung erfolgreich abgeschlossen wird“. Das Problem wird durch die fehlenden PodIP-Adressen für die etcd-Pods verursacht.

  • Antrea-CNI wird in der aktuellen TKC-Version nicht unterstützt

    • Bei der Bereitstellung eines Tanzu Kubernetes-Clusters erhalten Sie die Fehlermeldung „Antrea-CNI wird in der aktuellen TKC-Version nicht unterstützt“.

      Option 1 (empfohlen): Führen Sie ein Update des Tanzu Kubernetes-Clusters durch, um die OVA-Version zu verwenden, die Antrea unterstützt (v1.17.8 oder höher).

      Option 2: Geben Sie in der YAML-Datei für die Tanzu Kubernetes-Clusterspezifikation im Abschnitt spec.settings.network.cni „calico“ ein.

      Option 3: Ändern Sie die standardmäßige CNI in „Calico“. Weitere Informationen hierzu finden Sie unter dem entsprechenden Thema in der Dokumentation.

Neuigkeiten am 2. Februar 2021

Build-Informationen am 2. Februar 2021

ESXi 7.0 | 17. Dezember 2020 | ISO-Build 17325551

vCenter Server 7.0 | 2. Februar 2021 | ISO-Build 17491101

Neue Funktionen

  • Supervisor-Cluster

    • Update von Supervisor-Clustern mit vSphere-Netzwerk: Sie können nun Supervisor-Cluster, die ein vSphere-Netzwerk verwenden, von einer älteren Kubernetes-Version auf die neueste verfügbare Version aktualisieren. In neuen Supervisor-Clusterversionen stehen auch aktuelle Tanzu Kubernetes Grid-Dienstfunktionen zur Verfügung.

Behobene Probleme

  • Neue Tanzu Kubernetes Grid-Dienstfunktionen waren in vorhandenen Supervisoren mit vSphere-Netzwerk nicht verfügbar

    • In der vorherigen Version waren neue Tanzu Kubernetes Grid-Dienstfunktionen und Fehlerkorrekturen nur in neu erstellten Supervisor-Clustern verfügbar, wenn ein vSphere-Netzwerk verwendet wurde. In dieser Version können Benutzer nun Supervisor-Cluster mit einem vSphere-Netzwerk aktualisieren, um die Vorteile der neuesten Tanzu Kubernetes Grid-Dienstfunktionen und Fehlerkorrekturen zu nutzen.

Neuigkeiten am 17. Dezember 2020

Build-Informationen am 17. Dezember 2020

ESXi 7.0 | 17. Dezember 2020 | ISO-Build 17325551

vCenter Server 7.0 | 17. Dezember 2020 | ISO-Build 17327517

Hinweis: Um die neuen Funktionen und Bugfixes von Tanzu Kubernetes Grid Service in dieser Version nutzen zu können, müssen Sie einen neuen Supervisor-Cluster erstellen, wenn vSphere-Netzwerke verwendet werden.

Neue Funktionen

  • Supervisor-Cluster

    • Supervisor-Namespace-Isolierung mit dediziertem T1-Router. Supervisor-Cluster mit NSX-T-Netzwerk verwenden eine neue Topologie, wobei jeder Namespace über einen eigenen dedizierten T1-Router verfügt.

      • Neu erstellte Supervisor-Cluster verwenden diese neue Topologie automatisch.

      • Vorhandene Supervisor-Cluster werden während eines Upgrades auf diese neue Topologie migriert.

    • Supervisor-Cluster unterstützen NSX-T 3.1.0. Supervisor-Cluster ist kompatibel mit NSX-T 3.1.0.

    • Unterstützung für Supervisor-Cluster Version 1.16.x aufgehoben. Supervisor-Cluster Version 1.16.x wurde jetzt entfernt. Supervisor-Cluster, auf denen 1.16.x ausgeführt wird, sollten auf eine neue Version aktualisiert werden.

  • Tanzu Kubernetes Grid Service for vSphere

    • HTTP/HTTPS-Proxyunterstützung. Neu erstellte Tanzu Kubernetes-Cluster können einen globalen HTTP/HTTPS-Proxy für den Egress-Datenverkehr sowie zum Abrufen von Containerimages aus Internetregistrierungen verwenden.

    • Integration in Registrierungsdienst. Neu erstellte Tanzu Kubernetes-Cluster sind mit dem vSphere-Registrierungsdienst sofort einsatzbereit. Vorhandene Cluster, die auf eine neue Version aktualisiert wurden, können auch mit dem Registrierungsdienst verwendet werden.

    • Konfigurierbarer Knotenspeicher. Mit Tanzu Kubernetes-Clustern kann jetzt ein zusätzliches Speichervolume auf virtuellen Maschinen bereitgestellt werden, wodurch die verfügbare Knotenspeicherkapazität erhöht wird. Dadurch können Benutzer größere Container-Images bereitstellen, die die standardmäßige Root-Volume-Größe von 16 GB überschreiten können.

    • Verbesserte Statusinformationen. Benutzerdefinierte WCPCluster- und WCPMachine-Ressourcendefinitionen implementieren jetzt Berichte über bedingten Status. ErfolgreicheLebenszyklusverwaltung von Tanzu Kubernetes-Clustern hängt von einer Reihe von Subsystemen ab (z. B. Supervisor, Speicher, Netzwerk), und das Verstehen von Fehlern kann eine Herausforderung darstellen. Jetzt zeigen WCPCluster- und WCPMachine-CRDs häufige Status- und Fehlerbedingungen an, um die Fehlerbehebung zu erleichtern.

Behobene Probleme

  • Es fehlen neue Standard-VM-Klassen, die in vCenter Server 7.0 Update 1 eingeführt wurden

    • Nach dem Upgrade auf vSphere 7.0.1 und der anschließenden Aktualisierung von vSphere-Namespaces des Supervisor-Clusters wurden beim Ausführen des Befehls "kubectl get virtualmachineclasses" die neuen VM-Klassengrößen „2x-large“, „4x-large“ und „8x-large“ nicht aufgeführt. Dieses Problem wurde behoben, und alle Supervisor-Cluster werden mit dem korrekten Satz an Standard-VM-Klassen konfiguriert.

Neuigkeiten am 6. Oktober 2020

Build-Informationen am 6. Oktober 2020

ESXi 7.0 | 6. Oktober 2020 | ISO-Build 16850804

vCenter Server 7.0 | 06. Oktober 2020 | ISO-Build 16860138

Neue Funktionen

  • Supervisor-Cluster

    • Konfiguration von Supervisor-Clustern mit vSphere-Netzwerk. Wir haben vSphere für Supervisor-Cluster eingeführt, wodurch Sie eine entwicklerbereite Plattform unter Verwendung Ihrer vorhandenen Netzwerkinfrastruktur zur Verfügung stellen können.

    • Unterstützung des HAproxy-Load Balancers zum Einrichten von Supervisor-Clustern mit vSphere-Netzwerk. Wenn Sie Supervisor-Cluster mit vSphere-Netzwerk konfigurieren, müssen Sie einen Load Balancer hinzufügen, um Ihre modernen Arbeitslasten zu verarbeiten. Sie können Ihren Lastausgleichsdienst mit einer HAproxy-OVA bereitstellen und einrichten.

    • Verwaltung des Supervisor-Clusterlebenszyklus mit vSphere Lifecycle Manager. Für Supervisor-Cluster, die mit vSphere-Netzwerk konfiguriert sind, können Sie vSphere Lifecycle Manager für die Infrastrukturkonfiguration und Lebenszyklusverwaltung verwenden.

    • Möglichkeit, vSphere with Tanzu mit Ihrer Hardware zu testen. Wir bieten jetzt eine in das Produkt integrierte Testversion an, wenn Sie einen Supervisor-Cluster auf Ihrer Hardware aktivieren und diese moderne Anwendungsplattform ohne zusätzliche Kosten testen möchten.

  • Tanzu Kubernetes Grid Service for vSphere

    • Verfügbarmachen von Kubernetes-Versionen für DevOps-Benutzer. Wir haben die neue benutzerdefinierte Ressourcendefinition „TanzuKubernetesRelease“ im Supervisor-Cluster eingeführt. Diese benutzerdefinierte Ressourcendefinition liefert DevOps-Benutzern detaillierte Informationen zu den Kubernetes-Versionen, die sie in ihren Tanzu Kubernetes-Clustern verwenden können.

    • Integration vom VMware Container Networking mit Antrea für Kubernetes. Wir haben eine kommerziell unterstützte Version von Antrea als standardmäßiges Container Network Interface (CNI) für neue Tanzu Kubernetes-Cluster integriert. Antrea bietet eine umfassende Suite an Richtlinienfunktionen für Unternehmensnetzwerke zum Tanzu Kubernetes Grid-Dienst. Weitere Informationen finden Sie in der Versionsankündigung. Antrea ist zwar die Standard-CNI, vSphere-Administratoren und DevOps-Benutzer können jedoch weiterhin Calico als CNI für Tanzu Kubernetes-Cluster auswählen.

    • Unterstützung von Supervisor-Clusterumgebungen mit vSphere-Netzwerk. Wir unterstützen jetzt Supervisor-Clusterumgebungen mit vSphere-Netzwerk, damit Sie Ihre vorhandene Netzwerkinfrastruktur nutzen können.

Behobene Probleme

  • Keine Auflistung. Dies ist ein Featurerelease.

Neuigkeiten am 25. August 2020

Build-Informationen am 25. August 2020

ESXi 7.0 | 23. Juni 2020 | ISO-Build 16324942

vCenter Server 7.0 | 25. August 2020 | ISO-Build 16749653

Neue Funktionen

  • Keine, es handelt sich hierbei lediglich um eine Version zur Fehlerkorrektur.

Behobene Probleme

  • Hohe CPU-Nutzung nach dem Upgrade auf den Patch vom 30. Juli

    • vCenter Server generiert eine hohe CPU-Nutzung nach dem Upgrade auf den Patch vom 30. Juli. Dieses Problem ist nun behoben.

  • Aktivierungsfehler bei Supervisor-Cluster aufgrund eines Zertifikats mit Windows-Zeilenenden

    • Die Aktivierung eines Supervisor-Clusters kann fehlschlagen, wenn im Zertifikat Windows-Zeilenenden enthalten sind. Dieses Problem ist nun behoben.

Neuigkeiten am 30. Juli 2020

Build-Informationen am 30. Juli 2020

ESXi 7.0 | 23. Juni 2020 | ISO-Build 16324942

vCenter Server 7.0 | 30. Juli 2020 | ISO-Build 16620007

Neue Funktionen

  • Supervisor-Cluster: neue Version von Kubernetes, Support für benutzerdefinierte Zertifikate und PNID-Änderungen

    • Supervisor-Cluster unterstützt jetzt Kubernetes 1.18.2 (zusammen mit 1.16.7 und 1.17.4)

    • Das Ersetzen von Maschinen-SSL-Zertifikaten durch benutzerdefinierte Zertifikate wird jetzt unterstützt

    • vCenter-PNID-Update wird jetzt unterstützt, wenn Supervisor-Cluster im vCenter Server vorhanden sind

  • Tanzu Kubernetes Grid Service for vSphere: neue Funktionen für das horizontale Herunterskalieren von Clustern sowie für Netzwerk und Speicher hinzugefügt

    • Das horizontale Herunterskalieren von Clustern wird jetzt für Tanzu Kubernetes Grid-Dienstcluster unterstützt.

    • Ingress-Firewallregeln werden jetzt standardmäßig für alle Tanzu Kubernetes Grid-Dienstclustern erzwungen

    • Neue Versionen von Kubernetes werden regelmäßig asynchron zu vSphere-Patches ausgeliefert, aktuelle Versionen sind 1.16.8, 1.16.12, 1.17.7, 1.17.8

  • Netzwerkdienst: neue Version von NCP

    • SessionAffinity wird jetzt für ClusterIP-Dienste unterstützt

    • IngressClass, PathType und Platzhalterdomäne werden für Ingress in Kubernetes 1.18 unterstützt

    • Clientauthentifizierung wird jetzt in Ingress-Controller unterstützt

  • Registrierungsdienst: neue Version von Harbor

    • Der Registrierungsdienst wurde jetzt auf 1.10.3 aktualisiert

Weitere Informationen und Anweisungen zum Durchführen von Upgrades finden Sie in der Dokumentation Aktualisieren von vSphere with Tanzu-Clustern.

Behobene Probleme

  • NTP-Synchronisierungsproblem bei Tanzu Kubernetes Grid-Dienstcluster

Neuigkeiten am 23. Juni 2020

23. Juni 2020 Build-Informationen

ESXi 7.0 | 23. Juni 2020 | ISO-Build 16324942

vCenter Server 7.0 | 23. Juni 2020 | ISO-Build 16386292

OVA für Tanzu Kubernetes-Cluster: v1.16.8+vmware.1-tkg.3.60d2ffd

Neue Funktionen

  • Keine, es handelt sich hierbei lediglich um eine Version zur Fehlerkorrektur.

Behobene Probleme

  • Fehler beim Upgrade des Tanzu Kubernetes Grid-Dienstclusters

    • Wir haben ein Problem behoben, bei dem das Upgrade eines Tanzu Kubernetes Grid-Dienstclusters aufgrund von „Fehler: Unbekannter vorheriger Knoten“ fehlschlagen konnte

  • Fehler beim Upgrade des Supervisor-Clusters

    • Wir haben ein Problem behoben, bei dem ein Update des Supervisor-Clusters möglicherweise hängen bleibt, wenn sich der eingebettete Harbor im Status „Fehlgeschlagen“ befindet

Neuigkeiten am 19. Mai 2020

Build-Informationen am 19. Mai 2020

ESXi 7.0 | 2. April 2020 | ISO-Build 15843807

vCenter Server 7.0 | 19. Mai 2020 | ISO-Build 16189094

OVA für Tanzu Kubernetes-Cluster: v1.16.8+vmware.1-tkg.3.60d2ffd

Neue Funktionen

  • Tanzu Kubernetes Grid Service for vSphere: Paralleles Upgrade und Dienst-Upgrade

    • Kunden können jetzt über ihre Worker-Knoten und Steuerungsebene hinweg parallele Upgrades für den Tanzu Kubernetes Grid Service for vSphere und Upgrades der Dienste pvCSI, Calico und authsvc durchführen. Dies umfasst Vorabprüfungen und Upgrade-Kompatibilität für diese Dienstmatrix.

    • Mit parallelen Upgrades können die Worker-Knoten vertikal skaliert werden, d. h. Sie können die VM-Klasse Ihrer Worker-Knoten in eine kleinere oder größere Größe ändern.

  • Supervisor-Cluster: Neue Versionen von Kubernetes, Upgrade wird unterstützt

    • Der Supervisor-Cluster unterstützt jetzt Kubernetes 1.17.4

    • Der Supervisor-Cluster unterstützt jetzt Upgrades von Kubernetes 1.16.x auf 1.17.x

Behobene Probleme

  • Namenskonflikt bei gelöschten Namespaces

    • Wir haben ein Problem behoben, bei dem ein Namenskonflikt auftrat, wenn ein Benutzer einen vSphere-Namespace löschte und dann einen neuen vSphere-Namespace mit demselben Namen erstellte. Dieser Namenskonflikt führte dazu, dass keine Tanzu Kubernetes-Cluster erstellt werden konnten.

  • Verbesserte Namen für Verteilungen

    • Es ist nun klarer ersichtlich, welche Version von Kubernetes Sie ausführen, da die OVF-Versionsinformationen in eine separate Spalte verschoben wurden.

Build-Informationen für die anfängliche vSphere with Kubernetes-Version

Build-Informationen am 2. April 2020

ESXi 7.0 | 2. April 2020 | ISO-Build 15843807

vCenter Server 7.0 | 2. April 2020 | ISO-Build 15952498

OVA für Tanzu Kubernetes-Cluster: v1.16.8+vmware.1-tkg.3.60d2ffd

Weitere Informationen zu vSphere with Tanzu

VMware bietet eine Reihe von Ressourcen, die Sie nutzen können, um mehr über vSphere with Tanzu zu erfahren.

  • Erfahren Sie, wie Sie vSphere with Tanzu konfigurieren, verwalten und verwenden, indem Sie das Dokument Konfiguration und Verwaltung von vSphere with Tanzu lesen. Dieses Handbuch wurde für vSphere-Systemadministratoren und DevOps-Teams entwickelt und enthält Details zu Architektur, Diensten, Lizenzierung, Systemanforderungen, Einrichtung und Verwendung von vSphere with Tanzu.

  • In den VMware-Kompatibilitätshandbüchern erhalten Sie Informationen zur Hardwarekompatibilität und Produktinteroperabilität für vSphere with Tanzu. Für vSphere with Tanzu gelten dieselben Hardwareanforderungen wie für vSphere 7.0. Für bestimmte Konfigurationen erfordert es auch die Verwendung von virtuellen Maschinen mit NSX-T Edge, und für diese VMs gilt ein eigener untergeordneter Satz an CPU-Kompatibilität. Weitere Informationen finden Sie im NSX-T Data Center-Installationshandbuch.

  • Erfahren Sie im Abschnitt Internationalisierung der Versionshinweise zu vSphere 7.0, in welchen Sprachen vSphere with Tanzu verfügbar ist. Dies sind dieselben Sprachen, die VMware für vSphere bereitstellt.

  • Im Abschnitt Open Source der Versionshinweise zu vSphere 7.0 können Sie die Copyright-Hinweise und die Lizenzen für Open Source-Komponenten in vSphere with Tanzu einsehen. In den Versionshinweisen zu vSphere 7.0 erfahren Sie auch, wo Sie Open Source-Komponenten von vSphere herunterladen können.

Behobene Probleme

  • Die Karte „VM-Dienst“ auf der Seite „Namespace-Übersicht“ wird nach einem vCenter-Upgrade auf vCenter Server 7.0 Update 2c nicht mehr angezeigt

    Nach einem vCenter-Upgrade von vCenter Server 7.0 Update 2a auf vCenter Server 7.0 Update 2c zeigen bereits vorhandene Namespaces, die vor dem Upgrade erstellt wurden, die Karte „VM-Klassen- und Inhaltsbibliotheken“ in der Ansicht „Namespace-Übersicht“ nicht an. Dies gilt speziell für vCenter Server 7.0 Update 2a als Ausgangsversion und sollte sich nicht auf Upgrades von früheren Versionen wie vCenter Server 7.0 Update 2 auswirken.

    Für die betroffenen Namespaces sollten durch das Upgrade des Supervisor-Clusters die Karten in der Ansicht „Namespace-Übersicht“ wiederhergestellt werden

  • Bestimmte Vorgänge auf virtuellen Maschinen, die mit dem VM-Dienst erstellt wurden, können aufgrund einer nicht kompatiblen Hardwareversion der virtuellen Maschine fehlschlagen

    Vorgänge auf virtuellen Maschinen schlagen fehl, wenn die Hardwareversion der virtuellen Maschine des OVF-Images den Vorgang nicht unterstützt. Beispiel: Für ein Image mit der virtuellen Hardwareversion „vmx-11“ scheitert das Anhängen eines persistenten Volumes mit der folgenden Fehlermeldung:

    Attach a virtual disk: The device or operation specified at index '-1' is not supported for the current virtual machine version 'vmx-11'. A minimum version of 'vmx-13' is required for this operation to succeed

    Problemumgehung: Keine

  • Während des Upgrades des Supervisor-Clusters werden möglicherweise vSphere-Pods erstellt und bleiben im Status „Ausstehend“, wenn das Daemon-Set verwendet wird.

    Während des Upgrades des Supervisor-Clusters erstellt der Daemon-Set-Controller zusätzliche vSphere-Pods für jeden Supervisor-Steuerungsebenenknoten. Dies wird durch ein vorgelagertes Kubernetes-Problem verursacht.

    Problemumgehung: Fügen Sie NodeSelector/NodeAffinity zur vSphere-Pod-Spezifikation hinzu, damit der Daemon-Set-Controller die Steuerungsebenenknoten für die Erstellung von Pods überspringen kann.

  • Pod-Erstellung schlägt zeitweise fehl:

    In einigen Umgebungen wurde die Pod-Erstellung zeitweise mit dem folgenden Fehler gemeldet: „'Image konnte nicht abgerufen werden'. Zeitüberschreitung mit einem 'Keine Route zum Host'-Fehler.“ Die Ursache ist eine standardmäßige 3-Sekunden-Zeitüberschreitung während der Image-Abrufanforderung.

    Wenden Sie sich an GSS, um den Standardwert für die Zeitüberschreitung zu erhöhen.

  • Der Supervisor-Dienst kann abstürzen, wenn VC über eine große Anzahl von getrennten Hosts verfügt:

    In Umgebungen, in denen viele Hosts aufgrund eines falschen Benutzernamens und Kennworts getrennt sind, ist der Supervisor-Dienst möglicherweise abgestürzt und konnte nicht erneut gestartet werden.

    Dieses Problem wurde in der aktuellen Version behoben.

  • Das Konfigurieren eines Supervisor-Clusters mit NSX-T Data Center schlägt unter Umständen auf vCenter Server 7.0 Update 3 fehl

    Beim Konfigurieren eines Supervisor-Clusters mit NSX-T Data Center kann das Spherelet-VIB möglicherweise nicht auf ESXi-Hosts installiert werden. Folgende Fehlermeldung wird angezeigt:

    Could not find a trusted signer: self signed certificate

    Ein selbstsigniertes Spherelet-VIB befindet sich im Lieferumfang von vCenter Server 7.0 Update 3. Wenn Secure Boot jedoch nicht auf dem ESXi-Host aktiviert ist, der Teil des vSphere-Clusters ist, oder vSphere Life Cycle Manager (vLCM) für die Hosts im Cluster nicht aktiviert ist, verläuft der Aktivierungsvorgang für den Supervisor-Cluster erfolgreich. Dieses Problem wurde in der aktuellen Version behoben.

  • Das vCenter-Upgrade auf 70u3f ist nicht erfolgreich, da der WCP-Dienst nicht gestartet wurde

    Weitere Informationen hierzu finden Sie im Knowledgebase-Artikel 89010.

    Diese Problemumgehung kann entweder bei vCenter Server 7.0u3f selbst angewendet werden, welcher den Fehlerzustand aufweist, oder bei vCenter Server 7.0u3d, der die Version vor dem Upgrade auf 7.0u3f aufweist.

    1. Stellen Sie mit root-Anmeldedaten eine Verbindung zur vCenter Server SSH-Sitzung her.

    2. Stellen Sie mithilfe des folgenden Befehls eine Verbindung zur WCP-Datenbank her:

    PGPASSFILE=/etc/vmware/wcp/.pgpass /opt/vmware/vpostgres/current/bin/psql -d VCDB -U wcpuser -h localhost

    3. Führen Sie den folgenden Befehl aus, um die Einträge zu prüfen, bei den instance_id gleich null ist:

    SELECT cluster, instance_id FROM cluster_db_configs WHERE instance_id is NULL;

    4. Aktualisieren Sie die instance_id in cluster_db_configs auf eine zufällige UUID, wobei sie null ist:

    UPDATE cluster_db_configs SET instance_id=gen_random_uuid() WHERE instance_id is NULL;

    5. Der WCP-Dienst (und alle anderen Dienste, die nach dem Upgrade noch nicht gestartet wurden) müssen neu gestartet werden, nachdem der DB-Eintrag korrigiert wurde.

    service-control --status --all

    service-control --restart --all (--stop oder --start)

    oder

    service-control --restart wcp (--stop oder --start)

    6. Führen Sie die Schritte 2 und 3 erneut aus, um sicherzustellen, dass instance_id nicht NULL ist. Jetzt muss vCenter Server betriebsbereit sein.

    7. Wenn der Benutzer diese Problemumgehung bei vCenter Server 70u3d angewendet hat, fahren Sie dann zu diesem Zeitpunkt mit dem Upgrade auf vCenter Server 70u3f fort oder gehen Sie zum VAMI- (VMware Appliance Management Interface) oder CLI-Installationsprogramm und setzen Sie das Upgrade fort, wenn der Benutzer die Problemumgehung auf vCenter Server 70u3f angewendet hat.

  • Die Sicherheitsrichtlinienfunktion ist nach dem Upgrade möglicherweise nicht verfügbar

    Wenn NSX-T 3.1.x/3.0.x vorhanden ist und erst vCenter, dann Supervisor und zum Schluss NSX-T auf 3.2 oder höher aktualisiert wird, ist die SecurityPolicy-Funktion möglicherweise nicht verfügbar, weil NCP das NSX-T-Upgrade nicht bekannt war.

  • Verbesserte Netzwerkdurchsatzleistung auf Tanzu Kubernetes Grid-Cluster-VMs, die Antrea-ENCAP mit aktivierter LRO verwenden

    Datenpfadoptimierungen wurden hinzugefügt, um die Netzwerkdurchsatzleistung für Tanzu Kubernetes Grid-Cluster zu verbessern, die Antrea-ENCAP mit aktivierter LRO verwenden.

    Keine

  • Das Aktivieren der eingebetteten Harbor-Registrierung auf Supervisor kann zu einer unsicheren Standardkonfiguration führen

    Wenn Sie die unter „Aktivieren der eingebetteten Harbor-Registrierung auf dem Supervisor-Cluster“ beschriebenen Schritte ausgeführt haben, ist in der eingebetteten Harbor-Registrierung möglicherweise eine unsichere Standardkonfiguration vorhanden. Weitere Informationen hierzu finden Sie in VMware Knowledgebase-Artikel 91452.

    Problemumgehung: Das Problem kann entweder durch die Installation dieser Version oder durch die Implementierung einer temporären Problemumgehung behoben werden, wie in KB 91452 beschrieben.

Bekannte Probleme

Die bekannten Probleme gliedern sich in folgende Gruppen.

Supervisor-Cluster

  • <span style="color:#FF0000">NEU:</span> 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 Sie einen getrennten ESXi-Knoten aus einem Cluster verschieben, dieser sich aber weiterhin im selben Datencenter befindet, verbleiben Pods und PVCs, die auf dem Knoten ausgeführt werden, im Status „Wird beendet“

    Wenn sich ein ESXi-Host aufgrund von PSOD im Status „Keine Antwort“ befindet und Sie diesen Host unter demselben Datencenter aus dem Cluster verschieben, bleiben Pods und PVCs, die auf dem Host ausgeführt werden, im Status „Wird beendet“ hängen. Das Problem tritt auch dann auf, wenn ein Ersatzknoten im Cluster verfügbar ist.

    Dieses Problem tritt in der Regel auf, wenn Folgendes stattfindet:

    1. Sie aktivieren den Partnerdienst auf dem Supervisor-Cluster und erstellen Instanzen des Diensts.

    2. Bei einem ESXi-Knoten, auf dem Dienstinstanzen ausgeführt werden, tritt PSOD auf.

    3. Sie trennen den nicht reagierenden Host und verschieben ihn unter demselben Datencenter aus dem Cluster.

      Wenn sich der Host außerhalb des Clusters befindet, können Sie beobachten, dass die auf dem Knoten vorhandenen Pods und PVCs im Status „Wird beendet“ verbleiben.

    Problemumgehung: Entfernen Sie den Host aus der Bestandsliste, anstatt ihn unter demselben Datencenter aus dem Cluster zu verschieben.

  • Die Pod-Erstellung schlägt manchmal auf einem Supervisor-Cluster fehl, wenn DRS auf den manuellen Modus festgelegt ist

    Bei Clustern, bei denen Sie die Arbeitslastverwaltung aktivieren, müssen auch HA und automatisierter DRS aktiviert sein. Das Aktivieren der Arbeitslastverwaltung in Clustern, in denen HA und DRS nicht aktiviert sind oder in denen DRS im manuellen Modus ausgeführt wird, kann zu inkonsistentem Verhalten und Fehlern bei der Pod-Erstellung führen.

    Problemumgehung: Aktivieren Sie DRS im Cluster und legen Sie ihn auf Vollautomatisiert oder Teilautomatisiert fest. Stellen Sie auch sicher, dass HA auf dem Cluster aktiviert ist.

  • Die Speicherklasse wird angezeigt, wenn Sie „kubectl get sc“ ausführen, selbst nachdem Sie die entsprechende Speicherrichtlinie entfernt haben

    Wenn Sie kubectl get sc ausführen, nachdem Sie eine Speicherrichtlinie erstellt, die Richtlinie einem Namespace hinzugefügt und die Richtlinie dann entfernt haben, listet die Befehlsantwort immer noch die entsprechende Speicherklasse auf.

    Problemumgehung: Führen Sie kubectl describe namespace aus, um die Speicherklassen anzuzeigen, die tatsächlich mit dem Namespace verknüpft sind.

  • Anstatt nur der Speicherklassen für den Supervisor-Namespace werden bei Ausführung von „kubectl describe storage-class“ oder „kubectl get storage-class“ auf einem Supervisor-Cluster alle Speicherklassen zurückgegeben

    Wenn Sie den Befehl kubectl describe storage-class oder kubectl get storage-class auf einem Supervisor-Cluster ausführen, gibt der Befehl alle Speicherklassen und nicht nur die Speicherklassen für den Supervisor-Namespace zurück.

    Problemumgehung: Leiten Sie die Speicherklassennamen, die dem Namespace zugeordnet sind, aus dem ausführlichen Namen des Kontingents ab.

  • Die Schaltfläche zum Freigeben des Kubernetes-API-Endpoints ignoriert den FQDN selbst dann, wenn er konfiguriert ist

    Auch wenn der FQDN für die Kubernetes-Steuerungsebenen-IP für Supervisor-Cluster-Namespace konfiguriert ist, gibt die Schaltfläche „Namespace freigeben“ anstelle des FQDN die IP-Adresse zurück.

    Problemumgehung: Geben Sie den Supervisor-Cluster-Namespace manuell an den FQDN frei.

  • Der Zugriff auf den Lastausgleichsdienst ist über die vSphere-Anmeldung „kubectl“ nicht möglich

    Sie können über die vSphere-Anmeldung „kubectl“ nicht auf den API-Server zugreifen, wenn Sie einen Endpoint mit Lastausgleich verwenden.

    Problemumgehung: Dieses Problem kann sich auf zweierlei Weise äußern.

    1. Prüfen Sie, ob der API-Server über die Steuerungsebene <curl -k https://vip:6443 (oder 443)> erreichbar ist.

      1. Wenn Sie vom API-Server aus nicht auf den Lastausgleichsdienst zugreifen können, ist der API-Server noch nicht verfügbar.

      2. Problemumgehung: Warten Sie einige Minuten, bis der API-Server zugänglich wird.

    2. Prüfen Sie, ob der Status des Edge-VM-Knotens aktiv ist.

      1. Melden Sie sich bei NSX Manager an.

      2. Wechseln Sie zu System > Fabric > Knoten > Edge-Transportknoten. Der Knotenstatus muss aktiv sein.

      3. Wechseln Sie zu Netzwerk > Lastausgleichsdienste > Virtuelle Server. Suchen Sie nach den VIPs, die mit kube-apiserver-lb-svc-6443 und kube-apiserver-lb-svc-443 enden. Wenn ihr Status nicht aktiv ist, verwenden Sie die folgende Problemumgehung.

      4. Problemumgehung: Starten Sie die Edge-VM neu. Die Edge-VM wird nach dem Neustart neu konfiguriert.

  • Die Clusterkonfiguration von vSphere with Tanzu zeigt während der Konfiguration Zeitüberschreitungsfehler an

    Während der Konfiguration des Clusters werden möglicherweise die folgenden Fehlermeldungen angezeigt:

    Api request to param0 failed

    oder

    Config operation for param0 node VM timed out

    Problemumgehung: Keine. Die Aktivierung von vSphere with Tanzu kann 30 bis 60 Minuten dauern. Wenn diese oder ähnliche param0-Zeitüberschreitungsmeldungen angezeigt werden, handelt es sich nicht um Fehler, und die Meldungen können ignoriert werden.

  • Deaktivieren und sofortiges erneutes Aktivieren eines vSphere-Diensts in vSphere with Tanzu führt dazu, dass ein entsprechender Namespace in vCenter Server nicht mehr reagiert.

    Wenn der vSphere-Dienst deaktiviert und sofort wieder aktiviert wird, wird der Namespace im Supervisor-Cluster gelöscht und neu erstellt. Der entsprechende Namespace in vCenter Server verbleibt jedoch im Status „Wird beendet“. Infolgedessen können dem Namespace in vCenter Server keine Ressourcenkontingente zugewiesen werden, und DevOps-Ingenieure können keine Ressourcen wie Pods und PVCs im Namespace erstellen. Darüber hinaus schlägt die Bereitstellung des Benutzeroberflächen-Plug-Ins fehl, da der Dienstoperator-Pod nicht ausgeführt werden kann.

    Sie können die App Platform-Protokolle abrufen, indem Sie den folgenden Befehl auf dem Supervisor-Cluster ausführen: kubectl -n vmware-system-appplatform-operator-system logs vmware-system-appplatform-operator-mgr-0.

    Problemumgehung:

    Warten Sie vor dem erneuten Aktivieren des Diensts, bis der Namespace vollständig aus vCenter Server gelöscht wurde.

    Wenn der Namespace im Status „Wird beendet“ hängen bleibt, führen Sie die folgenden Schritte aus:

    1. Deaktivieren Sie den Dienst erneut.

    2. Starten Sie den wcp-Dienst in vCenter Server neu.

    3. Warten Sie, bis der Namespace gelöscht wurde. Dieser Schritt kann einige Zeit in Anspruch nehmen.

    4. Starten Sie den Dienst neu.

  • Die Aktivierung der Containerregistrierung schlägt fehl

    Wenn der Benutzer die Containerregistrierung über die Benutzeroberfläche aktiviert, schlägt die Aktivierungsaktion nach 10 Minuten mit einem Zeitüberschreitungsfehler fehl.

    Problemumgehung: Deaktivieren Sie die Containerregistrierung und wiederholen Sie die Aktivierung. Beachten Sie, dass der Zeitüberschreitungsfehler erneut auftreten kann.

  • Die Aktivierung eines Clusters nach dessen Deaktivierung schlägt fehl

    Das Aktivieren eines Clusters kurz nach dem Deaktivieren kann einen Konflikt beim Zurücksetzen des Kennworts für das Dienstkonto verursachen. Die Aktivierungsaktion schlägt fehl.

    Problemumgehung: Führen Sie einen Neustart mit dem Befehl vmon-cli --restart wcp durch.

  • Beim Löschen eines Container-Image-Tags in einer eingebetteten Containerregistrierung werden möglicherweise alle Image-Tags gelöscht, die dasselbe physische Container-Image verwenden

    Mehrere Images mit unterschiedlichen Tags können aus demselben Container-Image an ein Projekt in einer eingebetteten Containerregistrierung weitergegeben werden. Wenn eines der Images im Projekt gelöscht wird, werden alle anderen Images mit unterschiedlichen Tags, die aus demselben Image stammen, gelöscht.

    Problemumgehung: Der Vorgang kann nicht rückgängig gemacht werden. Geben Sie das Image erneut an das Projekt weiter.

  • Ein fehlgeschlagener Bereinigungsvorgang in einem Registrierungsprojekt führt zu einem Fehlerzustand des Projekts

    Wenn Sie einen Bereinigungsvorgang für ein Registrierungsprojekt durchführen, wird das Projekt vorübergehend in einem Fehlerzustand angezeigt. Sie können keine Images an dieses Projekt weitergeben oder daraus abrufen. In regelmäßigen Abständen wird das Projekt überprüft, und alle Projekte, die sich im Fehlerzustand befinden, werden gelöscht und neu erstellt. In diesem Fall werden alle vorherigen Projektmitglieder wieder zu dem neu erstellten Projekt hinzugefügt, und alle Repositorys und Images, die zuvor im Projekt vorhanden waren, werden gelöscht, sodass der Bereinigungsvorgang effektiv abgeschlossen wird.

    Problemumgehung: Keine.

  • Die Aktivierung der Containerregistrierung schlägt fehl, wenn die Speicherkapazität geringer als 2000 Mebibyte ist

    Für die Containerregistrierung gilt eine erforderliche Mindest-Gesamtspeicherkapazität, die im Feld „limit“ in VMODL angegeben ist. Dies liegt daran, dass einige Kubernetes-Pods ausreichend Speicherplatz benötigen, um ordnungsgemäß zu funktionieren. Damit die Containerregistrierung funktioniert, ist eine Mindestkapazität von 5 Gigabyte erforderlich. Beachten Sie, dass dieser Grenzwert keine Garantie für eine verbesserte Leistung oder die Unterstützung von mehr oder größeren Images bietet.

    Problemumgehung: Dieses Problem kann durch die Bereitstellung der Containerregistrierung mit einer größeren Gesamtkapazität vermieden werden. Das empfohlene Speichervolumen darf nicht weniger als 5 Gigabyte betragen.

  • Wenn Sie das TLS-Zertifikat des NSX-Lastausgleichsdiensts für Kubernetes-Cluster ersetzen, können Sie sich möglicherweise nicht über einen Docker-Client oder über die Harbor-Benutzeroberfläche bei der eingebetteten Harbor-Registrierung anmelden

    Um des TLS-Zertifikat für den NSX Load Balancer für Kubernetes-Cluster zu ersetzen, navigieren Sie in der vSphere-Benutzeroberfläche zu Konfigurieren > Namespaces > Zertifikate > NSX Load Balancer > Aktionen und klicken Sie auf Zertifikat ersetzen. Wenn Sie das NSX-Zertifikat ersetzen, schlägt der Anmeldevorgang bei der eingebetteten Harbor-Registrierung über einen Docker-Client oder die Harbor-Benutzeroberfläche möglicherweise mit dem Fehler unauthorized: authentication required oder Invalid user name or password fehl.

    Problemumgehung: Starten Sie den Registrierungs-Agent-Pod im Namespace vmware-system-registry neu:

    1. Führen Sie den Befehl kubectl get pod -n vmware-system-registry aus.

    2. Löschen Sie den Pod durch Ausführen des Befehls kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry .

    3. Warten Sie, bis der Pod neu gestartet wird.

  • Mit DNSDefault bereitgestellte Pods verwenden clusterDNS-Einstellungen

    Jeder in einem Supervisor-Cluster bereitgestellte vSphere-Pod, der DNSDefault verwendet, fällt auf die Verwendung des für den Cluster konfigurierten clusterDNS zurück.

    Problemumgehung: Keine.

  • Möglicherweise werden alle Hosts in einem Cluster gleichzeitig aktualisiert, wenn ein Upgrade für einen Supervisor-Cluster durchgeführt wird

    In bestimmten Fällen werden während des Supervisor-Cluster-Upgrades parallel alle Hosts in einem Cluster aktualisiert. Dies führt zu Ausfallzeiten bei allen Pods, die auf diesem Cluster ausgeführt werden.

    Problemumgehung: Starten Sie während des Supervisor-Cluster-Upgrades wcpsvc nicht neu und fügen Sie keine Hosts hinzu bzw. entfernen Sie keine Hosts.

  • Das Supervisor-Cluster-Upgrade bleibt möglicherweise für eine unbegrenzte Zeit hängen, wenn VMCA als Zwischenzertifizierungsstelle verwendet wird

    Das Supervisor-Cluster-Upgrade bleibt möglicherweise für eine unbegrenzte Zeit in der Phase „Konfigurieren“ hängen, wenn VMCA als Zwischenzertifizierungsstelle verwendet wird.

    Problemumgehung: Wechseln Sie für VMCA zu einer Zertifizierungsstelle, die keine Zwischenzertifizierungsstelle ist, und löschen Sie alle VMs der Steuerungsebene, die in der Phase „Konfigurieren“ hängen geblieben sind.

  • vSphere-Pod-Bereitstellung schlägt fehl, wenn eine Speicherrichtlinie mit aktivierter Verschlüsselung für flüchtige Pod-Festplatten zugewiesen wird

    Wenn eine Speicherrichtlinie mit aktivierter Verschlüsselung für flüchtige Pod-Festplatten verwendet wird, schlägt die Erstellung von vSphere-Pods mit dem Fehler „AttachVolume.Attach für Volume fehlgeschlagen“ fehl.

    Problemumgehung: Verwenden Sie eine Speicherrichtlinie ohne Verschlüsselung für die flüchtigen Pod-Festplatten.

  • Das Upgrade des Supervisor-Clusters bleibt während des Vorgangs „Namespace-Cluster-Upgrade befindet sich im Upgrade-Host-Schritt“ bei 50 % hängen

    Das Problem tritt auf, wenn ein vSphere-Pod während des Upgrades des Kubernetes-Steuerungsebenenknotens im Zustand WIRD BEENDET hängen bleibt. Der Controller des Steuerungsebenenknotens versucht, ein Upgrade des Spherelet-Prozesses durchzuführen. Während dieser Phase werden vSphere-Pods auf diesem Knoten der Steuerungsebene evakuiert oder beendet, um die Registrierung des Knotens bei der Kubernetes-Steuerungsebene aufzuheben. Aus diesem Grund bleibt das Upgrade des Supervisor-Clusters bei einer älteren Version hängen, bis vSphere-Pods im Zustand WIRD BEENDET aus der Bestandsliste entfernt werden.

    Problemumgehung:

    1. Melden Sie sich bei dem ESXi-Host an, auf dem der vSphere-Pod im Zustand WIRD BEENDET hängen bleibt.

    2. Entfernen Sie die vSphere-Pods im Zustand WIRD BEENDET mithilfe der folgenden Befehle:

    # vim-cmd vmsvc/getallvms

    # vim-cmd vmsvc/destroy

    Nach diesem Schritt werden die vSphere-Pods im vSphere Client als verwaist angezeigt.

    3. Löschen Sie die verwaisten vSphere-Pods, indem Sie zunächst der Gruppe „ServiceProviderUsers“ einen Benutzer hinzufügen.

    a.) Melden Sie sich beim vSphere Client an, wählen Sie Verwaltung -> Benutzer und Gruppen -> Benutzer erstellen und klicken Sie auf Gruppen.

    b.) Suchen Sie nach der Gruppe „ServiceProviderUsers“ oder „Administratoren“ und fügen Sie der Gruppe einen Benutzer hinzu.

    4. Melden Sie sich beim vSphere Client unter Verwendung des soeben erstellten Benutzers an und löschen Sie die verwaisten vSphere-Pods.

    5. Verwenden Sie in kubectl den folgenden Befehl:

    kubectl patch pod -p -n '{"metadata":{"finalizers":null}}'

  • Die Benutzeroberfläche für die Arbeitslastverwaltung löst den folgenden Lizenzfehler aus: Keiner der Hosts, die mit diesem vCenter verbunden sind, ist für die Arbeitslastverwaltung lizenziert

    Nach der erfolgreichen Aktivierung der Arbeitslastverwaltung auf einem vSphere-Cluster wird möglicherweise nach dem Neustart von vCenter Server oder dem Upgrade von ESXI-Hosts, auf denen die Arbeitslastverwaltung aktiviert ist, der folgende Lizenzierungsfehler angezeigt: Keiner der Hosts, die mit diesem vCenter verbunden sind, ist für die Arbeitslastverwaltung lizenziert. Dies ist ein Benutzeroberflächenfehler. Ihre Lizenz sollte weiterhin gültig sein, und Ihre Arbeitslasten sollten weiterhin ausgeführt werden.

    Problemumgehung: Benutzer sollten ihren Browser-Cache für den vSphere Client löschen.

  • Die Synchronisierung großer vSphere-Umgebungen in einer Cloud mit dem VMware NSX Advanced Load Balancer Controller kann lange dauern

    Die Synchronisierung von vSphere-Umgebungen mit Bestandslisten, die mehr als 2.000 ESXi-Hosts und 45.000 virtuelle Maschinen enthalten, kann in einer Cloud mit einem NSX Advanced Load Balancer Controller bis zu zwei Stunden dauern.

    Problemumgehung: Keine

  • Die private Containerregistrierung des Supervisor-Clusters wird möglicherweise fehlerhaft, nachdem das VMware Certificate Authority (VMCA)-Rootzertifikat auf einem vCenter Server 7.0 Update 2 geändert wurde

    Nach dem Ändern des VMware Certificate Authority (VMCA)-Rootzertifikats auf einem System mit vCenter Server 7.0 Update 2 wird die private Containerregistrierung des Supervisor-Clusters möglicherweise fehlerhaft, und die Registrierungsvorgänge funktionieren nicht mehr wie erwartet. Die folgende Integritätsstatusmeldung für die Containerregistrierung wird auf der Benutzeroberfläche für die Clusterkonfiguration angezeigt:

    Harbor registry harbor-1560339792 on cluster domain-c8 is unhealthy. Reason: failed to get harbor health: Get https://30.0.248.2/api/health: x509: certificate signed by unknown authority

    Problemumgehung:

    Starten Sie den Registrierungs-Agent-Pod im Namespace vmware-system-registry auf dem vSphere Kubernetes-Cluster manuell neu:

    1. Führen Sie den Befehl kubectl get pod -n vmware-system-registry aus, um den Registrierungs-Agent-Pod abzurufen.

    2. Löschen Sie die Pod-Ausgabe, indem Sie den Befehl kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry ausführen.

    3. Warten Sie, bis der Pod neu gestartet wird.

    4. Aktualisieren Sie die Image-Registrierung auf der Benutzeroberfläche für die Clusterkonfiguration, und der Systemstatus sollte in Kürze als „Wird ausgeführt“ angezeigt werden.

  • Projekte für neu erstellte Namespaces im Supervisor-Cluster werden nicht automatisch in der privaten Containerregistrierung erstellt

    Projekte werden möglicherweise nicht automatisch in der privaten Containerregistrierung für neu erstellte Namespaces auf einem Supervisor-Cluster erstellt. Der Status der Containerregistrierung wird weiterhin als fehlerfrei angezeigt, aber in der Containerregistrierung des Clusters werden keine Projekte angezeigt, wenn ein neuer Namespace erstellt wird. Sie können keine Images an die Projekte der neuen Namespaces in der Containerregistrierung weitergeben oder von ihnen abrufen.

    Problemumgehung:

    1. Führen Sie den Befehl „kubectl get pod -n vmware-system-registry“ aus, um den Registrierungs-Agent-Pod zu erhalten.

    2. Löschen Sie die Pod-Ausgabe, indem Sie den Befehl „kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry“ ausführen.

    3. Warten Sie, bis der Pod neu gestartet wird.

    4. Melden Sie sich bei der Registrierung des privaten Containers an, um sicherzustellen, dass Projekte für Namespaces im Cluster erstellt werden.

  • Möglicherweise beobachten Sie ErrImgPull beim Erstellen von Pods mit 10 Replikaten

    Dieses Problem kann beim Versuch auftreten, eine Bereitstellung mit 10 Replikat-Pods in einer YAML zu verwenden. Beim Erstellungsversuch mit dieser YAML mithilfe der privaten Containerregistrierung werden von 10 Replikaten möglicherweise mindestens 7 übergeben und 3 fallen möglicherweise mit dem Problem „ErrImgPull“ aus.

    Problemumgehung: Verwenden Sie weniger Replikat-Sets, maximal 5.

  • Der NSX Advanced Load Balancer Controller wird nicht unterstützt, wenn vCenter Server mit einem benutzerdefinierten Port bereitgestellt wird

    Sie können vCenter Server nicht mit dem NSX Advanced Load Balancer Controller registrieren, da während der Registrierung keine Option für die Bereitstellung eines benutzerdefinierten vCenter Server-Ports in der Benutzeroberfläche des NSX Advanced Load Balancer Controller vorhanden ist.

    Der NSX Advanced Load Balancer Controller funktioniert nur, wenn vCenter Server mit den Standardports 80 und 443 bereitgestellt wird.

  • Bei einem Domänenneuverweis auf einem vCenter Server, auf dem bereits Supervisor-Cluster ausgeführt werden, wechseln die Supervisor-Cluster in den Zustand „Konfigurieren“

    Domänenneuverweise werden auf einem vCenter Server mit Supervisor-Clustern nicht unterstützt. Beim Versuch, einen Domänenneuverweis durchzuführen, wechseln vorhandene Supervisor-Cluster in den Zustand „Konfigurieren“, und VMs der Steuerungsebene und Tanzu Kubernetes-Cluster-VMs werden in der Bestandsliste in der Ansicht „Hosts und Cluster“ nicht mehr angezeigt.

    Problemumgehung: Keine

  • Das Zuweisen von Tags und benutzerdefinierten Attributen funktioniert nicht für VMs, die mithilfe von Kubernetes in einem Supervisor-Cluster erstellt wurden

    Wenn Sie versuchen, einer VM, die in einem Supervisor-Cluster erstellt wurde, Tags oder benutzerdefinierte Attribute entweder über den vSphere UI-Client oder unter Verwendung von vAPIs zuzuweisen, schlägt der Vorgang mit der Meldung „Beim Anhängen von Tags ist ein Fehler aufgetreten“ fehl.

    Problemumgehung: Keine

  • Entwickler mit der Berechtigung für Self-Service-Namespaces können nicht auf Ressourcen im Clusterbereich zugreifen, z. B. Speicherklassen

    Wenn Entwickler versuchen, Speicherklassen im Clusterbereich mithilfe des Befehls kubectl aufzulisten

    kubectl get storageclass -n test-ns or kubectl get storageclass

    Der folgende Fehler wird angezeigt.

    Error from server (Forbidden): storageclasses.storage.k8s.io is forbidden: User "<sso:DEVUSER@DOMAIN>" cannot list resource "storageclasses" in API group "storage.k8s.io" at the cluster scope

    Problemumgehung: Dies ist ein erwartetes Verhalten, da Entwickler nur Zugriff auf die Speicherklassen haben, die der Namespacevorlage zugewiesen sind, auf die sie Zugriff haben. Dies wird vom vSphere-Administrator vorab festgelegt.

    Mithilfe des folgenden Befehls werden Speicherklassen aufgelistet, die dem Namespace zugeordnet sind.

    kubectl get resourcequota <NAMESPACE>-storagequota -n <NAMESPACE>

  • Die Verwendung von „kubectl apply -f“ für Self-Service eines Namespace schlägt fehl

    Der Versuch, einen Namespace mithilfe eines Manifests mit kubectl apply -f zu erstellen, schlägt fehl mit dem Fehler

    Error from server (Forbidden): namespaces is forbidden: User "sso:[email protected]"cannot list resource "namespaces"inAPI group ""at the cluster scope

    Problemumgehung: Entwickler können stattdessen den Befehl kubectl create -f verwenden, um einen Namespace zu erstellen.

  • Das Erstellen von vSphere-Pods in einem Self-Service-Namespace schlägt gelegentlich fehl

    Möglicherweise tritt der Fehler „Ressourcenpods können nicht erstellt werden“ auf, wenn Sie versuchen, einen vSphere-Pod in einem Namespace zu erstellen, der mit der Self-Service-Namespace-Vorlage erstellt wurde.

    Problemumgehung: Warten Sie einige Sekunden nach der Namespace-Erstellung, um vSphere-Pods im Namespace zu erstellen.

  • Entwickler können keine Bezeichnungen und Anmerkungen zu Namespaces hinzufügen, die mithilfe der Self-Service-Namespace-Vorlage erstellt wurden

    Der Versuch, Bezeichnungen und Anmerkungen im Manifest anzugeben, das zum Erstellen oder Ändern eines Namespace mit dem Befehl kubectl apply -f verwendet wird, schlägt fehl mit dem Fehler

    Error from server (Forbidden): User "sso:[email protected]"cannot patch resource "namespaces"inAPI group ""inthe namespace ""

    Problemumgehung: Fügen Sie erforderliche Bezeichnungen und Anmerkungen zum Namespace-Manifest hinzu und verwenden Sie stattdessen kubectl create -f , um Bezeichnungen und Anmerkungen hinzuzufügen.

  • Sie können die Namespace-Vorlage erst verwenden, wenn ein Supervisor-Cluster-Upgrade ausgeführt wird.

    Wenn Sie ein Supervisor-Cluster-Upgrade starten, bleibt jede Aufgabe in Zusammenhang mit der Namespace-Vorlage, z. B. Aktivierung, Deaktivierung oder Updates, in einer Warteschlange, bis das Upgrade abgeschlossen ist.

    Problemumgehung: Warten Sie, bis der Upgrade-Vorgang abgeschlossen ist, bevor Sie Befehle ausführen, um die Namespace-Vorlage zu bearbeiten.

  • Versuche, ein dauerhaftes Volume an einen Pod auf einem Tanzu Kubernetes-Cluster anzuhängen, schlagen mit der Fehlermeldung „CNS: Fehler beim Anhängen der Festplatte aufgrund eines fehlenden SCSI-Controllers“ fehl

    Wenn Sie versuchen, ein dauerhaftes Volume an einen Pod in einem Tanzu Kubernetes-Cluster anzuhängen, schlagen Ihre Versuche fehl und der Pod verbleibt im Status „Ausstehend“. Die Fehlermeldung weist darauf hin, dass der SCSI-Controller fehlt, obwohl für die Worker-Knoten-VM ein PVSCSI-Controller konfiguriert ist.

    Dieses Problem kann auftreten, wenn die Worker-Knoten-VM ihren Block-Volume-Grenzwert von 60 Volumes erreicht. Kubernetes ignoriert jedoch die vSphere-Volume-Grenzwerte und plant die Blockierung der Volume-Erstellung auf diesem Knoten.

    Problemumgehung: Fügen Sie dem Cluster einen Worker-Knoten hinzu. Löschen Sie den Pod, um seine Bereitstellung auf dem neuen Worker-Knoten zu planen.

  • Das Löschen eines statusbehafteten Pods nach einer inaktiven vCenter Server-Sitzung und der Versuch, sein Volume später im Tanzu Kubernetes-Cluster wiederzuverwenden oder zu löschen, kann zu Fehlern und unvorhersehbarem Verhalten führen

    Wenn Sie einen statusbehafteten Pod löschen, nachdem er einen Tag lang inaktiv war, scheint sein Volume erfolgreich von der Knoten-VM des Tanzu Kubernetes-Clusters getrennt zu sein. Wenn Sie jedoch versuchen, einen neuen statusbehafteten Pod mit diesem Volume zu erstellen oder das Volume zu löschen, schlagen Ihre Versuche fehl, da das Volume weiterhin an die Knoten-VM in vCenter Server angehängt ist.

    Problemumgehung: Verwenden Sie die CNS-API, um das Volume von der Knoten-VM zu trennen, damit der Status des Volumes im Tanzu Kubernetes-Cluster und in vCenter Server synchronisiert wird. Starten Sie außerdem den CSI-Controller im Supervisor-Cluster neu, um die inaktive Sitzung zu erneuern.

  • Das Supervisor-Cluster-Upgrade bleibt hängen bzw. wird aufgrund einer Ausschöpfung des IP-Bereichs im primären Arbeitslastnetzwerk des Supervisor-Clusters (bei Verwendung des vSphere-Netzwerks)/NCP-Cluster-Netzwerk-Pod-CIDRs (bei Verwendung von NSX-T Container-Plug-Ins) nicht abgeschlossen.

    Das Supervisor-Cluster-Upgrade bleibt im Status „Ausstehend“ mit folgender Meldung hängen: „Das Upgrade des Namespaces-Clusters läuft im Bereitstellungsschritt eines neuen Masters“.

    Neue Steuerungsebenen-VMs, die während des Cluster-Upgrades bereitgestellt werden, erhalten nur eine Netzwerkschnittstelle. Steuerungsebenen-VMs sollten über 2 Netzwerkschnittstellen verfügen, wobei eine mit dem Verwaltungsnetzwerk und die andere mit dem Arbeitslastnetzwerk verbunden ist.

    Bestimmte System-Pods wie coredns, die auf der neuen Steuerungsebenen-VM bereitgestellt werden sollen, bleiben möglicherweise im Status „Ausstehend“ hängen.

    Problemumgehung: Löschen Sie eine kleine Anzahl von Arbeitslasten (VMs, Pod-VMs, TKG-Cluster), um genügend IPs für den Abschluss des Upgrade-Vorgangs freizugeben. Mindestens 3 IPs sollten freigegeben werden.

  • Aktualisieren der Schlüssel/Wert-Paare oder Registrierungsanmeldedaten für eine Supervisor-Dienstkonfiguration

    Möglicherweise möchten Sie die Schlüssel-Wert-Paare der Konfigurationsregistrierung eines Supervisor-Diensts ändern, weil Sie falsche Anmeldedaten eingegeben haben oder das Registrierungskennwort möglicherweise abgelaufen ist.

    Problemumgehung:

    1. Erstellen Sie eine neue Ressource für einen geheimen Schlüssel auf dem Supervisor-Cluster.

    kubectl -n vmware-system-supervisor-services create secret generic new-secret --from-literal=registryName= --from-literal=registryPasswd= --from-literal=registryUsername=

    2. Aktualisieren Sie die Dienstreferenz für die Supervisor-Dienstressource.

    # kubectl edit supervisorservice svc-minio -n vmware-system-supervisor-services

    3. Aktualisieren Sie die spec.config-Sitzung:

    spec:

    config:

    secretNamespace: vmware-system-supervisor-services

    secretRef: new-secret

  • Tanzu Kubernetes Grid Service- und Supervisor-Dienst-UI-Plug-Ins funktionieren nicht

    Wenn vCenter Server von einem benutzerdefinierten CA-Zertifikat signiert und der Supervisor-Cluster aktiviert ist, funktionieren das Tanzu Kubernetes Grid-Dienst-UI-Plug-In und alle im vSphere Client bereitgestellten Supervisor-Dienst-UI-Plug-Ins nicht. Bei den UI-Plug-Ins treten SSL-Authentifizierungsprobleme auf, wenn versucht wird, mit den entsprechenden Backend-Servern im Supervisor-Cluster zu kommunizieren. Das Tanzu Kubernetes Grid Service-Plug-In zeigt eine Fehlermeldung ähnlich der folgenden an:

    The Tanzu Kubernetes Grid Service failed to authenticate with kubernetes; see the browser console for more technical details

    Problemumgehung: Fügen Sie das vertrauenswürdige Root-Zertifikat in einer separaten Datei (nicht in vmca.pem) in /etc/ssl/certs hinzu und generieren Sie die Hashes erneut mithilfe von c_rehash. Sie müssen dies auf allen drei Steuerungsebenen-VMs durchführen.

    Beachten Sie, dass das Bearbeiten von /etc/ssl/certs/vmca.pem nicht empfohlen wird, da die Inhalte dieser Datei während jeder Clustersynchronisierung von „update-controller“ überschrieben werden.

    Bedenken Sie darüber hinaus Folgendes: Wenn eine der Steuerebenen-VMs im Supervisor-Cluster erneut bereitgestellt wird (beispielsweise nach einer Größenanpassung der Steuerungsebenen-VMs oder aufgrund einer Reparatur), geht das manuell unter /etc/ssl/certs hinzugefügte Zertifikat verloren und die Problemumgehung muss auf die betroffene VM erneut angewendet werden.

  • Supervisor-Cluster hängt im Konfigurationszustand

    Nach der Konfiguration eines vSphere-Clusters als Supervisor-Cluster hängt der Cluster im Konfigurationszustand. Sie können keine vSphere-Pods und Tanzu Kubernetes-Cluster erstellen.

    Problemumgehung: Starten Sie den Dienst „wcp“ mit dem folgenden Befehl neu:

    vmon-cli restart wcp

    Detaillierte Anweisungen finden Sie in der Dokumentation.

  • „kubectl get virtualmachineimages“ gibt auch dann keine Ergebnisse zurück, wenn die zugeordnete Inhaltsbibliothek mit VM-Images aufgefüllt wird

    Wenn die vom VM-Dienst verwendete Inhaltsbibliothek mit einer Sicherheitsrichtlinie aktiviert ist, kann der VM-Dienst die Images nicht lesen, und VMs können nicht mithilfe von Images aus dieser Inhaltsbibliothek bereitgestellt werden.

    Problemumgehung: Heben Sie die Zuordnung der Inhaltsbibliothek zur Sicherheitsrichtlinie vom Supervisor-Namespace auf. Entfernen Sie die Einstellung „Standard-OVF-Sicherheitsrichtlinie“ aus der relevanten Inhaltsbibliothek und verknüpfen Sie dann die Inhaltsbibliothek erneut mit dem Namespace.

  • Entwicklern wird ein falscher NETZSTATUS für VMs mit vom VM-Dienst verwalteten vGPU- und Passthrough-Geräten angezeigt, wenn der zugehörige Host in den Wartungsmodus wechselt.

    Wenn ein Host in den Wartungsmodus wechselt, werden VMs mit vom VM-Dienst verwalteten vGPU- und Passthrough-Geräten automatisch von DRS ausgeschaltet. In der Ausgabe von kubectl get vm werden jedoch der vorherige Netzstatus und VMs angezeigt. Dies würde dazu führen, dass POWERSTATE=poweredOn angezeigt wird, selbst wenn die VM auf vCenter ausgeschaltet ist.

    Keine.

  • Auf einem Supervisor-Cluster mit NSX-T-Einrichtung verwenden ESXi-Hosts gegebenenfalls weiterhin selbstsignierte Spherelet-VIBs

    Wenn Sie Ihren Supervisor-Cluster mit der in vCenter Server 7.0 Update 3 verfügbaren Kubernetes-Version konfiguriert oder aktualisiert haben und die Kubernetes-Version Ihres Supervisor-Clusters weiter auf eine in vCenter Server 7.0 Update 3a verfügbare Version aktualisiert haben, verwenden ESXi-Hosts gegebenenfalls weiterhin selbstsignierte Spherelet-VIBs. Dies geschieht, weil die auf vCenter Server 7.0 Update 3 und vCenter Server 7.0 Update 3a installierten Spherelet-VIB-Versionen identisch sind. Dieses Problem trifft nicht auf einen Supervisor-Cluster zu, der mit dem vSphere-Netzwerk-Stack konfiguriert ist.

    Umgehung 1:

    Wenn der vSphere-Cluster nicht auf vSphere Lifecycle Manager basiert, führen Sie die folgenden Schritte aus, um die von VMware zertifizierten Spherelet-VIBs zu installieren:

    1. Versetzen Sie einen ESXi-Host in den Wartungsmodus und warten Sie, bis er vom Supervisor-Cluster als „Nicht bereit“ markiert wird.

    2. Verschieben Sie diesen Host als eigenständigen Host außerhalb des Clusters und warten Sie, bis das Spherelet und NSX-T-VIBs deinstalliert wurden.

    3. Fügen Sie denselben Host wieder zum Cluster hinzu, beenden Sie den Wartungsmodus und warten Sie, bis das neue Spherelet und das NSX-T-VIB erneut konfiguriert wurden.

    4. Wiederholen Sie die obigen Schritte für jeden ESXi-Host innerhalb des Clusters.

    Wenn der Supervisor-Cluster mit vSphere Lifecycle Manager aktiviert ist, deaktivieren Sie den Supervisor-Cluster und konfigurieren Sie ihn erneut.

    Umgehung 2:

    Deaktivieren Sie nach der Aktualisierung von vCenter Server auf vCenter Server 7.0 Update 3a den Supervisor-Cluster und konfigurieren Sie ihn neu. Dies gilt sowohl für Cluster, die mit vSphere Lifecycle Manager aktiviert sind, als auch für Cluster, die nicht auf vLCM/VUM basieren.

  • Auf bestimmten vSphere-Pods wird nach einem Neustart des Hosts oder Upgrade des Supervisor-Clusters der Status „NodeAffinity“ angezeigt

    Nach dem Neustart des Hosts oder Upgrade des Supervisor-Clusters wird für bestimmte vSphere-Pods unter Umständen der Status NodeAffinity angezeigt. Dieses Verhalten ist das Ergebnis eines Problems in Upstream-Kubernetes, bei dem der Kubernetes-Scheduler nach dem Kubelet-Neustart redundante Pods mit dem Status NodeAffinity im Cluster erstellt. Dieses Problem hat keine Auswirkungen auf die Funktionen des Clusters. Informationen zum Problem in Upstream-Kubernetes finden Sie unter https://github.com/kubernetes/kubernetes/issues/92067.

    Problemumgehung: Löschen Sie die redundanten Pods mit dem Status NodeAffinity.

  • vDPp-Service-Operator und auf vSphere with Tanzu aktivierte Instanz-Pods treten in den Status „Ausstehend“, nachdem Sie Ihre Umgebung auf 7.0 Update 3e oder höher aktualisiert haben

    Dieses Problem tritt auf, wenn die auf dem Supervisor-Cluster installierte Version des Partnerdiensts Kubernetes Version 1.22 nicht unterstützt. Nach dem Upgrade Ihrer vSphere with Tanzu-Umgebung auf 1.22 mit Version 7.0 Update 3e oder höher ist der Dienst nicht mehr kompatibel. Dies führt dazu, dass der Operator und die Instanz-Pods in den Status „Ausstehend“ wechseln.

    Die Versuche, den Dienst auf eine neuere Version zu aktualisieren, schlagen fehl.

    Problemumgehung: Aktualisieren Sie den vDPp-Dienst auf eine mit Kubernetes 1.22 kompatible Version vor dem Upgrade von vSphere with Tanzu auf 7.0 Update 3e.

  • Das automatische Upgrade eines Clusters von Kubernetes 1.19.1 auf 1.20.8 schlägt fehl

    In seltenen Fällen kann das automatische Upgrade eines Clusters von Kubernetes 1.19.1 auf 1.20.8 mit dem folgenden Fehler fehlschlagen:

    Aufgabe für Upgrade wurde nicht gefunden. Lösen Sie das Upgrade erneut aus.

    Problemumgehung: Starten Sie das Cluster-Upgrade manuell.

  • Vorgänge im Supervisor-Namespace können fehlschlagen, wenn er innerhalb kurzer Zeit wiederverwendet wurde:

    Wenn ein Supervisor-Namespace innerhalb eines kurzen Zeitraums gelöscht und mit demselben Namen neu erstellt wurde, sind Vorgänge möglicherweise aufgrund eines ungültigen Eintrags im Cache fehlgeschlagen.

    Dieses Problem wurde in der aktuellen Version behoben.

  • Das Supervisor-Support-Paket enthält das VC-Support-Paket:

    Durch die Generierung eines Supervisor-Support-Pakets wurde das VC-Support-Paket nicht automatisch aufgenommen.

    Behoben in der neuesten Version.

  • Inhalt der Netzwerk-Support-Checkliste nicht lokalisiert.

    Während der Aktivierung der Arbeitslastverwaltung ist es möglich, eine Netzwerk-Checkliste herunterzuladen. Lokalisierung wird nicht auf das Arbeitsblatt angewendet.

    Behoben in der aktuellen Version.

  • In einem skalierten Tanzu Kubernetes-Cluster-Setup wird das OOM-Problem auf WCP-System-Pods capi-kubeadm-control-plane-controller-manager beobachtet

    Dokumentiert im KB-Artikel

    https://kb.vmware.com/s/article/88914

    Weitere Informationen finden Sie im KB-Artikel

  • Das Supervisor-Cluster-Upgrade bleibt beim Upgradeschritt der Komponenten aufgrund eines Fehlers beim TKG- oder CAPW-Upgrade hängen.

    Dokumentiert im KB-Artikel

    https://kb.vmware.com/s/article/88854

  • Die Sicherheitsrichtlinie entfernt keine aktualisierten Regeln.

    Wenn eine Sicherheitsrichtlinien-CR mit den Regeln A und B erstellt und die Regeln darin anschließend zu B und C geändert werden, bleibt Regel A weiterhin wirksam.

    Problemumgehung: Sicherheitsrichtlinie löschen und mit aktualisierten Regeln neu erstellen

  • Lastausgleichsdienste und Tanzu Kubernetes-Cluster werden nicht erstellt, wenn zwei SE-Gruppen auf NSX Advanced Load Balancer vorhanden sind.

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

    „get() hat mehr als eine ServiceEngineGroup zurückgegeben – 2 zurückgegeben“

    Infolgedessen können neue Lastausgleichsdienste nicht verwendet werden, und Sie können keine neuen Arbeitslastcluster erstellen.

    Weitere Informationen finden Sie in dem VMware-Knowledgebase-Artikel 90386.

    Problemumgehung: Nur die SE-„Standardgruppe“ sollte für die Erstellung von VirtualService verwendet werden. Löschen Sie alle anderen SE-Gruppen aus NSX Advanced Load Balancer mit Ausnahme der Standardgruppe und wiederholen Sie den Vorgang.

  • Die aktualisierte Sicherheitsrichtlinie wird nicht wirksam.

    Wenn eine Sicherheitsrichtlinien-CR, die die Regeln A und B enthält, erstellt und dann aktualisiert wird, wobei die Regeln in B und C geändert werden, ist Regel A weiterhin wirksam und wird nicht entfernt.

    Problemumgehung: Erstellen Sie eine neue Richtlinie, die die Regeln B und C enthält, und wenden Sie sie an. Löschen Sie die alte Richtlinie, die A und B enthält.

  • Die Namespace-Verwaltungs-API gibt manchmal einen HTTP 500-Fehler zurück und kann eine Anforderung nicht autorisieren

    Eine Anforderung an die Arbeitslastverwaltung schlägt möglicherweise von Zeit zu Zeit fehl. Die API wird mit dem Fehlerstatus 500 zurück, und keine Anforderung wird verarbeitet. Sie finden eine Protokollmeldung mit dem Hinweis „Bei der Autorisierung ist ein unerwarteter Fehler aufgetreten“. Dieses Problem tritt zeitweise auf, das Auftreten des Problems ist jedoch wahrscheinlicher, wenn die Arbeitslastverwaltung ausgelastet ist, z. B. wenn Sie einen oder mehrere Supervisoren aktiv konfigurieren.

    Problemumgehung: Wiederholen Sie den Vorgang, den Sie zum Zeitpunkt des Auftretens des Fehlers versucht haben.

  • Der Supervisor-Cluster verbleibt zeitweise im Status KONFIGURIEREN oder FEHLER.

    Während der Aktivierung, des Upgrades oder der erneuten Knotenbereitstellung bei einem Supervisor-Clusters verbleibt er möglicherweise im Status KONFIGURIEREN oder FEHLER und zeigt die folgende Fehlermeldung an:

    „API-Anforderung an VMware vCenter Server (vpxd) fehlgeschlagen. Details 'ServerFaultCode: Ein allgemeiner Systemfehler ist aufgetreten: vix-Fehlercodes= (1. 0)" kann hängen bleiben.“

    Die relevanten Protokolle finden Sie unter: /var/log/vmware/wcp/wcpsvc.log

    Löschen Sie den mit der betroffenen Steuerungsebenen-VM korrespondierenden vSphere Agent Manager (EAM), um die erneute Bereitstellung des Knotens zu erzwingen.

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

    Nach dem Löschen eines PersistentVolumeClaim (PVC) verbleibt das entsprechende PersistentVolume (PV) in Supervisor möglicherweise in einem beendeten Zustand. Darüber hinaus zeigt der vSphere Client möglicherweise mehrere fehlgeschlagene „deleteVolume“-Aufgaben an.

    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.

Netzwerk

  • Die Bereitstellung von NSX Edge-VMs schlägt in langsamen Netzwerken fehl

    Es gibt eine kombinierte 60-Minuten-Zeitüberschreitung für die NSX Edge OVF-Bereitstellung und die NSX Edge-VM-Registrierung. Wenn in langsameren Netzwerken oder Umgebungen mit langsamerem Speicher der Zeitüberschreitungswert für die Edge-Bereitstellung und die Registrierung von 60 Minuten überschritten wird, schlägt der Vorgang fehl.

    Problemumgehung: Bereinigen Sie Edges und starten Sie die Bereitstellung neu.

  • NSX Edges werden nicht aktualisiert, wenn die DNS-, NTP- oder Syslog-Einstellungen von vCenter Server nach der Clusterkonfiguration geändert werden

    DNS-, NTP- und Syslog-Einstellungen werden während der Clusterkonfiguration von vCenter Server an NSX Edge-VMs kopiert. Wenn diese vCenter Server-Einstellungen nach der Konfiguration geändert werden, werden die NSX Edges nicht aktualisiert.

    Problemumgehung: Verwenden Sie die NSX Manager-APIs, um die DNS-, NTP- und Syslog-Einstellungen Ihrer NSX Edges zu aktualisieren.

  • Die NSX Edge-Verwaltungsnetzwerkkonfiguration stellt nur die Subnetz- und Gateway-Konfiguration auf ausgewählten Portgruppen bereit

    In der Dropdown-Liste für NSX Edge-Verwaltungsnetzwerkkompatibilität werden nur Informationen zu Subnetzen und Gateways angezeigt, wenn ESXi-VMKnics auf dem Host konfiguriert sind, die von einem DVPG auf dem ausgewählten VDS gestützt werden. Wenn Sie eine verteilte Portgruppe ohne angehängte VMKnic auswählen, müssen Sie ein Subnetz und ein Gateway für die Netzwerkkonfiguration bereitstellen.

    Problemumgehung: Verwenden Sie eine der folgenden Konfigurationen:

    • Diskrete Portgruppe: Hier befinden sich derzeit keine VMKs. Sie müssen die entsprechenden Informationen zu Subnetz und Gateway für diese Portgruppe angeben.

    • Gemeinsam genutzte Verwaltungsportgruppe: Hier befindet sich der Verwaltungs-VMK der ESXi-Hosts. Informationen zum Subnetz und zum Gateway werden automatisch abgerufen.

  • VLAN 0 kann während der Clusterkonfiguration nicht verwendet werden

    Wenn Sie versuchen, VLAN 0 für Overlay-Tunnel-Endpoints oder die Uplink-Konfiguration zu verwenden, schlägt der Vorgang mit folgender Meldung fehl:

    Argument 'uplink_network vlan' is not a valid VLAN ID for an uplink network. Please use a VLAN ID between 1-4094

    Problemumgehung: Aktivieren Sie die Unterstützung von VLAN 0 manuell mithilfe eines der folgenden Prozesse:

    1. Melden Sie sich per SSH bei Ihrem bereitgestellten VC an (root/vmware).

    2. Öffnen Sie /etc/vmware/wcp/nsxdsvc.yaml. Es werden Inhalte ähnlich dem folgenden angezeigt: 

    logging: 
  level: debug
  maxsizemb: 10

    a. Um die VLAN 0-Unterstützung für NSX-Cluster-Overlay-Netzwerke zu aktivieren, fügen Sie die folgenden Zeilen an /etc/vmware/wcp/nsxdsvc.yaml an und speichern Sie die Datei.

    experimental:
 supportedvlan: 
  hostoverlay: 
    min: 0 
    max: 4094 
  edgeoverlay: 
    min: 1 
    max: 4094 
  edgeuplink: 
    min: 1 
    max: 4094

    b. Um die VLAN 0-Unterstützung für NSX Edge-Overlay-Netzwerke zu aktivieren, fügen Sie die folgenden Zeilen an /etc/vmware/wcp/nsxdsvc.yaml an und speichern Sie die Datei.

    experimental: 
 supportedvlan: 
  hostoverlay: 
    min: 1 
    max: 4094 
  edgeoverlay: 
    min: 0 
    max: 4094 
  edgeuplink: 
    min: 1 
    max: 4094

    c. Um die VLAN 0-Unterstützung für NSX Edge-Uplink-Netzwerke zu aktivieren, fügen Sie die folgenden Zeilen an /etc/vmware/wcp/nsxdsvc.yaml an und speichern Sie die Datei.

    experimental: 
 supportedvlan: 
  hostoverlay: 
    min: 1 
    max: 4094 
  edgeoverlay: 
    min: 1 
    max: 4094 
  edgeuplink: 
    min: 0 
    max: 4094

    3. Starten Sie den Arbeitslastverwaltungsdienst mit vmon-cli --restart wcp neu.

  • vSphere with Tanzu und NSX-T können nicht in einem Cluster aktiviert werden, in dem vSphere Lifecycle Manager Image aktiviert ist

    vSphere with Tanzu und NSX-T sind nicht mit vSphere Lifecycle Manager Image kompatibel. Sie sind nur mit vSphere Lifecycle Manager-Baselines kompatibel. Wenn vSphere Lifecycle Manager Image in einem Cluster aktiviert ist, können Sie vSphere with Tanzu oder NSX-T in diesem Cluster nicht aktivieren.

    Problemumgehung: Verschieben Sie Hosts in einen Cluster, in dem vSphere Lifecycle Manager Image deaktiviert ist. Sie müssen einen Cluster mit vSphere Lifecycle Manager-Baselines verwenden. Sobald die Hosts verschoben wurden, können Sie NSX-T und dann vSphere with Tanzu in diesem neuen Cluster aktivieren.

  • Wenn das vSphere with Tanzu-Netzwerk mit NSX-T konfiguriert ist, wird „ExternalTrafficPolicy: local“ nicht unterstützt

    Bei einem Kubernetes-Dienst vom Typ „LoadBalancer“ wird die Konfiguration „ExternalTrafficPolicy: local“ für Tanzu Kubernetes-Cluster nicht unterstützt.

    Problemumgehung: Keine.

  • Wenn das vSphere with Tanzu-Netzwerk mit NSX-T konfiguriert ist, ist die Anzahl der Dienste vom Typ „LoadBalancer“, die ein Tanzu Kuberetes-Cluster unterstützen kann, durch den NodePort-Bereich des Supervisor-Clusters beschränkt.

    Jeder VirtualMachineService vom Typ „LoadBalancer“ wird in einen Kubernetes-Dienst vom Typ „LoadBalancer“ und einen Kubernetes-Endpoint übersetzt. Die maximal zulässige Anzahl an Kubernetes-Diensten vom Typ „LoadBalancer“, die in einem Supervisor-Cluster erstellt werden können, beträgt 2767. Dies umfasst die auf dem Supervisor-Cluster und die in Tanzu Kubernetes-Clustern erstellten Dienste.

    Problemumgehung: Keine.

  • NSX Advanced Load Balancer Controller unterstützt nicht das Ändern der vCenter Server-PNID

    Nachdem Sie den Supervisor-Cluster mit dem NSX Advanced Load Balancer konfiguriert haben, können Sie die vCenter Server-PNID nicht ändern.

    Problemumgehung: Wenn Sie die PNID von vCenter Server ändern müssen, entfernen Sie den NSX Advanced Load Balancer Controller und ändern Sie die vCenter Server-PNID. Stellen Sie anschließend den NSX Advanced Load Balancer Controller mit der neuen PNID von vCenter Server erneut bereit und konfigurieren Sie ihn.

  • In vDS-Umgebungen (vSphere Distributed Switch) können Tanzu Kubernetes-Cluster mit CIDR-Netzwerkbereichen konfiguriert werden, die sich überschneiden oder in Konflikt mit denjenigen des Supervisor-Clusters stehen, und umgekehrt. Dies führt dazu, dass Komponenten nicht miteinander kommunizieren können.

    In vDS Umgebungen wird zum Zeitpunkt der Entwicklung des Designs keine Netzwerkvalidierung vorgenommen, wenn Sie die CIDR-Bereiche für den Supervisor-Cluster konfigurieren oder wenn Sie die CIDR-Bereiche für Tanzu Kubernetes-Cluster konfigurieren. Dies führt dazu, dass die folgenden zwei Probleme auftreten können:

    1) Sie erstellen einen Supervisor-Cluster mit CIDR-Bereichen, die mit den für Tanzu Kubernetes-Cluster reservierten CIDR-Standardbereichen in Konflikt stehen.

    2) Sie erstellen einen Tanzu Kubernetes-Cluster mit einem benutzerdefinierten CIDR-Bereich, der sich mit dem für die Supervisor-Cluster verwendeten CIDR-Bereich überschneidet.

    Problemumgehung: Verwenden Sie in vDS-Umgebungen bei der Konfiguration eines Supervisor-Clusters keine der standardmäßigen CIDR-Bereiche, die für Tanzu Kubernetes-Cluster verwendet werden. Dazu gehört der Bereich 192.168.0.0/16, der für Dienste reserviert ist, und der für Pods reservierte Bereich 10.96.0.0/12. Weitere Informationen finden Sie auch unter „Konfigurationsparameter für Tanzu Kubernetes-Cluster“ in der Dokumentation zu vSphere with Tanzu.

    Verwenden Sie in vDS-Umgebungen bei der Erstellung eines Tanzu Kubernetes-Clusters nicht den CIDR-Bereich, der für den Supervisor-Cluster verwendet wird.

  • Das Erstellen eines virtuellen Gast-Cluster-Netzwerks schlägt fehl, wenn mehr als 18 benutzerdefinierte Bezeichnungen angehängt sind

    Wenn der Benutzer Gast-Cluster und VirtualMachines erfolgreich unter einem Namespace erstellen möchte, kann der Benutzer maximal 18 benutzerdefinierte Bezeichnungen für den Namespace hinzufügen. Andernfalls kann das virtuelle Netzwerk für den Gast-Cluster unter dem Namespace nicht erfolgreich erstellt werden.

    Entfernen Sie Bezeichnungen aus dem Namespace, sodass die Gesamtzahl kleiner oder gleich 18 ist. Der NCP-Wiederholungsmechanismus versucht den Namespace erneut und erstellt ihn, aber je nach Intervall kann es bis zu 6 Stunden dauern.

  • Support-Transportzone über die Richtlinien-API für WCP erstellt:

    Wenn eine NSX-Transportzone über die Richtlinien-API erstellt wurde, ist die Supervisor-Aktivierung möglicherweise fehlgeschlagen. Das Erstellen der NSX-Transportzone über die Richtlinien-API wird jetzt unterstützt, während gleichzeitig die Abwärtskompatibilität mit der mit der MP-API erstellten NSX-Transportzone beibehalten wird.

    Behoben in der aktuellen Version.

  • 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-Cloudunterstü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

  • <span style="color:#FF0000">NEU:</span> Versuche, den Vorgang „Festplatte entfernen“ auf einem vSAN Direct-Datenspeicher auszuführen, schlagen mit dem Fehler „VimFault – Vorgang kann nicht abgeschlossen werden“ fehl

    In der Regel tritt dieser Fehler auf, wenn eines der folgenden Szenarien eintritt:

    • Im Rahmen des Vorgangs Festplatte entfernen werden alle persistenten Volumes, die sich auf dem vSAN Direct-Datenspeicher befinden, in einen anderen vSAN Direct-Datenspeicher auf demselben ESXi-Host verlagert. Die Verlagerung kann fehlschlagen, wenn auf den vSAN Direct-Zieldatenspeichern kein Speicherplatz verfügbar ist. Stellen Sie sicher, dass die vSAN Direct-Datenspeicher über ausreichend Speicherplatz für die Ausführung von Anwendungen verfügen.

    • Der Vorgang Festplatte entfernen kann auch fehlschlagen, wenn die vSAN Direct-Zieldatenspeicher auf dem ESXi-Host über ausreichend Speicherplatz verfügen. Dies kann auftreten, wenn der zugrunde liegende Vorgang zur Verlagerung eines persistenten Volumes, der vom übergeordneten Vorgang Festplatte entfernen initialisiert wird, aufgrund der Größe des Volumes länger als 30 Minuten dauert. In diesem Fall können Sie feststellen, dass die Neukonfiguration des zugrunde liegenden vSphere Pods in der Ansicht Aufgaben verbleibt.

      Der Status „Wird ausgeführt“ weist darauf hin, dass die zugrunde liegende Verlagerung eines persistenten Volumes, die durch die Neukonfiguration des vSphere-Pods durchgeführt wird, nicht unterbrochen wird, selbst wenn der Vorgang Festplatte entfernen aufgrund einer Zeitüberschreitung fehlschlägt.

    Problemumgehung:

    Nachdem die Neukonfigurationsaufgabe für den vSphere Pod abgeschlossen ist, führen Sie den Vorgang Festplatte entfernen erneut aus. Der Vorgang Festplatte entfernen wird erfolgreich fortgesetzt.

  • Eine Erweiterung einer Supervisor-Cluster-PVC im Off- oder Onlinemodus führt nicht zu einer Erweiterung einer entsprechenden Tanzu-Kubernetes-Cluster-PVC

    Ein Pod, der die Tanzu Kubernetes-Cluster-PVC verwendet, kann die erweiterte Kapazität der Supervisor-Cluster-PVC nicht nutzen, da das Dateisystem nicht in der Größe angepasst wurde.

    Problemumgehung: Ändern Sie die Größe der Tanzu Kubernetes-Cluster-PVC auf eine Größe, die gleich oder größer ist als die Größe der Supervisor-Cluster-PVC.

  • Nicht übereinstimmende Größe in statisch bereitgestellter TKG-PVC im Vergleich zum zugrunde liegenden Volume

    Bei der statischen Bereitstellung in Kubernetes wird nicht überprüft, ob die Größe der PV- und Backing-Volumes gleich ist. Wenn Sie eine PVC in einem Tanzu-Kubernetes-Cluster statisch erstellen und die PVC-Größe kleiner ist als die Größe der zugrunde liegenden entsprechenden Supervisor-Cluster-PVC, können Sie möglicherweise mehr Speicherplatz verwenden als der von Ihnen in der PV angeforderte Platz. Wenn die Größe der PVC, die Sie statisch im Tanzu Kubernetes-Cluster erstellen, größer ist als die Größe der zugrunde liegenden Supervisor-Cluster-PVC, wird möglicherweise die Fehlermeldung No space left on device angezeigt, noch bevor Sie die angeforderte Größe im Tanzu Kubernetes-Cluster-PV ausschöpfen.

    Problemumgehung:

    1. Ändern Sie im Tanzu Kubernetes-Cluster-PV persistentVolumeReclaimPolicy in Retain.

    2. Notieren Sie sich das volumeHandle des Tanzu-Kubernetes-Cluster-PVs und löschen Sie dann die PVC und das PV im Tanzu-Kubernetes-Cluster.

    3. Erstellen Sie die/das Tanzu Kubernetes-Cluster-PVC und -PV statisch mit dem volumeHandle neu und setzen Sie den Speicher auf die gleiche Größe wie die Größe der entsprechenden Supervisor-Cluster-PVC.

  • Versuche, eine PVC aus einem Supervisor-Namespace oder einem TKG-Cluster zu erstellen, schlagen fehl, wenn der externe csi.vsphere.vmware.com-Bereitsteller seine Lease für die Leader-Auswahl verliert

    Wenn Sie versuchen, mit dem kubectl-Befehl eine PVC aus einem Supervisor-Namespace oder einem TKG-Cluster zu erstellen, sind Ihre Versuche möglicherweise nicht erfolgreich. Die PVC verbleibt möglicherweise im Zustand „Ausstehend“. Wenn Sie die PVC beschreiben, zeigt das Feld „Ereignisse“ die folgenden Informationen im Tabellenlayout an:

    • Typ – Normal

    • Grund – ExternalProvisioning

    • Alter – 56s (x121 over 30m)

    • Von – persistentvolume-controller

    • Meldung – waiting for a volume to be created, either by external provisioner "csi.vsphere.vmware.com" or manually created by system administrator

    Problemumgehung:

    1. Vergewissern Sie sich, dass alle Container im Pod vsphere-csi-controller innerhalb des Namespace vmware-system-csi ausgeführt werden.

      kubectl describe pod vsphere-csi-controller-pod-name -n vmware-system-csi

    2. Überprüfen Sie die Protokolle des externen Bereitstellers mithilfe des folgenden Befehls.

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

      Der folgende Eintrag weist darauf hin, dass der Sidecar-Container für external-provisioner seine Leader-Auswahl verloren hat:

      I0817 14:02:59.582663 1 leaderelection.go:263] failed to renew lease vmware-system-csi/csi-vsphere-vmware-com: failed to tryAcquireOrRenew context deadline exceededF0817 14:02:59.685847 1 leader_election.go:169] stopped leading

    3. Löschen Sie diese Instanz von vsphere-csi-controller.

      kubectl delete pod vsphere-csi-controller-pod-name -n vmware-system-csi

    Kubernetes erstellt eine neue Instanz des CSI-Controllers, und alle Sidecars werden erneut initialisiert.

  • Alle PVC-Vorgänge wie Erstellen, Anhängen, Trennen oder Löschen eines Volumes schlagen fehl, während CSI keine Verbindung zu vCenter Server herstellen kann

    Zusätzlich zu Betriebsfehlern können die Volume-Integritätsinformationen und StoragePool CR im Supervisor-Cluster nicht aktualisiert werden. Die CSI- und Syncer-Protokolle weisen Fehler auf, dass keine Verbindung mit vCenter Server hergestellt werden kann.

    CSI stellt als spezifischer Lösungsbenutzer eine Verbindung zu vCenter Server her. Das Kennwort für diesen SSO-Benutzer wird alle 24 Stunden von wcpsvc rotiert, und das neue Kennwort wird in einen geheimen Schlüssel übertragen, den der CSI-Treiber liest, um die Verbindung mit vCenter Server herzustellen. Wenn das neue Kennwort nicht an den geheimen Schlüssel übermittelt werden kann, verbleibt das veraltete Kennwort im Supervisor-Cluster und der CSI-Treiber schlägt fehl.

    Dieses Problem betrifft die vSAN Data Persistence-Plattform und alle CSI-Volume-Vorgänge.

    Problemumgehung:

    In der Regel stellt der WCP-Dienst das aktualisierte Kennwort an CSI bereit, das im Kubernetes-Cluster ausgeführt wird. Gelegentlich erfolgt die Kennwortbereitstellung nicht aufgrund eines Problems, z. B. eines Konnektivitätsproblems oder eines Fehlers in einem früheren Teil des Synchronisierungsvorgangs. CSI verwendet weiterhin das alte Kennwort und sperrt schließlich das Konto aufgrund zu vieler Authentifizierungsfehler.

    Stellen Sie sicher, dass sich der WCP-Cluster in einem fehlerfreien und ausgeführten Zustand befindet. Es sollten keine Fehler für diesen Cluster auf der Seite „Arbeitslastverwaltung“ gemeldet werden. Nachdem die Probleme behoben wurden, die zum Fehlschlagen der Synchronisierung führten, erzwingen Sie eine Kennwortaktualisierung, um das gesperrte Konto zu entsperren.

    So erzwingen Sie das Zurücksetzen des Kennworts:

    1. Beenden Sie wcpsvc:

      vmon-cli -k wcp

    2. Ändern Sie den Zeitpunkt der letzten Kennwortrotation in einen kleinen Wert (z. B. 1), indem Sie die dritte Zeile /etc/vmware/wcp/.storageUser in 1 ändern.

    3. Starten Sie wcpsvc:

      vmon-cli -i wcp

    wcpsvc setzt das Kennwort zurück, wodurch das Konto entsperrt und das neue Kennwort an den Cluster übermittelt wird.

VMware Tanzu Kubernetes Grid Service for vSphere

  • Ein Tanzu Kubernetes-Cluster bleibt nach dem Supervisor-Cluster-Upgrade im Zustand „Aktualisierung läuft“ hängen

    Wenn ein Upgrade eines Supervisor-Clusters durchgeführt wird, löst dies möglicherweise ein paralleles Update aller Tanzu Kubernetes-Cluster zur Weitergabe neuer Konfigurationseinstellungen aus. Während dieses Vorgangs kann es passieren, dass ein TKC-Cluster, der sich zuvor im Zustand „Wird ausgeführt“ befand, in der Phase „Aktualisierung läuft“ hängen bleibt. Ein Tanzu Kubernetes-Cluster im Zustand „Wird ausgeführt“ weist nur auf die Verfügbarkeit der Steuerungsebene hin, und es ist möglich, dass die erforderliche Steuerungsebene und die zugehörigen Worker-Knoten nicht erfolgreich erstellt wurden. Ein solcher Tanzu Kubernetes-Cluster besteht die Integritätsprüfungen, die während des nach Abschluss des Supervisor-Cluster-Upgrades initiierten parallelen Updates durchgeführt werden, möglicherweise nicht. Dies führt dazu, dass der Tanzu Kubernetes-Cluster in der Phase „Aktualisierung läuft“ hängen bleibt. Dies kann bestätigt werden, indem die Ereignisse in den dem Tanzu Kubernetes-Cluster zugeordneten KubeadmControlPlane -Ressourcen überprüft werden. Die von der Ressource ausgegebenen Ereignisse ähneln den folgenden Beispielen:

    Warning ControlPlaneUnhealthy 2m15s (x1026 over 5h42m) kubeadm-control-plane-controller Waiting for control plane to pass control plane health check to continue reconciliation: machine's (gc-ns-1597045889305/tkg-cluster-3-control-plane-4bz9r) node (tkg-cluster-3-control-plane-4bz9r) was not checked

    Problemumgehung: Keine.

  • Tanzu Kubernetes-Cluster greift weiterhin auf die entfernte Speicherrichtlinie zu

    Wenn ein VI-Administrator eine Speicherklasse aus dem vCenter Server-Namespace löscht, wird der Zugriff auf diese Speicherklasse für keinen Tanzu Kubernetes-Cluster entfernt, der diese bereits verwendet.

    Problemumgehung:

    1. Erstellen Sie als VI-Administrator nach dem Löschen einer Speicherklasse aus dem vCenter Server-Namespace eine neue Speicherrichtlinie mit demselben Namen.

    2. Fügen Sie die vorhandene Speicherrichtlinie oder die soeben neu erstellte erneut zum Supervisor-Namespace hinzu. TanzuKubernetesCluster-Instanzen, die diese Speicherklasse verwenden, sollten jetzt vollständig funktionsfähig sein.

    3. Erstellen Sie für jede TanzuKubernetesCluster-Ressource mit der Speicherklasse, die Sie löschen möchten, eine neue TanzuKubernetesCluster-Instanz mit einer anderen Speicherklasse und verwenden Sie Velero, um Arbeitslasten in den neuen Cluster zu migrieren.

    4. Wenn kein TanzuKubernetesCluster oder PersistentVolume mehr die Speicherklasse verwendet, kann sie sicher entfernt werden.

  • Das SSL-Zertifikat der eingebetteten Containerregistrierung wird nicht an Tanzu Kubernetes-Clusterknoten kopiert

    Wenn die eingebettete Containerregistrierung für einen Supervisor-Cluster aktiviert ist, wird das Harbor-SSL-Zertifikat in keinem der auf diesem SC erstellten Tanzu Kubernetes-Clusterknoten eingeschlossen, und Sie können keine Verbindung zur Registrierung über diese Knoten herstellen.

    Problemumgehung: Kopieren Sie das SSL-Zertifikat von der Supervisor-Cluster-Steuerungsebene und fügen Sie es in die Worker-Knoten des Kubernetes-Clusters ein.

  • VM-Images sind in der Inhaltsbibliothek nicht verfügbar

    Wenn in einem Setup im eingebetteten verknüpften Modus mehrere vCenter Server-Instanzen konfiguriert sind, kann der Benutzer über die Benutzeroberfläche eine Inhaltsbibliothek auswählen, die auf einer anderen vCenter Server-Instanz erstellt wurde. Die Auswahl einer solchen Bibliothek führt dazu, dass DevOps-Benutzern die VM-Images nicht für die Bereitstellung des Tanzu Kubernetes-Clusters zur Verfügung stehen. In diesem Fall gibt „kubectl get virtualmachineimages“ keine Ergebnisse zurück.

    Problemumgehung: Wählen Sie beim Zuordnen einer Inhaltsbibliothek zum Supervisor-Cluster für VM-Images des Tanzu Kubernetes-Clusters eine Bibliothek aus, die auf derselben vCenter Server-Instanz erstellt wurde, auf der sich der Supervisor-Cluster befindet. Alternativ können Sie eine lokale Inhaltsbibliothek erstellen, die auch die Air-Gap-Bereitstellung von Tanzu Kubernetes-Clustern unterstützt.

  • Sie können keine neuen Tanzu Kubernetes-Cluster bereitstellen oder vorhandene Cluster horizontal hochskalieren, weil der Abonnent der Inhaltsbibliothek nicht mit dem Herausgeber synchronisiert werden kann

    Beim Einrichten einer abonnierten Inhaltsbibliothek für Tanzu Kubernetes-Cluster-OVAs wird ein SSL-Zertifikat erstellt und Sie werden aufgefordert, das Zertifikat manuell als vertrauenswürdig einzustufen, indem Sie den Zertifikatfingerabdruck bestätigen. Wenn das SSL-Zertifikat nach der ersten Einrichtung der Bibliothek geändert wird, muss das neue Zertifikat erneut als vertrauenswürdig eingestuft werden, indem der Fingerabdruck aktualisiert wird.

    Bearbeiten Sie die Einstellungen der abonnierten Inhaltsbibliothek. Hierdurch wird ein Test der Abonnement-URL initiiert, obwohl keine Änderung für die Bibliothek angefordert wird. Der Test erkennt, dass das SSL-Zertifikat nicht als vertrauenswürdig eingestuft ist und fordert Sie dazu auf, es als vertrauenswürdig einzustufen.

  • Tanzu Kubernetes Version 1.16.8 ist nicht kompatibel mit vCenter Server 7.0 Update 1

    Tanzu Kubernetes Version 1.16.8 ist nicht kompatibel mit vCenter Server 7.0 Update 1. Sie müssen Tanzu Kubernetes-Cluster auf eine höhere Version aktualisieren, bevor Sie ein Update von vSphere-Namespaces auf U1 durchführen.

    Aktualisieren Sie vor dem Durchführen eines Updates der vSphere-Namespaces auf die Version vCenter Server 7.0 Update 1 alle Tanzu Kubernetes-Cluster, auf denen Version 1.16.8 ausgeführt wird, auf eine höhere Version. Weitere Informationen finden Sie in der Liste der Tanzu Kubernetes-Versionen in der Dokumentation.

  • Nach dem Upgrade der Steuerungsebene für Arbeitslasten auf vCenter Server 7.0 Update 1 sind die neuen VM-Klassengrößen nicht verfügbar

    Beschreibung: Nach dem Upgrade auf vSphere 7.0.1 und dem anschließenden Durchführen einer vSphere-Namespaces-Aktualisierung des Supervisor-Clusters, führt bei Tanzu Kubernetes-Clustern das Ausführen des Befehls „kubectl get virtualmachineclasses“ nicht zur Auflistung der neuen VM-Klassengrößen „2x-large“, „4x-large“ und „8x-large“.

    Problemumgehung: Keine. Die neuen VM-Klassengrößen können nur mit einer neuen Installation der Steuerungsebene für Arbeitslasten verwendet werden.

  • Bei Tanzu Kubernetes Version 1.17.11 vmware.1-tkg.1 tritt eine Zeitüberschreitung auf, wenn eine Verbindung zum Cluster-DNS-Server hergestellt wird, während die Calico-CNI verwendet wird

    Tanzu Kubernetes Version v1.17.11+vmware.1-tkg.1 weist ein Problem mit dem Photon OS-Kernel auf, das verhindert, dass das Image in Verbindung mit der Calico-CNI wie erwartet funktioniert.

    Problemumgehung: Bei Tanzu Kubernetes Version 1.17.11 wird das Calico-Problem mit dem als „v1.17.11+vmware.1-tkg.2.ad3d374.516“ identifizierten Image behoben. Verwenden Sie zum Ausführen von Kubernetes 1.17.11 diese Version anstelle von „v1.17.11+vmware.1-tkg.1.15f1e18.489“. Alternativ können Sie auch eine andere Version von Tanzu Kubernetes verwenden, z. B. 1.18.5, 1.17.8 oder 1.16.14.

  • Wenn das vSphere with Tanzu-Netzwerk mit NSX-T Data Center konfiguriert ist, führt die Aktualisierung eines „ExternalTrafficPolicy: Local“-Diensts auf „ExternalTrafficPolicy: Cluster“ dazu, dass der Zugriff auf die LB-IP dieses Diensts auf SV-Mastern nicht mehr möglich ist

    Wenn ein Kubernetes-Dienst vom Typ „LoadBalancer“ anfänglich in Arbeitslast-Clustern mit ExternalTrafficPolicy: Local erstellt und später auf ExternalTrafficPolicy: Cluster aktualisiert wird, wird der Zugriff auf die LoadBalancer-IP dieses Diensts auf den Supervisor-Cluster-VMs verworfen.

    Problemumgehung: Löschen Sie den Dienst und erstellen Sie ihn mit ExternalTrafficPolicy: Cluster neu.

  • Hohe CPU-Auslastung auf Tanzu Kubernetes-Cluster-Steuerungsebenenknoten

    Im Kubernetes-Upstream-Projekt liegt ein bekanntes Problem vor, bei dem kube-controller-manager gelegentlich in eine Schleife geschaltet wird, was zu einer hohen CPU-Auslastung führt, die sich auf die Funktionalität von Tanzu Kubernetes-Clustern auswirken kann. Möglicherweise bemerken Sie, dass der Prozess kube-controller-manager einen höheren CPU-Anteil als erwartet verbraucht und wiederholt Protokolle mit der Angabe failed for updating Node.Spec.PodCIDRs ausgibt.

    Problemumgehung: Löschen Sie den kube-controller-manager-Pod, der sich innerhalb des Steuerungsebenenknotens befindet, bei dem ein solches Problem auftritt. Der Pod wird neu erstellt, und das Problem sollte nicht erneut auftreten.

  • Mit K8s 1.16 bis 1.19 erstellte Tanzu Kubernetes-Cluster können nicht aktualisiert werden

    Die Konfigurationsdatei von Kubelet wird während der Ausführung von kubeadm init generiert und dann während Cluster-Upgrades repliziert. Bei 1.16 generiert kubeadm init eine Konfigurationsdatei, die resolvConf auf /etc/resolv.conf festlegt. Diese Einstellung wird dann vom Befehlszeilen-Flag --resolv-conf überschrieben, das auf /run/systemd/resolve/resolv.conf verweist. In 1.17 und 1.18 konfiguriert kubeadm Kubelet weiterhin mit der korrekten --resolv-conf. Ab 1.19 konfiguriert kubeadm das Befehlszeilen-Flag nicht mehr und ist stattdessen auf die Kubelet-Konfigurationsdatei angewiesen. Aufgrund des Replizierungsvorgangs während der Cluster-Upgrades enthält ein von 1.16 aktualisierter 1.19-Cluster eine Konfigurationsdatei, in der resolvConf auf /etc/resolv.conf statt auf /run/systemd/resolve/resolv.conf verweist.

    Problemumgehung: Konfigurieren Sie vor dem Upgrade eines Tanzu Kubernetes-Clusters auf 1.19 die Kubelet-Konfigurationsdatei so neu, dass sie auf die richtige resolv.conf verweist. Duplizieren Sie ConfigMap kubelet-config-1.18 manuell im kube-system-Namespace auf kubelet-config-1.19 und ändern Sie dann die neuen ConfigMap's-Daten so, dass sie auf resolvConf bei /run/systemd/resolve/resolv.conf verweisen.

  • Wenn das Supervisor-Cluster-Netzwerk mit NSX-T konfiguriert ist und nachdem ein Dienst von „ExternalTrafficPolicy: Local“ auf „ExternalTrafficPolicy: Cluster“ aktualisiert wird, schlagen Anforderungen auf den Supervisor-Cluster-Steuerungsebenenknoten an die Lastausgleichsdienst-IP dieses Diensts fehl

    Wenn Sie einen Dienst auf einem Tanzu Kubernetes-Cluster mit ExternalTrafficPolicy: Local erstellen und den Dienst später auf ExternalTrafficPolicy: Cluster aktualisiert haben, erstellt kube-proxy fälschlicherweise eine IP-Tabellenregel auf den Knoten der Steuerungsebene des Supervisor-Clusters, um Datenverkehr zu blockieren, der für die LoadBalancer-IP des Diensts bestimmt ist. Wenn dieser Dienst beispielsweise die LoadBalancer-IP 192.182.40.4 hat, wird die folgende IP-Tabellenregel auf jedem Steuerungsebenenknoten erstellt:

    -A KUBE-SERVICES -d 192.182.40.4/32 -p tcp -m comment --comment "antrea-17-171/antrea-17-171-c1-2bfcfe5d9a0cdea4de6eb has no endpoints" -m tcp --dport 80 -j REJECT --reject-with icmp-port-unreachable

    Dies führt dazu, dass der Zugriff auf diese IP-Adresse verworfen wird.

    Problemumgehung: Löschen Sie den Dienst und erstellen Sie ihn mit ExternalTrafficPolicy: Cluster neu.

  • Nachdem Sie die HTTP-Proxy- und/oder Vertrauensstellungseinstellungen in der TkgServiceConfiguration-Spezifikation aktiviert haben, übernehmen alle bereits vorhandenen Cluster ohne Proxy-/Vertrauenseinstellungen die globalen Proxy-/Vertrauenseinstellungen, wenn sie aktualisiert werden.

    Sie können die TkgServiceConfiguration-Spezifikation bearbeiten, um den TKG-Dienst zu konfigurieren, einschließlich der Angabe der standardmäßigen CNI-, HTTP-Proxy- und Vertrauenszertifikate. Alle Konfigurationsänderungen, die Sie an der TkgServiceConfiguration-Spezifikation vornehmen, gelten global für alle von diesem Dienst bereitgestellten oder aktualisierten Tanzu Kubernetes-Cluster. Sie können die globale Konfiguration nicht mithilfe von Einstellungen per Cluster deaktivieren.

    Wenn Sie beispielsweise die TkgServiceConfiguration-Spezifikation bearbeiten und einen HTTP-Proxy aktivieren, übernehmen alle von diesem Cluster bereitgestellten neuen Cluster diese Proxy-Einstellungen. Darüber hinaus übernehmen alle bereits vorhandenen Cluster ohne Proxyserver die globale Proxy-Konfiguration, wenn der Cluster geändert oder aktualisiert wird. Im Falle eines HTTP/S-Proxys, der die Konfiguration per Cluster unterstützt, können Sie die Clusterspezifikation mit einem anderen Proxyserver aktualisieren, Sie können die globale Proxy-Einstellung jedoch nicht entfernen. Wenn der HTTP-Proxy global festgelegt ist, müssen Sie ihn entweder verwenden oder mit einem anderen Proxyserver überschreiben.

    Problemumgehung: Sie müssen sich darüber im Klaren sein, dass die TkgServiceConfiguration-Spezifikation global angewendet wird. Wenn Sie nicht möchten, dass alle Cluster einen HTTP-Proxy verwenden, aktivieren Sie ihn nicht auf globaler Ebene. Tun Sie dies auf Clusterebene.

  • In sehr großen Supervisor-Cluster-Bereitstellungen mit vielen Tanzu Kubernetes-Clustern und -VMs können vmop-controller-manager-Pods aufgrund von OutOfMemory-Ereignissen fehlschlagen, was dazu führt, dass der Lebenszyklus von Tanzu Kubernetes-Clustern nicht verwaltet werden kann

    Innerhalb des Supervisor-Clusters ist der vmop-controller-manager-Pod für die Verwaltung des Lebenszyklus der VMs zuständig, aus denen Tanzu Kubernetes-Cluster gebildet werden. Bei einer sehr großen Anzahl solcher VMs (mehr als 850 VMs pro Supervisor-Cluster) kann es passieren, dass der vmop-controller-manager-Pod in einen Zustand des Typs „OutOfMemory CrashLoopBackoff“ wechselt. Wenn dies eintritt, wird die Lebenszyklusverwaltung von Tanzu Kubernetes-Clustern unterbrochen, bis der vmop-controller-manager-Pod wieder ordnungsgemäß funktioniert.

    Reduzieren Sie die Gesamtzahl der in einem Supervisor-Cluster verwalteten Tanzu Kubernetes-Cluster-Worker-Knoten, indem Sie Cluster entweder löschen oder herunterskalieren.

  • Beim Upgrade von einer vSphere-Version vor 6.5 auf vSphere 7 with Tanzu kann ein Fehler ausgegeben werden, der darauf hinweist, dass der PhotonOS-Typ nicht unterstützt wird.

    Nach dem erfolgreichen Upgrade einer vSphere 6-Umgebung auf vSphere 7 with Tanzu führt der Versuch, einen Tanzu Kubernetes-Cluster bereitzustellen, zu der Fehlermeldung, dass PhotonOS „nicht unterstützt“ wird. Speziell:

    Erstellen oder Aktualisieren von VirtualMachine fehlgeschlagen: Zulassungswebhook „default.validating.virtualmachine.vmoperator.vmware.com“ hat die Anforderung abgelehnt: GuestOS wird für osType „vmwarePhoton64Guest“ auf Image „v1.19.7---vmware.1-tkg.1.fc82c41'“ nicht unterstützt

    Wenn Sie ein Upgrade auf vSphere 7 with Tanzu von einer vSphere-Version durchgeführt haben, die älter als vSphere 6.5 ist (z. B. vSphere 6), müssen Sie sicherstellen, dass für die Standard-VM-Kompatibilitätsebene mindestens „ESXi 6.5 und höher“ eingestellt ist, damit PhotonOS als unterstütztes Gastbetriebssystem angezeigt wird. Wählen Sie dazu den vSphere-Cluster, in dem die Arbeitslastverwaltung aktiviert ist, klicken Sie mit der rechten Maustaste und wählen Sie „Standard-VM-Kompatibilität bearbeiten“ aus. Wählen Sie „ESXi 6.5 und höher“ aus.

  • Nach der Bereitstellung eines Tanzu Kubernetes-Clusters mithilfe einer kleinen VM und der anschließenden Bereitstellung einer Arbeitslast in diesem Cluster wechselt der Worker-Knoten in den Status „NotReady“ und in eine fortlaufende Schleife, in der versucht wird, den Knoten neu zu starten.

    Beschreibung: Auf einem kleinen oder besonders kleinen Worker-Knoten für einen Cluster verbraucht der /bin/opm-Prozess möglicherweise einen zu großen Teil des VM-Arbeitsspeichers, was zu einem Fehler wegen zu wenig Arbeitsspeicher für den Worker-Knoten führt.

    Problemumgehung: Vermeiden Sie die Verwendung der kleinen oder besonders kleinen VM-Klasse für Worker-Knoten, selbst für kurzlebige Entwicklungs- oder Testcluster. Als Best Practice wird empfohlen, dass die Mindest-VM-Klasse für einen Worker-Knoten in einer beliebigen Umgebung „Mittel“ ist. Weitere Informationen finden Sie unter Standard-VM-Klassen in der Dokumentation.

  • Die Synchronisierung von Tanzu Kubernetes-Versionen aus einer abonnierten Inhaltsbibliothek schlägt mit der folgenden HTTP-Anforderungsfehlermeldung fehl: „SSL-Zertifikat für Host wp-content.vmware.com kann nicht authentifiziert werden.“

    Beschreibung: Wenn Sie eine abonnierte Inhaltsbibliothek für Tanzu Kubernetes-Cluster-OVAs konfigurieren, wird ein SSL-Zertifikat für wp-content.vmware.com generiert. Sie werden aufgefordert, dem Zertifikat manuell zu vertrauen, indem Sie den Fingerabdruck des Zertifikats bestätigen. Wenn das SSL-Zertifikat nach der ersten Einrichtung der Bibliothek geändert wird, muss das neue Zertifikat erneut als vertrauenswürdig eingestuft werden, indem der Fingerabdruck aktualisiert wird. Das aktuelle SSL-Zertifikat für die Inhaltsbibliothek läuft zum Monatsende im Juni 2021 ab. Kunden, die wp-content.vmware.com abonniert haben, werden bemerken, dass ihre Synchronisierung der Inhaltsbibliothek fehlschlägt, und müssen den Fingerabdruck aktualisieren, indem sie die Schritte in der Problemumgehung ausführen. Zusätzliche Orientierungshilfe erhalten Sie im zugehörigen VMware-Knowledgebase-Artikel auf https://kb.vmware.com/s/article/85268.

    Problemumgehung: Melden Sie sich über den vSphere Client bei vCenter Server an. Wählen Sie die abonnierte Inhaltsbibliothek aus und klicken Sie auf Einstellungen bearbeiten. Hierdurch wird ein Test der Abonnement-URL initiiert, obwohl keine Änderung für die Bibliothek angefordert wird. Der Test erkennt, dass das SSL-Zertifikat nicht als vertrauenswürdig eingestuft ist und fordert Sie dazu auf, es als vertrauenswürdig einzustufen. Wählen Sie im angezeigten Dropdown-Menü Aktionen die Option Fortfahren aus, und der Fingerabdruck wird aktualisiert. Jetzt können Sie mit der Synchronisierung der Inhalte der Bibliothek fortfahren.

  • TKGS unterstützt keine gleichzeitige Änderung der vertikalen Skalierung von VM-Klasse und -Knoten.

    Kunden sehen möglicherweise Fehler, nachdem ein Update auf den Cluster angewendet wurde, das sowohl eine VMClass-Änderung als auch eine vertikale Skalierung des Knotens beinhaltet.

    Ändern Sie die TKC-Konfiguration, damit nur eines der beiden Felder geändert wird, und wenden Sie die Änderung erneut an.

  • Symptom: Nach dem Aktualisieren einer Bezeichnung oder eines Merkmals in der Clusterspezifikation ist ein unerwartetes paralleles Update des Clusters aufgetreten.

    Beschreibung: Wenn Sie die TKGS-v1alpha2-API verwenden und spec.topology.nodePools[*].labels oder spec.topology.nodePools[*].taints eines Knotenpools ändern, wird ein paralleles Update dieses Knotenpools ausgelöst.

    Problemumgehung: Keine

  • Symptom: Nach einem Cluster-Update sind die manuell zu einem Knotenpool hinzugefügten Merkmale und Bezeichnungen nicht mehr vorhanden.

    Beschreibung: Bei Verwendung der TKGS-v1alpha2-API während eines Cluster-Updates behält das System spec.topology.nodePools[*].taints und spec.topology.nodePools[*].labels, die vor dem Update manuell hinzugefügt wurden und vorhanden waren, nicht bei.

    Problemumgehung: Fügen Sie nach Abschluss des Updates die Bezeichnungs- und Markierungsfelder manuell wieder hinzu.

  • Symptom: Der Tanzu Kubernetes-Cluster bleibt in einer Erstellungsphase hängen, da eine der VMs der Steuerungsebene keine IP-Adresse erhalten hat.

    Beschreibung: Tanzu Kubernetes-Cluster bleibt in einer Erstellungsphase hängen, da eine der VMs der Steuerungsebene keine IP-Adresse erhalten hat.

    Problemumgehung: Verwenden Sie Tanzu Kubernetes Version 1.20.7 oder höher, um dieses Problem zu vermeiden.

  • Symptom: Während der Erstellung eines Tanzu Kubernetes-Clusters bleibt der Prozess in einem Aktualisierungsstatus mit dem Grund „WaitingForNetworkAddress“ hängen.

    Beschreibung: Die VMs der Steuerungsebene und Worker-Knoten sind eingeschaltet, ihnen ist jedoch keine IP-Adresse zugewiesen. Dies kann darauf zurückzuführen sein, dass vmware-tools nicht mehr über genügend Arbeitsspeicher verfügt und nicht neu gestartet wird.

    Problemumgehung: Das spezifische Problem wurde in den Tanzu Kubernetes-Versionen v1.20.7 und höher behoben. Darüber hinaus können Sie das Problem beheben, indem Sie den VM-Arbeitsspeicher vergrößern. Die VM-Klasse best-effort-xsmall bietet nur 2 GB Arbeitsspeicher. Verwenden Sie eine VM-Klasse mit mehr Arbeitsspeicher, um Tanzu Kubernetes-Cluster bereitzustellen.

  • Symptom: Self-Service-vSphere-Namespaces bleiben im Status „Wird entfernt“ hängen.

    Beschreibung: Nach dem Löschen eines vSphere-Namespace bleibt der Prozess mehrere Stunden lang im Zustand „Wird entfernt“ hängen, ohne dass er weiterläuft.

    Problemumgehung: Verwenden Sie kubectl, um nach verbleibenden Kubernetes-Objekten zu suchen, die noch nicht aus dem Namespace gelöscht wurden. Wenn noch Objekte im Zusammenhang mit kubeadm-control-plane vorhanden sind, starten Sie die Pods capi-kubeadm-control-plane-controller-manager neu. Mit dieser Aktion sollten die zu löschenden Objekte erneut in die Warteschlange gestellt werden.

    HINWEIS: Dies ist ein erweiterter Vorgang. Wenden Sie sich an den VMware Support, bevor Sie diese Problemumgehung durchführen.

  • TKC v1alpha2-API blockiert nicht die Erstellung von TKC mit inkompatibler TKr

    Ab Version 7.0.3 MP2 ist TKr <1.18.x nicht mehr kompatibel, aber die TKC-API lässt weiterhin die Erstellung von TKCs mit einer Version vor v1.18.x zu. Sie blockiert nicht die Erstellung eines TKC-Objekts, wenn es mit einer inkompatiblen TKr erstellt wird. Diese TKC wird nie erstellt.

    Löschen Sie TKCs, die nicht im ausgeführten Zustand befinden und mit inkompatibler TKr erstellt wurden. Und mit einer kompatiblen Version neu erstellen.

vSAN Data Persistence-Plattform

  • Ein vDPP-UI-Plug-In wird im vSphere Client nicht bereitgestellt, und eine Fehlermeldung weist darauf hin, dass versucht wurde, das Plug-In von einem nicht mehr vorhandenen Supervisor-Cluster aus herunterzuladen

    Das Problem tritt möglicherweise auf, wenn Sie ein vDPP-UI-Plug-In auf einem Cluster bereitstellen und diesen Cluster dann entfernen. Die veralteten Einträge im Zusammenhang mit diesem vDPP-UI-Plug-In verbleiben jedoch im vCenter Extension Manager. Wenn Sie später einen neuen Cluster erstellen, schlagen Ihre Versuche, dieselbe Version des vDPP-UI-Plug-Ins auf diesem Cluster zu installieren, fehl, da der vSphere Client die veralteten Einträge verwendet, um das Plug-In aus dem alten, nicht mehr vorhandenen Cluster herunterzuladen.

    Problemumgehung:

    1. Navigieren Sie mit https://vc-ip/mob and zum vCenter Extension Manager und suchen Sie die Plug-In-Erweiterung.

    2. Entfernen Sie alle ClientInfo- und ServerInfo-Einträge, die den Namen des alten Clusters enthalten.

    3. Wählen Sie im Array ClientInfo die ClientInfo mit der höchsten Versionsnummer aus und ändern Sie ihren Typ von vsphere-client-remote-backup in vsphere-client-remote.

  • Ein vSphere-Pod in einem Supervisor-Cluster bleibt ohne die vm-uuid-Anmerkung im Status „Ausstehend“

    Gelegentlich verbleibt ein Pod möglicherweise für lange Zeit im Status „Ausstehend“. Dies tritt in der Regel auf, wenn Sie eine vSAN Data Persistence-Plattform (vDPP) verwenden, und kann durch einen internen Fehler oder Benutzeraktionen verursacht werden.

    Wenn Sie den kubectl-Befehl zum Abfragen der Pod-Instanz verwenden, fehlt die Anmerkung vmware-system-vm-uuid/vmware-system-vm-moid in den Metadatenanmerkungen.

    Problemumgehung: Verwenden Sie den kubectl delete pod pending_pod_name-Befehl, um den Pod zu löschen. Wenn der Pod Teil eines statusbehafteten Satzes ist, wird der Pod automatisch neu erstellt.

  • Eine Instanz eines vDPP-Diensts kann nicht bereitgestellt werden, wenn lokale Host-PVCs der beiden Replikat-Pods an denselben Clusterknoten gebunden sind

    Gelegentlich kann es vorkommen, dass eine Instanz eines vSAN Data Persistence Platform-Diensts, wie z. B. MinIO oder Cloudian, in einen Zustand versetzt wird, bei dem den beiden Replikat-Pods die lokalen Host-PVCs auf demselben Clusterknoten zugeteilt sind. Normalerweise können keine zwei Replikate derselben Instanz über lokalen Hostspeicher auf demselben Clusterknoten verfügen. In diesem Fall verbleibt einer der Replikat-Pods möglicherweise für eine unbestimmte Zeit im Status „Ausstehend“, was zu Fehlern bei der Bereitstellung der Instanz führt.

    Zu den Symptomen, die Sie während der Fehler beobachten, gehören alle folgenden:

    • Instanzintegrität ist gelb.

    • Mindestens ein Pod der Instanz verbleibt für mehr als 10 Minuten im Status „Ausstehend“.

    • Dem ausstehenden Pod und einem der ausgeführten Replikat-Pods derselben Instanz werden ihre lokalen Host-PVCs auf demselben Knoten des Clusters zugeteilt.

    Die Fehlerszenarien, die zu diesem Problem führen können, sehen folgendermaßen aus:

    • Einige Knoten im Cluster verfügen nicht über ausreichende Speicherressourcen für die Instanz.

    • Die Anzahl der Replikate ist größer als die Anzahl der Knoten im Cluster. Dies kann daran liegen, dass ein oder mehrere Knoten vorübergehend nicht verfügbar sind.

    Problemumgehung:

    1. Stellen Sie sicher, dass Ihr Cluster über ausreichend Speicherressourcen verfügt und die Anzahl der Clusterknoten höher als die Anzahl der Instanzreplikate ist.

    2. Löschen Sie den ausstehenden Pod und alle zugehörigen lokalen Host-PVCs.

    Der Dienstoperator sollte die Volume-Daten auf dem neuen Knoten neu erstellen, auf dem der Pod geplant wird. Je nach Größe des Volumes und der Menge der darauf gespeicherten gültigen Daten kann dies einige Zeit in Anspruch nehmen.

  • Nachdem die Wartung eines ESXi-Knoten im Modus „Zugriff sicherstellen“ beendet wurde, bleibt das während der Wartung auf den Knoten angewendete Merkmal (Taint) möglicherweise weiterhin auf dem Knoten erhalten

    Dieses Problem tritt möglicherweise auf, wenn vSAN Data Persistence Platform (vDPP) zum Erstellen von Instanzen von Partnerdiensten verwendet wird. Nachdem die Wartung des ESXi-Knotens im Modus „Zugriff sicherstellen“ beendet wurde, ist das verbleibende Merkmal (Taint) node.vmware.com/drain=planned-downtime:NoSchedule immer noch auf dem Knoten vorhanden.

    Normalerweise tritt das Problem bei folgenden Aktionen auf:

    1. Ein Partnerdienst ist auf dem Supervisor-Cluster aktiviert, und Instanzen des Diensts werden erstellt.

    2. Ein ESXi-Knoten wird im Modus „Zugriff sicherstellen“ in den Wartungsmodus versetzt.

    3. Der Knoten wechselt im Modus „Zugriff sicherstellen“ erfolgreich in den Wartungsmodus.

    4. Das Merkmal (Taint) node.vmware.com/drain=planned-downtime:NoSchedule wird auf den Knoten angewendet.

    5. Der Knoten verlässt den Wartungsmodus.

    Nachdem der Knoten den Wartungsmodus verlassen hat, verwenden Sie den folgenden Befehl, um sicherzustellen, dass kein Merkmal (Taint) mehr auf dem Knoten verbleibt:

    kubectl describe node | grep Taints

    Problemumgehung:

    Wenn das Merkmal node.vmware.com/drain=planned-downtime:NoSchedule auf dem Host vorhanden ist, entfernen Sie es manuell:

    kubectl taint nodes nodeNamekey=value:Effect-

    Hinweis: Stellen Sie sicher, dass am Ende des Befehls ein Bindestrich steht.

    Gehen Sie wie im folgenden Beispiel vor:

    kubectl taint nodes wdc-10-123-123-1.eng.vmware.com node.vmware.com/drain=planned-downtime:NoSchedule-

  • Nach einer APD-Wiederherstellung verbleiben persistente Dienst-Pods, die auf der vSAN Data Persistence-Plattform ausgeführt werden, möglicherweise im Status „Ausstehend“ mit AttachVolume-Fehlern

    Nach der ADP- und Wiederherstellung von ESXi-Hosts verbleibt ein vDPP-Dienstinstanz-Pod möglicherweise im Status „Ausstehend“. Wenn Sie den Befehl kubectl -n instance_namespace describe pod name_of_pod_in_pending ausführen, können Sie die AttachVolume-Fehler anzeigen.

    Wenn der Pod länger als 15 Minuten im Status „Ausstehend“ verbleibt, ist es unwahrscheinlich, dass er diesen Status verlässt.

    Problemumgehung: Löschen Sie den ausstehenden Pod mit dem folgenden Befehl: kubectl -n instance_namespace delete pod name_of_pod_in_pending. Der Pod wird neu erstellt und sollte in den Status „Wird ausgeführt“ versetzt werden.

VM-Dienst

  • <span style="color:#FF0000">NEU:</span> Versuche, einen vSphere-Pod und eine VM-Dienst-VM mit demselben Namen bereitzustellen, verursachen Fehler und unvorhersehbares Verhalten

    Möglicherweise treten Fehler oder ein anderes problematisches Verhalten auf. Diese Probleme können auftreten, wenn ein vSphere-Pod in einem Namespace ausgeführt wird und Sie dann versuchen, eine VM-Dienst-VM mit demselben Namen im selben Namespace bereitzustellen, oder umgekehrt.

    Problemumgehung: Verwenden Sie nicht dieselben Namen für die vSphere-Pods und -VMs im selben Namespace.

  • Ein begrenzter Satz von VM-Images steht für die Nutzung mit dem VM-Dienst zur Verfügung

    Beim Versuch, ein VM-Image zu verwenden, das nicht mit dem VM-Dienst kompatibel ist, wird beim Erstellen der VM die folgende Meldung angezeigt:

    Error from server (GuestOS not supported for osType on image or VMImage is not compatible with v1alpha1 or is not a TKG Image): error when creating : admission webhook "default.validating.virtualmachine.vmoperator.vmware.com" denied the request: GuestOS not supported for osType on image or VMImage is not compatible with v1alpha1 or is not a TKG Image

    Problemumgehung: Verwenden Sie nur VM-Images aus dem VMware Marketplace, die für die Verwendung mit dem VM-Dienst validiert wurden.

  • Images virtueller Maschinen mit Namen, die nicht DNS-konform sind, können nicht genutzt werden

    Wenn der Name eines OVF-Images in einer Inhaltsbibliothek nicht mit dem DNS-Unterdomänennamen kompatibel ist, erstellt der VM-Dienst kein VirtualMachineImage aus dem OVF-Image. Infolgedessen listet kubectl get vmimage die Images nicht in einem Namespace auf und Entwickler können dieses Image nicht nutzen.

    Problemumgehung: Verwenden Sie namenskonforme DNS-Unterdomänennamen für OVF-Images.

  • Doppelte OVF-Images werden nicht als doppelte VirtualMachineImages angezeigt

    OVF-Images mit demselben Namen in unterschiedlichen Inhaltsbibliotheken werden nicht als unterschiedliche VirtualMachineImages angezeigt

    Problemumgehung: Verwenden Sie eindeutige Namen für OVF-Images über Inhaltsbibliotheken hinweg, die mit dem VM-Dienst konfiguriert werden.

  • Vom VM-Dienst erstellte VMs erlauben keinen Zugriff auf das Web oder die Remotekonsole

    Vom VM-Dienst erstellte virtuelle Maschinen erlauben keinen Zugriff auf die Remotekonsole. Dies führt dazu, dass sich Administratoren nicht mit den Optionen Webkonsole starten und Remote Console starten im vSphere Web Client bei der VM anmelden können.

    Problemumgehung: Administratoren können auf die VM-Konsole zugreifen, indem sie sich bei dem ESXi-Host anmelden, auf dem sich die VM befindet.

  • VMs mit vGPU- und Passthrough-Geräten, die vom VM-Dienst verwaltet werden, werden ausgeschaltet, wenn der ESXi-Host in den Wartungsmodus wechselt

    Mit dem VM-Dienst können DevOps-Ingenieure VMs erstellen, die an vGPU- oder Passthrough-Geräte angehängt sind. Wenn ein ESXi-Host in den Wartungsmodus wechselt, generiert DRS normalerweise eine Empfehlung für VMs, die auf dem Host ausgeführt werden. Ein vSphere-Administrator kann dann die Empfehlung akzeptieren, um vMotion auszulösen.

    Vom VM-Dienst verwaltete VMs mit vGPU- und Passthrough-Geräten werden jedoch automatisch ausgeschaltet. Dies kann sich vorübergehend auf Arbeitslasten auswirken, die auf diesen VMs ausgeführt werden. Die VMs werden automatisch eingeschaltet, nachdem der Host im Wartungsmodus ausgeführt wurde.

    Problemumgehung: Keine.

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