Inhalt dieser Versionshinweise

Stand: 5. Oktober 2021

Diese Versionshinweise decken die folgenden Themen ab:

 

Neuigkeiten

VMware vSphere with Tanzu bietet monatliche Patches zum Einführen neuer Funktionen, zur Bereitstellung neuer Updates für Kubernetes und andere Dienste, zum Schritthalten mit dem Upstream und zum Beheben von gemeldeten Problemen. Hier wird dokumentiert, was jeder monatliche Patch enthält.

Neuheiten 5. Oktober 2021

Build-Informationen am 28. September 2021

ESXi 7.0 Update 3 | 5. Oktober 2021 | ISO-Build 18644231

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

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-Dienst: Updates der Tanzu Kubernetes Cluster-API, mit denen neue Felder für eine erweiterte Konfiguration des Tanzu Kubernetes Grid-Diensts bereitgestellt werden, einschließlich Unterstützung für mehrere Worker-Knotenpools. Einstellung der v1alpha1-API zugunsten der neuen v1alpha2-API.
    • 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.

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

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 vom 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. Erfolgreiche Lebenszyklusverwaltung 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 | 6. 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:

    Virtuelle Festplatte anhängen: Das Gerät oder der Vorgang, angegeben bei Index „-1“, wird für die aktuelle Version „vmx-11“ der virtuellen Maschine nicht unterstützt. Für diesen Vorgang ist mindestens Version „vmx-13“ erforderlich

    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.

Bekannte Probleme

Die bekannten Probleme gliedern sich in folgende Gruppen.

Supervisor-Cluster
  • 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-Anforderung an param0 fehlgeschlagen

    oder

    Die Zeit für den Konfigurationsvorgang für die Knoten-VM param0 wurde überschritten

    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 Nicht autorisiert: Authentifizierung erforderlich oder Benutzername oder Kennwort ungültig 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 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.
  • 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-Registrierung harbor-1560339792 auf cluster domain-c8 ist fehlerhaft. Grund: Harbor-Integrität konnte nicht abgerufen werden: Abrufen von https://30.0.248.2/api/health: x509: Zertifikat von unbekannter Zertifizierungsstelle signiert

    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 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. 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“ oder „kubectl get storageclass“

    Der folgende Fehler wird angezeigt.

    Fehler von Server (Verboten): storageclasses.storage.k8s.io ist verboten: Benutzer „<sso:DEVUSER@DOMAIN>“ kann Ressource „storageclasses“ in API-Gruppe „storage.k8s.io“ im Clustergeltungsbereich nicht auflisten

    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 

    Fehler vom Server (verboten): Namespaces sind verboten: Benutzer „sso:user@vsphere.local“ kann Ressource „namespaces“ in der API-Gruppe „“ im Clustergeltungsbereich nicht auflisten

    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 

    Fehler vom Server (verboten): Benutzer „sso:nuser@vsphere.local“ kann Ressource „namespaces“ in der API-Gruppe „“ im Namespace „“ nicht patchen

    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-Dienst- 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-Dienst-Plug-In zeigt eine Fehlermeldung ähnlich der folgenden an:
     

    Der Tanzu Kubernetes Grid-Dienst konnte nicht bei Kubernetes authentifiziert werden; weitere technische Details finden Sie in der Browserkonsole

    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.

    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. 

    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. 

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. Verwenden Sie eine VLAN-ID zwischen 1 und 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.

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

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 auf kubelet-config-1.19 im kube- system Namespace und ändern Sie dann die ConfigMap-Daten so, dass resolvConf auf /run/systemd/resolve/resolv.conf verweist.

  • 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 aktualisieren, erstellt kube-proxy fälschlicherweise eine IP-Tabellenregel auf den Steuerungsebenenknoten 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.

Speicher
  • 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 Kein Platz mehr auf dem Gerät 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 Beibehalten.
    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 – 56 s (x 121 gegenüber 30 Min.)
    • Von – persistentvolume-controller
    • Meldung – Warten auf die Erstellung eines Volumes, entweder durch den externen Provisioner „csi.vsphere.vmware.com“ oder manuell vom Systemadministrator erstellt

    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 exceeded
      F0817 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 in /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.       

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 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 Befehl kubectl delete pod pending_pod_name, 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.
    3. 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=pluted-ddownime:NoSchedule auf dem Host vorhanden ist, entfernen Sie es manuell:

    kubectl taint nodes nodeName key=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
  • 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:

    Fehler vom Server (GuestOS wird für osType nicht unterstützt) auf Image oder VMImage ist nicht mit „v1alpha1“ kompatibel oder ist kein TKG-Image): Fehler beim Erstellen : Zulassungswebhook „default.validating.virtualmachine.vmoperator.vmware.com“ hat die Anforderung abgelehnt: GuestOS wird für osType nicht unterstützt auf Image oder VMImage ist nicht mit „v1alpha1“ kompatibel oder ist kein 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