Versionshinweise zu NSX Container Plugin 3.1

VMware NSX Container Plugin 3.1   |   19. November 2020   |   Build 17170700 Überprüfen Sie regelmäßig, ob Erweiterungen und Updates für dieses Dokument zur Verfügung stehen.

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

• Neuigkeiten
• Kompatibilitätsanforderungen
• Behobene Probleme
• Bekannte Probleme

Neuigkeiten

 

NSX Container Plugin (NCP) 3.1 weist folgende neuen Funktionen auf:

• Möglichkeit zur Angabe einer SNAT-IP für eine Tanzu Application Service(TAS)-Organisation
• Support für lokalen DNS-Cache des Knotens für Tanzu Kubernetes Grid Integrated (TKGI)
• Möglichkeit zum Hinzufügen einer Kubernetes-Cluster-Kennzeichnung in Protokollen verteilter Firewalls, um die von einem Kubernetes-Cluster in einer Umgebung mit mehreren Mandanten stammenden Firewallprotokolle zu unterscheiden.
• Aktivieren des Tier-1-Routers pro Supervisor-Namespace-Topologie für vSphere mit Tanzu
• Support für die NSX-Lizenzerzwingung für containerbezogene Funktionen

Kompatibilitätsanforderungen

Produkt	Version
NCP-/NSX-T-Kachel für Tanzu Application Service (PCF)	3.1
NSX-T	3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.1.1
vSphere	6.7, 7.0
Kubernetes	1.18, 1.19
OpenShift 3	3.11 Hinweis: Wird in einer künftigen Version nicht mehr unterstützt.
OpenShift 4	RHCOS 4.4, 4.5
Kubernetes-Host-VM-Betriebssystem	Ubuntu 18.04, Ubuntu 20.04, CentOS 7.7, CentOS 7.8, CentOS 8.1, CentOS 8.2, RHEL 7.8, RHEL 8.1, RHEL 8.2 Hinweis: Für Ubuntu 20.04, RHEL/CentOS 7.8, 8.1 wird NSX-OVS-Kernelmodulinstallation nicht unterstützt. NSX-OVS ist nur mit dem vorgelagerten OVS kompatibel.
OpenShift-Host-VM-Betriebssystem	RHEL 7.7, RHEL 7.8
Tanzu Application Service (Pivotal Cloud Foundry)	Ops Manager 2.7 + PAS 2.7 (LTS) Ops Manager 2.9 + PAS 2.9 Ops Manager 2.10 + PAS 2.10
Tanzu Kubernetes Grid Integrated (TKGI)	1.10

Unterstützung für das Upgrade auf diese Version:

• Alle NCP 3.0.x-Versionen

 

Behobene Probleme

• Problem 2552918: Das Rollback für den Import vom Managermodus in den Richtlinien-Workflow schlägt für die verteilte Firewall fehl, wodurch das Rollback des Clusters fehlschlägt

  In seltenen Fällen muss für den Importvorgang vom Manager- in den Richtlinienmodus ein Rollback durchgeführt werden, das für die Abschnitte und Regeln der verteilten Firewall fehlschlägt. Dies führt dazu, dass das Rollback des Clusters fehlschlägt und in NSX Manager veraltete Ressourcen erhalten bleiben.

  Problemumgehung: Verwenden Sie die Sicherungs- und Wiederherstellungsfunktion, um NSX Manager in einem fehlerfreien Zustand wiederherzustellen.

Bekannte Probleme

• Problem 2131494: NGINX-Kubernetes-Ingress funktioniert weiterhin nach der Änderung der Ingress-Klasse von „nginx“ in „nsx“

  Bei der Erstellung eines NGINX-Kubernetes-Ingress erstellt NGINX Regeln für die Weiterleitung des Datenverkehrs. Wenn Sie die Ingress-Klasse in einen anderen Wert ändern, werden die Regeln von NGINX nicht gelöscht und weiterhin angewendet, selbst wenn Sie den Kubernetes Ingress nach der Änderung der Klasse löschen. Dies ist eine Einschränkung von NGINX.

  Problemumgehung: Um die von NGINX erstellten Regeln zu löschen, löschen Sie den Kubernetes-Ingress, wenn der Klassenwert „nginx“ lautet. Erstellen Sie dann den Kubernetes-Ingress neu.

• Für einen Kubernetes-Dienst des Typs „ClusterIP“ wird die Client-IP-basierte Sitzungsaffinität nicht unterstützt

  NCP unterstützt keine Client-IP-basierte Sitzungsaffinität für einen Kubernetes-Dienst des Typs „ClusterIP“.

  Problemumgehung: Keine

• Für einen Kubernetes-Dienst des Typs „ClusterIP“ wird das Hairpin-Modus-Flag nicht unterstützt

  NCP unterstützt das Hairpin-Modus-Flag für einen Kubernetes-Dienst des Typs „ClusterIP“ nicht.

  Problemumgehung: Keine

• Problem 2192489: Nach dem Deaktivieren des „BOSH DNS-Servers“ in der PAS Director-Konfiguration wird der Bosh DNS-Server (169.254.0.2) auch weiterhin in der resolve.conf Datei angezeigt.

  In einer PAS-Umgebung, in der PAS 2.2 ausgeführt wird, wird der Bosh DNS-Server (169.254.0.2) nach dem Deaktivieren des „BOSH DNS-Servers“ in der PAS Director-Konfiguration weiterhin in der in der resove.conf-Datei des Containers angezeigt. Dadurch nimmt ein Ping-Befehl mit einem vollqualifizierten Domänennamen viel Zeit in Anspruch. Dieses Problem liegt bei PAS 2.1 nicht vor.

  Problemumgehung: Keine. Hierbei handelt es sich um ein PAS-Problem.

• Problem 2224218: Nach dem Löschen eines Diensts oder einer App dauert es 2 Minuten, bis die SNAT-IP wieder im IP-Pool freigegeben wird

  Wenn Sie einen Dienst oder eine App löschen und sie innerhalb von 2 Minuten erneut erstellen, erhält er bzw. sie eine neue SNAT IP aus dem IP-Pool.

  Problemumgehung: Warten Sie nach dem Löschen eines Diensts oder einer App 2 Minuten, bevor Sie ihn bzw. sie neu erstellen, wenn Sie dieselbe IP wiederverwenden möchten.

• Problem 2404302: Wenn mehrere Load Balancer-Anwendungsprofile für denselben Ressourcentyp (z. B. HTTP) auf NSX-T vorhanden sind, wird NCP eine beliebige von diesen zum Anhängen an die virtuellen Server auswählen.

  Wenn mehrere HTTP Load Balancer-Anwendungsprofile auf NSX-T vorhanden sind, wird NCP eine beliebige von diesen mit der entsprechenden x_forwarded_for-Konfiguration auswählen, um sie an den virtuellen HTTP- und HTTPS-Server anzuhängen. Wenn mehrere FastTCP- und UDP-Anwendungsprofile auf NSX-T vorhanden sind, wird NCP ein beliebiges von diesen auswählen, das an die virtuellen TCP- und UDP-Server angehängt werden soll. Die Anwendungsprofile des Load Balancers wurden möglicherweise von verschiedenen Anwendungen mit unterschiedlichen Einstellungen erstellt. Wenn NCP eines dieser Load Balancer-Anwendungsprofile an die von NCP erstellten virtuellen Server anhängt, kann dies möglicherweise den Workflow anderer Anwendungen unterbrechen.

  Problemumgehung: Keine

• Problem 2397621: Installation von OpenShift 3 schlägt fehl

  Bei der Installation von OpenShift 3 wird vorausgesetzt, dass der Status eines Knotens „Bereit“ lautet; dies ist nach der Installation des CNI-Plug-Ins möglich. In dieser Version gibt es keine separate CNI-Plug-In-Datei, was dazu führt, dass die OpenShift-Installation fehlschlägt.

  Problemumgehung: Erstellen Sie das /etc/cni/net.d-Verzeichnis auf jedem Knoten, bevor Sie die Installation starten.

• Problem 2413383: Das Upgrade von OpenShift 3 schlägt fehl, da nicht alle Knoten bereit sind

  Standardmäßig ist der NCP-Bootstrap-Pod nicht auf dem Master-Knoten geplant. Daher lautet der Status des Master-Knotens immer „Nicht bereit“.

  Problemumgehung: Weisen Sie den Master-Knoten mit der Rolle „Berechnen“ zu, damit die nsx-ncp-bootstrap- und nsx-node-agent-DaemonSets Pods erstellen können. Der Knotenstatus wird in „Bereit“ geändert, sobald nsx-ncp-bootstrap das NSX-CNI installiert.

• Problem 2451442: Nach einem wiederholten Neustart von NCP und dem erneuten Erstellen eines Namespace kann NCP möglicherweise keine IP-Adressen an Pods zuteilen

  Wenn Sie denselben Namespace während des Neustarts von NCP wiederholt löschen und neu erstellen, kann NCP den Pods in diesem Namespace möglicherweise keine IP-Adressen zuteilen.

  Problemumgehung: Löschen Sie alle veralteten NSX-Ressourcen (logische Router, logische Switches und logische Ports), die mit dem Namespace verknüpft sind, und erstellen Sie sie anschließend neu.

• Problem 2460219: HTTP-Umleitung funktioniert nicht ohne einen Standardserverpool

  Wenn der virtuelle HTTP-Server nicht an einen Serverpool gebunden ist, schlägt die HTTP-Umleitung fehl. Das Problem tritt in NSX-T 2.5.0 und früheren Versionen auf.

  Problemumgehung: Erstellen Sie einen Standardserverpool oder aktualisieren Sie auf NSX-T 2.5.1.

• Problem 2518111: NSX-T-Ressourcen, die aus NSX-T aktualisiert wurden, können nicht durch NCP gelöscht werden

  NCP erstellt NSX-T-Ressourcen auf Grundlage der von Ihnen festgelegten Konfigurationen. Wenn Sie diese NSX-T-Ressourcen über den NSX Manager oder die NSX-T-API aktualisieren, kann NCP diese Ressourcen möglicherweise nicht löschen und neu erstellen, wenn dies erforderlich ist.

  Problemumgehung: Aktualisieren Sie keine von NCP über den NSX Manager oder die NSX-T-API erstellten NSX-T-Ressourcen.

• Problem 2524778: NSX Manager zeigt NCP nach dem Löschen des NCP-Master-Knotens als inaktiv oder fehlerhaft an

  Nachdem ein NCP-Master-Knoten gelöscht wurde, z. B. nach einem erfolgreichen Wechel zu einem Sicherungsknoten, wird NCP weiterhin mit dem Integritätsstatus „Inaktiv“ angezeigt, obwohl es betriebsbereit sein sollte.

  Problemumgehung: Führen Sie in der Manager-API DELETE /api/v1/systemhealth/container-cluster/<cluster-id>/ncp/status aus, um den veralteten Status manuell zu löschen.

• Problem 2517201: Auf einem ESXi-Host kann kein Pod erstellt werden

  Nachdem ein ESXi-Host aus einem vSphere-Cluster entfernt und erneut zum Cluster hinzugefügt wurde, schlägt das Erstellen eines Pods auf dem Host fehl.

  Problemumgehung: Starten Sie NCP neu.

• Problem 2416376: NCP kann keine PAS-ASG (App Security Group) mit einer Bindung an mehr als 128 Bereiche verarbeiten

  Aufgrund eines Grenzwerts in der verteilten NSX-T-Firewall, kann NCP keine PAS-ASG mit einer Bindung an mehr als 128 Bereiche verarbeiten.

  Problemumgehung: Erstellen Sie mehrere ASGs und binden Sie jede an maximal 128 Bereiche.

• Problem 2534726: Wenn ein Upgrade auf NCP 3.0.1 über die NSX-T-Kachel fehlschlägt, führt ein erneutes Upgrade über die BOSH-Befehlszeile zu Leistungsproblemen

  Wenn Sie ein Upgrade auf NCP 3.0.1 über die NSX-T-Kachel in OpsMgr durchführen, werden HA-Switching-Profile während des Upgrades in NSX Manager als inaktiv gekennzeichnet. Die Switching-Profile werden gelöscht, wenn NCP neu gestartet wird. Wenn das Upgrade fehlschlägt und Sie es mit einem BOSH-Befehl (z. B.: bosh deploy -d <deployment-id> -n <deployment>.yml) erneut ausführen, werden die HA-Switching-Profile nicht gelöscht. NCP wird weiterhin ausgeführt. Die Leistung ist jedoch beeinträchtigt.

  Problemumgehung: Führen Sie ein Upgrade von NCP immer über OpsMgr und nicht über die BOSH-Befehlszeile durch.

• Problem 2537221: Nach dem Upgrade von NSX-T auf 3.0 wird der Netzwerkstatus von zu Containern gehörenden Objekten auf der NSX Manager-Benutzeroberfläche als „Unbekannt“ angezeigt

  Auf der NSX Manager-Benutzeroberfläche werden auf der Registerkarte „Bestandsliste“ > „Container“ die zu Containern gehörenden Objekte und deren Status angezeigt. In einer PKS-Umgebung wird nach dem Upgrade von NSX-T auf 3.0 der Netzwerkstatus der zu Containern gehörenden Objekte als „Unbekannt“ angezeigt. Das Problem wird dadurch verursacht, dass PKS die Änderung der NSX-T-Version nicht erkennt. Dieses Problem tritt nicht auf, wenn NCP als Pod ausgeführt wird und die Integritätsprüfung aktiv ist.

  Problemumgehung: Starten Sie nach dem Upgrade von NSX-T die NCP-Instanzen schrittweise neu (maximal 10 gleichzeitig), um NSX Manager nicht zu überlasten.

• Problem 2550474: Wenn in einer OpenShift-Umgebung eine HTTPS-Route in eine HTTP-Route geändert wird, kann dies dazu führen, dass die HTTP-Route nicht wie erwartet funktioniert

  Wenn Sie eine HTTPS-Route bearbeiten und die zu TLS gehörenden Daten löschen, um die Route in eine HTTP-Route zu konvertieren, dann funktioniert die HTTP-Route möglicherweise nicht wie erwartet.

  Problemumgehung: Löschen Sie die HTTPS-Route und erstellen Sie eine neue HTTP-Route.

• Problem 2552573: In einer OpenShift 4.3-Umgebung schlägt die Clusterinstallation möglicherweise fehl, wenn DHCP über die Richtlinienbenutzeroberfläche konfiguriert wird

  In einer OpenShift 4.3-Umgebung erfordert die Clusterinstallation, dass ein DHCP-Server verfügbar ist, der IP-Adressen und DNS-Informationen bereitstellt. Wenn Sie den DHCP-Server verwenden, der in NSX-T unter Verwendung der Richtlinienbenutzeroberfläche konfiguriert wurde, schlägt die Clusterinstallation möglicherweise fehl.

  Problemumgehung: Konfigurieren Sie einen DHCP-Server über die Manager-Benutzeroberfläche, löschen Sie den fehlgeschlagenen Cluster und erstellen Sie den Cluster neu.

• Problem 2552564: In einer OpenShift 4.3-Umgebung funktioniert die DNS-Weiterleitung möglicherweise nicht mehr, wenn eine überlappende Adresse gefunden wird

  In einer OpenShift 4.3-Umgebung erfordert die Clusterinstallation, dass ein DNS-Server konfiguriert wird. Wenn Sie zum Konfigurieren einer DNS-Weiterleitung NSX-T verwenden und wenn eine IP-Adresse vorhanden ist, die mit dem DNS-Dienst überlappt, funktioniert die DNS-Weiterleitung nicht mehr und die Clusterinstallation schlägt fehl.

  Problemumgehung: Konfigurieren Sie einen externen DNS-Dienst, löschen Sie den fehlgeschlagenen Cluster und erstellen Sie den Cluster neu.

• Problem 2483242: IPv6-Datenverkehr von Containern wird durch NSX-T SpoofGuard blockiert

  Wenn SpoofGuard aktiviert ist, erfolgt für lokale IPv6-Adressen kein automatisches Whitelisting.

  Problemumgehung: Deaktivieren Sie SpoofGuard, indem Sie in der NCP-Konfiguration „nsx_v3.enable_spoofguard = False“ festlegen.

• Problem 2552609: Fehlerhafte X-Forwarded-For- (XFF) und X-Forwarded-Port-Daten

  Wenn Sie XFF mit INSERT oder REPLACE für HTTPS-Ingress-Regeln (Kubernetes) oder HTTPS-Routen (OpenShift) konfigurieren, enthalten die XFF-Header möglicherweise falsche X-Forwarded-For- und X-Forwarded-Port-Werte.

  Problemumgehung: Keine.

• Problem 2555336: Pod-Datenverkehr schlägt aufgrund doppelter logischer Ports fehl, die im Managermodus erstellt wurden

  Dieses Problem tritt häufiger auf, wenn viele Pods in mehreren Clustern vorhanden sind. Wenn Sie einen Pod erstellen, schlägt der Datenverkehr zum Pod fehl. NSX-T zeigt mehrere logische Ports an, die für denselben Container erstellt wurden. Das NCP-Protokoll enthält nur die ID eines der logischen Ports. 

  Problemumgehung: Löschen Sie den Pod und erstellen Sie ihn neu. Die veralteten Ports in NSX-T werden entfernt, wenn NCP neu gestartet wird.

• Problem 2554357: Die automatische Skalierung des Load Balancers funktioniert nicht für IPv6

  In einer IPv6-Umgebung ist kein Kubernetes-Dienst vom Typ LoadBalancer aktiv, wenn die Größe des vorhandenen Load Balancers erreicht ist.

  Problemumgehung: Legen Sie für PKS-Bereitstellungen in /var/vcap/jobs/ncp/config/ncp.ini und für andere in nsx-ncp-configmap „nsx_v3.lb_segment_subnet = FE80::/10“ fest. Starten Sie NCP anschließend neu.

• Problem 2597423: Beim Importieren von Manager-Objekten in die Richtlinie führt ein Rollback dazu, dass die Tags einiger Ressourcen verloren gehen.

  Wenn ein Rollback erforderlich ist, werden die Tags der folgenden Elemente beim Importieren von Manager-Objekten in die Richtlinie nicht wiederhergestellt:

  • Spoofguard-Profile (Teil der gemeinsam genutzten Ressourcen und Clusterressourcen)
  • BgpneighbourConfig (Teil der gemeinsam genutzten Ressourcen)
  • BgpRoutingConfig (Teil der gemeinsam genutzten Ressourcen)
  • StaticRoute BfdPeer (Teil der gemeinsam genutzten Ressourcen)

  Problemumgehung: Stellen Sie bei Ressourcen, die Teil der gemeinsam genutzten Ressourcen sind, die Tags manuell wieder her. Verwenden Sie die Sicherungs- und Wiederherstellungsfunktion, um Ressourcen wiederherzustellen, die Teil von Clusterressourcen sind.

• Problem 2579968: Wenn häufig Änderungen an den Kubernetes-Diensten vom Typ „LoadBalancer“ vorgenommen werden, werden einige virtuelle Server und Serverpools nicht wie erwartet gelöscht

  Wenn häufig Änderungen an den Kubernetes-Diensten vom Typ „LoadBalancer“ vorgenommen werden, verbleiben einige virtuelle Server und Serverpools möglicherweise in der NSX-T-Umgebung, obwohl sie gelöscht werden sollten.

  Problemumgehung: Starten Sie NCP neu. Alternativ können Sie veraltete virtuelle Server und die zugehörigen Ressourcen auch manuell entfernen. Ein virtueller Server ist veraltet, wenn kein Kubernetes-Dienst vom Typ „LoadBalancer“ den Bezeichner des virtuellen Servers im Tag „external_id“ aufweist.

• Problem 2536383: Nach dem Upgrade von NSX-T auf 3.0 oder höher werden die Informationen zu NCP auf der Benutzeroberfläche von NSX-T nicht ordnungsgemäß angezeigt

  Nach dem Upgrade von NSX-T auf 3.0 oder höher wird auf der Benutzerfläche von NSX-T auf der Registerkarte Bestand > Container für den Netzwerkstatus der auf dem Container verwandten Objekte „Unbekannt“ angezeigt. Außerdem werden NCP-Cluster nicht auf der Registerkarte System > Fabric > Knoten > NCP-Cluster angezeigt. Dieses Problem tritt in der Regel in einer PKS-Umgebung auf.

  Problemumgehung: Starten Sie nach dem Upgrade von NSX-T die NCP-Instanzen schrittweise neu (maximal 10 gleichzeitig).

• Problem 2622099: Beim Kubernetes-Dienst vom Typ „LoadBalancer“ tritt ein Fehler mit dem Fehlercode NCP00113 und der Fehlermeldung „Das Objekt wurde von einer anderen Person geändert.“ auf.

  Wenn Sie in einer Bereitstellung mit einer einzelnen Ebene mit der Richtlinien-API ein vorhandenes Tier-1-Gateway als Gateway der obersten Ebene verwenden und die Pool-Zuteilungsgröße des Gateways ROUTING lautet, kann ein Kubernetes-Dienst vom Typ „LoadBalancer“ möglicherweise nicht initialisiert werden und es tritt der Fehlercode NCP00113 und mit folgender Fehlermeldung auf: „Das Objekt wurde von einer anderen Person geändert. Versuchen Sie es erneut.“

  Problemumgehung: Wenn das Problem auftritt, warten Sie 5 Minuten. Starten Sie NCP anschließend neu. Das Problem wird behoben.

• Problem 2633679: Der NCP-Operator unterstützt keine OpenShift-Knoten, die mit einem Tier-1-Segment verbunden sind, das mit der API /policy/api/v1/infra/tier-1s/<tier1-id>/segments/<segment-id> erstellt wurde

  Der NCP-Operator unterstützt keine OpenShift-Knoten, die mit einem Tier-1-Segment verbunden sind, das mit der API /policy/api/v1/infra/tier-1s/<tier1-id>/segments/<segment-id> erstellt wurde.

  Problemumgehung: Verwenden Sie die API /policy/api/v1/infra/segments/<segment-id>, um das Segment zu erstellen.

• NCP kann nicht gestartet werden, wenn die Protokollierung in der Datei während der Installation von Kubernetes aktiviert ist

  Dieses Problem tritt auf, wenn uid:gid=1000:1000 auf dem Container-Host nicht über die Berechtigung für den Protokollordner verfügt.

  Problemumgehung: Führen Sie einen der folgenden Schritte aus:

  • Ändern Sie den Modus des Protokollordners auf den Container-Hosts in 777.
  • Erteilen Sie uid:gid=1000:1000 auf den Container-Hosts die Berechtigung „rwx“ des Protokollordners.
  • Deaktivieren Sie die Funktion der Protokollierung in der Datei.
• Problem 2653214: Fehler bei der Suche nach dem Segmentport für einen Knoten, nachdem die IP-Adresse des Knotens geändert wurde

  Wenn Sie nach der Änderung der IP-Adresse eines Knotens ein Upgrade von NCP durchführen oder wenn der NCP-Operator-Pod neu gestartet wird, wird beim Überprüfen des Status des NCP-Operator mit dem Befehl „oc describe co nsx-ncp“ die Fehlermeldung „Fehler beim Suchen des Segmentports für Knoten ...“ angezeigt.

  Problemumgehung: Keine. Das Hinzufügen einer statischen IP-Adresse auf einer Knotenschnittstelle, die auch eine DHCP-Konfiguration aufweist, wird nicht unterstützt.

• Problem 2664457: Bei der Verwendung von DHCP in OpenShift geht die Konnektivität möglicherweise vorübergehend verloren, wenn der NSX-Knoten-Agent startet oder neu gestartet wird

  NSX-OVS aktiviert das Profil der DHCP-Verbindung auf ovs_bridge, die in NetworkManager möglicherweise immer wieder fehlschlägt. Dies führt dazu, dass auf der VM auf ovs_uplink_port und/oder ovs_bridge keine IP (Konnektivität) vorhanden ist.

  Problemumgehung: Starten Sie die VM neu oder warten Sie einfach, bis die DHCP-IP-Zuteilung erfolgreich verläuft.

• Problem 2671647: Beim Neustart des monit-Auftrags für OVS daemons ovsdb-server und ovs-vswitchd verloren gegangene OVS-Flows

  Vom NSX-Knoten-Agent erstellte OVS-Flows gehen verloren, wenn der monit-Auftrag für die openvswitch-Daemons mithilfe des Befehls „monit restart <Prozessname>“ neu gestartet wird

  Problemumgehung: Führen Sie unter Verwendung des folgenden Befehls einen Neustart des NSX-Knoten-Agents durch, nachdem sich die openvswitch-Daemons wieder im Status „Ausgeführt“ befinden: „monit restart nsx-node-agent“.

• Problem 2672677: In einer stark belasteten OpenShift 4-Umgebung reagiert ein Knoten möglicherweise nicht mehr

  In einer OpenShift 4-Umgebung mit einer hohen Dichte an Pods pro Knoten und einer hohen Frequenz, in der Pods gelöscht und erstellt werden, kann ein RHCOS-Knoten in den Status „Nicht bereit“ wechseln. Pods, die auf dem betroffenen Knoten ausgeführt werden, mit Ausnahme der daemonset-Mitglieder, werden entfernt und auf anderen Knoten in der Umgebung neu erstellt.

  Problemumgehung: Starten Sie den betroffenen Knoten neu.

• Problem 2653241: Das Aktualisieren der Zertifikate eines Geheimnisses in Kubernetes wird nicht unterstützt

  Wenn Sie die Zertifikate in einem Geheimnis aktualisieren, werden die neuen Zertifikate nicht in NSX-T aktualisiert. Dieses Problem besteht sowohl im Manager- als auch im Richtlinienmodus.

  Problemumgehung: Löschen Sie das Geheimnis und erstellen Sie ein neues mit den aktualisierten Zertifikaten.

• Problem 2674503: NSX-NCP-Bootstrap unterstützt nicht die Installation von NSX-OVS-Kernelmodulen auf CentOS 7.8, 8.1, 8.2 oder RHEL 7.8, 8.1, 8.2

  Der NSX-NCP-Bootstrap-Container unterstützt nicht die Installation von NSX-OVS-Kernelmodulen auf CentOS 7.8, 8.1, 8.2 oder RHEL 7.8, 8.1, 8.2.

  Problemumgehung: Legen Sie für use_nsx_ovs_kernel_module in der NSX-Knoten-Agent-ConfigMap False fest und verwenden Sie das Upstream-OVS-Kernelmodul von Linux.

• Problem 3033821: Nach der Manager-zu-Richtlinien-Migration werden Regeln für verteilte Firewalls nicht ordnungsgemäß erzwungen

  Nach einer Manager-zu-Richtlinien-Migration haben neu erstellte richtlinienbezogene Regeln für die verteilte Firewall (Distributed Firewall, DFW) des Netzwerks eine höhere Priorität als die migrierten DFW-Regeln.

  Problemumgehung: Verwenden Sie die Richtlinien-API, um die Reihenfolge der DFW-Regeln nach Bedarf zu ändern.