VMware NSX Container Plugin 3.1.2   |   15. April 2021   |   Build 17855682 Ü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.2 beinhaltet die folgende neue Funktion:

• Unterstützung für Angabe des Cookienamens bei Load Balancer-Persistenz der Schicht 7

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 (TAS)	3.1.2
NSX-T	3.0.3, 3.1.0, 3.1.1, 3.1.2, 3.1.3
vSphere	6.7, 7.0
Kubernetes	1.18, 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.6, 4.7
Kubernetes-Host-VM-Betriebssystem	Ubuntu 18.04, Ubuntu 20.04 CentOS 7.8, CentOS 7.9, CentOS 8.3 RHEL 7.8, RHEL 7.9, RHEL 8.1, RHEL 8.3 Weitere Informationen finden Sie unten in den Hinweisen.
OpenShift 3 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	Ops Manager 2.7 + TAS 2.7 (LTS) Ops Manager 2.9 + TAS 2.9 Ops Manager 2.10 + TAS 2.10 Ops Manager 2.10 + TAS 2.11
Tanzu Kubernetes Grid Integrated (TKGI)	1.11

Anmerkungen:

Die Installation des NSX-OVS-Kernelmoduls unter CentOS/RHEL erfordert eine bestimmte Kernelversion. Die unterstützten RHEL-Kernel-Versionen sind 1127 und 1160, unabhängig von der RHEL-Version. Beachten Sie, dass die Standard-Kernel-Version 1127 für RHEL 7.8 und 1160 für RHEL 7.9 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.

Ab NCP 3.1.2 wird das RHEL-Image nicht mehr verteilt. Verwenden Sie für alle unterstützten Integrationen das Red Hat Universal Base Image (UBI). Weitere Informationen finden Sie unter https://www.redhat.com/de/blog/introducing-red-hat-universal-base-image.

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

• Alle vorherigen 3.1.x-Versionen und alle NCP 3.0.x-Versionen

 

Behobene Probleme

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

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 TAS Director-Konfiguration wird der Bosh DNS-Server (169.254.0.2) auch weiterhin in der resolve.conf-Datei angezeigt.

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

  Problemumgehung: Keine. Hierbei handelt es sich um ein TAS-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 TAS-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 TAS-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 TKGI-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 TKGI 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 TKGI-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 TKGI-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 2697547: HostPort wird auf RHEL/CentOS/RHCOS-Knoten nicht unterstützt

  Sie können hostPorts auf nativen Kubernetes- und TKGI-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 Starten von NCP die Load Balancer-Dienste neu startet oder nicht initialisieren kann, weil ein doppelter Load Balancing-Server oder ein logischer Tier-1-Router für den Load Balancer vorhanden ist. 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. 

  Dieses Verhalten tritt nur auf, wenn NCP ein clientseitiges Load Balancing über mehrere NSX Manager-Instanzen hinweg durchführt. Es tritt nicht auf, wenn ein einzelner API-Endpoint in ncp.ini konfiguriert ist.

  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 2745904: Die Funktion „IPSet für standardmäßig ausgeführte ASG verwenden“ unterstützt nicht das Entfernen oder Ersetzen eines vorhandenen Container-IP-Blocks

  Wenn Sie „IPSet für standardmäßig ausgeführte ASG verwenden“ auf einer NCP-Kachel aktivieren, erstellt NCP eine dedizierte NSGroup für alle Container-IP-Blöcke, die durch „IP-Blöcke von Containernetzwerken“ auf derselben NCP-Kachel konfiguriert wurden. Diese NSGroup wird in den Firewallregeln verwendet, die für globale, ausgeführte ASGs erstellt wurden, um Datenverkehr für alle Container zu ermöglichen. Wenn Sie später einen vorhandenen Container-IP-Block entfernen oder ersetzen, wird er in der NSGroup entfernt oder ersetzt. Vorhandene Container im ursprünglichen IP-Block werden nicht mehr mit den globalen ausgeführten ASGs verknüpft. Ihr Datenverkehr funktioniert möglicherweise nicht mehr.

  Problemumgehung: Fügen Sie nur neue IP-Blöcke zu „IP-Blöcke von Containernetzwerken“ hinzu.

• Problem 2744480: Self-Access des Kubernetes-Diensts wird auf KVM nicht unterstützt

  Wenn ein Kubernetes-Pod versucht, über einen Kubernetes-Dienst, für den der Pod ein Endpoint ist, auf sich selbst zuzugreifen, werden Antwortpakete auf dem KVM-Host verworfen.

  Problemumgehung: Keine

• Problem 2744361: Die mit einer statischen IP-Adresse konfigurierte Arbeitslast-VM in OpenShift verliert möglicherweise die Konnektivität, wenn der nsx-node-agent-Pod beendet wird

  Gelegentlich verliert eine mit einer statischen IP-Adresse konfigurierte Arbeitslast-VM in OpenShift die Konnektivität, wenn der nsx-node-agent-Pod beendet wird.

  Problemumgehung: Starten Sie die VM neu.

• Problem 2746362: nsx-kube-proxy kann keine Kubernetes-Dienstereignisse vom Kubernetes-API-Server empfangen

  In einem OpenShift-Cluster kann nsx-kube-proxy gelegentlich kein Kubernetes-Dienstereignis vom Kubernetes-API-Server empfangen. Der Befehl „nsxcli -c get kube-proxy-watchers“ gibt die Ausgabe „Watcher Thread Status: Aktiv“, aber die „Anzahl der verarbeiteten Ereignisse“ ist 0, d. h., nsx-kube-proxy hat kein Ereignis vom API-Server empfangen.

  Problemumgehung: Starten Sie den nsx-kube-proxy-Pod neu.

• Problem 2745907: „monit“-Befehle geben falsche Statusinformationen für nsx-node-agent zurück

  Wenn monit den nsx-node-agent auf einer diego_cell-VM neu startet und es mehr als 30 Sekunden dauert, bis der nsx-node-agent vollständig gestartet ist, zeigt monit den Status von nsx-node-agent als „Ausführung fehlgeschlagen“ an und aktualisiert seinen Status nicht auf „wird ausgeführt“, selbst wenn der nsx-node-agent später voll funktionsfähig ist.

  Problemumgehung: Keine.

• Problem 2735244: Absturz von nsx-node-agent und nsx-kube-proxy aufgrund einer fehlgeschlagenen Aktivitätsprüfung

  nsx-node-agent und nsx-kube-proxy verwenden sudo, um einige Befehle auszuführen. Wenn in /etc/resolv.conf viele Einträge zu DNS-Server- und Suchdomänen vorhanden sind, kann das Auflösen von Hostnamen durch sudo sehr lange dauern. Dies verursacht eine lange Blockierung von nsx-node-agent und nsx-kube-proxy durch den sudo-Befehl, und die Aktivitätsprüfung schlägt fehl.

  Problemumgehung: Führen Sie eine der folgenden beiden Aktionen durch:

  • Fügen Sie Hostnameneinträge zu /etc/hosts hinzu. Wenn der Hostname beispielsweise „host1“ ist, fügen Sie den Eintrag „127.0.0.1   host1“ hinzu.
  • Legen Sie einen größeren Wert für die Zeitüberschreitung der nsx-node-agent-Aktivitätsprüfung fest. Führen Sie den Befehl „kubectl edit ds nsx-node-agent -n nsx-system“ aus, um den Zeitüberschreitungswert für die Container nsx-node-agent und nsx-kube-proxy zu aktualisieren.
• Problem 2744557: Komplexe reguläre Ausdrucksmuster, die sowohl eine Erfassungsgruppe () als auch {0} enthalten, die für den Abgleich des Ingress-Pfads nicht unterstützt werden

  Wenn beispielsweise das reguläre Ausdrucks-(Regex)-Muster wie folgt lautet: /foo/bar/(abc){0,1}, hat es keine Übereinstimmung mit /foo/bar/.

  Problemumgehung: Verwenden Sie die Erfassungsgruppe () und {0} nicht, wenn Sie eine Ingress-Regex-Regel erstellen. Verwenden Sie das reguläre Muster EQUALS für die Übereinstimmung mit /foo/bar/.

• Problem 2751080: Nach einem KVM-Host-Upgrade können Container-Hosts keine Kubernetes-Pods ausführen

  Nach einem KVM-Host-Upgrade können auf dem aktualisierten Host bereitgestellte Container-Hosts keine Kubernetes-Pods ausführen. Die Pods verbleiben im Container-Erstellungsstatus. Wenn der NCP-Operator bereitgestellt wird, wechselt der Status des Knotens möglicherweise zu NotReady, und als Zustand des networkUnavailable-Knotens wird „True“ angezeigt. Dieses Problem tritt nur bei RHEL und nicht bei Ubuntu auf.

  Problemumgehung: Starten Sie nsx-opsagent auf dem KVM-Hypervisor neu.

• Problem 2736412: Parameter members_per_small_lbs wird ignoriert, wenn max_allowed_virtual_servers festgelegt ist

  Wenn sowohl max_allowed_virtual_servers als auch members_per_small_lbs festgelegt sind, können virtuelle Server möglicherweise nicht an einen verfügbaren Load Balancer angehängt werden, da nur max_allowed_virtual_servers berücksichtigt werden.

  Problemumgehung: Lockern Sie die Skalierungseinschränkungen, anstatt die automatische Skalierung zu aktivieren.

• Problem 2740552: Wenn Sie einen statischen Pod mithilfe des API-Servers löschen, entfernt nsx-node-agent den OVS-Bridge-Port des Pods nicht, und das automatisch von Kubernetes neu erstellte Netzwerk des statischen Pods ist nicht verfügbar

  Kubernetes lässt das Entfernen eines statischen Pods durch einen API-Server nicht zu. Kubernetes erstellt eine gespiegelte Version des statischen Pods, sodass der statische Pod von einem API-Server durchsucht werden kann. Beim Löschen des Pods durch den API-Server wird nur der gepiegelte Pod gelöscht und NCP empfängt und verarbeitet die Löschanforderung, um alle dem Pod zugewiesene NSX-Ressource zu entfernen. Der statische Pod ist jedoch weiterhin vorhanden, und nsx-node-agent erhält nicht die Löschanforderung von CNI, um den OVS-Bridge-Port des statischen Pods zu entfernen. 

  Problemumgehung: Entfernen Sie den statischen Pod, indem Sie die Manifestdatei löschen, anstatt den statischen Pod vom API-Server zu entfernen.

• Problem 2795268: Verbindung zwischen nsx-node-agent, Hyperbus-Flips und Kubernetes-Pod bleibt in Erstellungsstatus hängen

  In einer großen Umgebung kann nsx-node-agent möglicherweise keine Verbindung zum Kubernetes-API-Server herstellen, um Pod-Informationen zu erhalten. Da viele Informationen übertragen werden, können Keepalive-Nachrichten nicht an Hyperbus gesendet werden, und Hyperbus schließt die Verbindung.

  Problemumgehung: Starten Sie den nsx-node-agent neu. Stellen Sie sicher, dass der Kubernetes-API-Server verfügbar ist und das Zertifikat für die Verbindung mit dem API-Server korrekt ist.

• Problem 2795482: Der ausgeführte Pod bleibt nach einem Neustart des Knotens/Hypervisors oder einem anderen Vorgang im ContainerCreating-Status hängen

  Wenn das wait_for_security_policy_sync-Flag „True“ lautet, kann ein Pod aufgrund eines harten Neustarts des Worker-Knotens, eines Hypervisor-Neustarts oder eines anderen Grundes in den Status ContainerCreating wechseln, nachdem er länger als eine Stunde ausgeführt wurde. Der Pod wird für immer im Erstellungszustand bleiben.

  Problemumgehung: Löschen und erstellen Sie den Pod neu.

• Problem 2871314: Nach dem TKGI-Upgrade von 1.10.x auf 1.11.x (vor 1.11.6) werden die Ingress-Zertifikate für den NSX-Lastausgleichsdienst gelöscht.

  Ab NCP 3.1.1 werden Zertifikate mit einer Revisionsnummer nachverfolgt. Dies führt zu einem Problem beim Upgrade von TKGI 1.10.x auf TKGI 1.11.x (vor 1.11.6), was dazu führt, dass die Ingress-Zertifikate für NSX Load Balancer gelöscht und nicht erneut importiert werden.

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

  1. Starten Sie NCP neu. Oder
  2. Löschen Sie den geheimen Schlüssel in der Kubernetes-Umgebung und erstellen Sie denselben geheimen Schlüssel neu. Oder
  3. Führen Sie ein Upgrade auf TKGI 1.11.6 oder höher durch.
• Problem 2871321: Nach dem TKGI-Upgrade von 1.10.x auf 1.11.x (vor 1.11.6) geht die IP-Adresse verloren, wenn der CRD LoadBalancer L7-Cookiepersistenz verwendet.

  Dieses Problem wird durch eine neue Funktion in NCP 3.1.1 verursacht, die die Aktualisierung von Cookienamen in NSX Load Balancer unterstützt.

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

  1. Verwenden Sie die Quell-IP-Persistenz anstelle der Cookiepersistenz.
  2. Führen Sie ein Upgrade auf TKGI 1.11.6 oder höher durch.
• 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.