VMware NSX Container Plugin 3.1.1   |   4. Februar 2021   |   Build 17559186 Ü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.1 beinhaltet die folgende neue Funktion:

• Vereinfachung der NCP-Bereitstellung und -Verwaltung für Kubernetes-Cluster über Operator
• Einstellen der NetworkUnavaialble-Bedingung des Knotens, wenn der nsx-node-agent auf dem Knoten nicht verfügbar ist (über Operator)
• Aktivieren der Protokollierung für SNAT-Regeln
• Router-Sharding für OCP4
• Multicast zu Tier-1 für einen Kubernetes-Cluster
• Aktivieren des Zugriffsprotokolls auf dem virtuellen Ingress-Server
• Aktivieren von TCP-Multiplexing auf Load Balancer
• Unterstützung des Pod-Zugriffs über hostPort

Einstellungsbenachrichtigung:

Die Anmerkung „ncp/whitelist-source-range“ wird in NCP 3.3 nicht mehr unterstützt. Ab NCP 3.1.1 können Sie stattdessen die Anmerkung „ncp/allowed-source-range“ verwenden.

Kompatibilitätsanforderungen

Produkt	Version
NCP-/NSX-T-Kachel für Tanzu Application Service (PCF)	3.1.1
NSX-T	3.0.2, 3.1.0, 3.1.1
vSphere	6.7, 7.0
Kubernetes	1.18 (P1), 1.19, 1.20
OpenShift 3	3.11 Hinweis: OpenShift 3.x wird in zukünftigen Versionen nicht mehr unterstützt.
OpenShift 4	RHCOS 4.5, 4.6
Kubernetes-Host-VM-Betriebssystem	Ubuntu 18.04, Ubuntu 20.04 CentOS 7.8, CentOS 7.9, CentOS 8.2 RHEL 7.8, RHEL 7.9, RHEL 8.3 (Hinweis: RHEL für Vanilla-Kubernetes wird in zukünftigen Versionen nicht mehr unterstützt). Weitere Informationen finden Sie unten in den Hinweisen.
OpenShift-Host-VM-Betriebssystem	RHEL 7.7, RHEL 7.8 (Hinweis: RHEL für Vanilla-Kubernetes wird in zukünftigen Versionen nicht mehr unterstützt).
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

Anmerkungen:

Die Installation des NSX-OVS-Kernelmoduls unter CentOS/RHEL erfordert eine bestimmte Kernelversion. Die unterstützten RHEL-Kernelversionen sind unabhängig von der RHEL-Version 1127, 1160 und 193. Beachten Sie, dass die Standardkernelversion 1127 für RHEL 7.8, 1160 für RHEL 7.9 und 193 für RHEL 8.2 ist. Wenn Sie eine andere Kernelversion ausführen, können Sie die Installation des NSX-OVS-Kernelmoduls überspringen, indem Sie „use_nsx_ovs_kernel_module“ im Abschnitt „nsx_node_agent“ in der nsx-node-agent-Konfigurationszuordnung auf „False“ festlegen.

Um das NSX-OVS-Kernelmodul unter RHEL 8.2 (Kernelversion 193) auszuführen, müssen Sie die Option „UEFI Secure Boot“ unter „Startoptionen“ in den VM-Einstellungen in vCenter Server deaktivieren.

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

• NCP 3.1 und alle NCP 3.0.x-Versionen

 

Behobene Probleme

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

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 erstellt und aktiviert fünf temporäre Verbindungsprofile, um ovs_bridge zu konfigurieren, aber ihre Aktivierung schlägt möglicherweise vorübergehend im NetworkManager wiederholt fehl. 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, bis alle Profile erfolgreich vom NetworkManager aktiviert werden können.

• 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 2706551: Die automatisierte Full-Stack-Installation von OpenShift (auch als IPI bezeichnet) schlägt fehl, da Knoten während der Installation nicht bereit sind

  Der Keepalived-Pod fügt die Kubernetes-VIP zu ovs_bridge auf den Master-Knoten hinzu, bevor der Kubernetes-API-Server auf ihnen ausgeführt wird. Dies führt dazu, dass alle Anforderungen an den Kubernetes-API-Server fehlschlagen und die Installation nicht abgeschlossen werden kann.

  Problemumgehung: Keine

• Problem 2707883: nsx-ncp-operator erstellt keine NCP-bezogene Kubernetes-Ressource, wenn die Ressource gelöscht wurde, als nsx-ncp-operator nicht ausgeführt wurde

  Wenn Sie beispielsweise das nsx-node-agent- oder nsx-ncp-bootstrap-DaemonSet löschen, wenn nsx-ncp-operator nicht ausgeführt wird, wird es nicht neu erstellt, wenn nsx-ncp-operator erneut ausgeführt wird.

  Problemumgehung: Aktualisieren Sie jedes Feld in der nsx-ncp-operator-ConfigMap, z. B. log_level im Abschnitt [Default], wenn nsx-ncp-operator erneut ausgeführt wird.

• Problem 2697547: HostPort wird auf RHEL/CentOS/RHCOS-Knoten nicht unterstützt

  Sie können hostPorts auf nativen Kubernetes- und PKS-Knoten auf Ubuntu-Knoten angeben, indem Sie in der nsx-node-agent-ConfigMap „enable_hostport_snat“ auf „True“ festlegen. Auf RHEL/CentOS/RHCOS-Knoten wird hostPort jedoch nicht unterstützt, und der Parameter „enable_hostport_snat“ wird ignoriert.

  Problemumgehung: Keine

• Problem 2707174: Ein Pod, der gelöscht und mit demselben Namespace und Namen neu erstellt wird, hat keine Netzwerkkonnektivität

  Wenn ein Pod gelöscht und mit demselben Namespace und Namen neu erstellt wird, wenn NCP nicht ausgeführt wird und nsx-ncp-agents ausgeführt werden, erhält der Pod möglicherweise falsche Netzwerkkonfigurationen und kann nicht auf das Netzwerk zugreifen.

  Problemumgehung: Löschen Sie den Pod und erstellen Sie ihn neu, wenn NCP ausgeführt wird.

• Problem 2713782: NSX API-Aufrufe schlagen mit dem Fehler „SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC“ fehl

  Gelegentlich kann es vorkommen, dass NCP beim Start von NCP neu startet oder die Initialisierung der Load Balancer-Dienste fehlschlägt. Außerdem kann ein NSX-Endpoint während der Ausführung von NCP für einen kurzen Zeitraum (weniger als 1 Sekunde) als INAKTIV angezeigt werden. Wenn der Load Balancer nicht initialisiert werden kann, wird im NCP-Protokoll die Meldung „Fehler beim Initialisieren der LoadBalancer-Dienste“ angezeigt.

  Problemumgehung: Erhöhen Sie den Wert des Parameters „nsx_v3.conn_idle_timeout“. Beachten Sie, dass dies bei Verwendung des clientseitigen Load Balancing zu einer längeren Wartezeit führen kann, bis Endpoints nach einer vorübergehenden Verbindungsunterbrechung als verfügbar erkannt werden.

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