Versionshinweise zu VMware NSX Container Plugin 4.1.2

VMware NSX Container Plugin 4.1.2 | 19. Oktober 2023 | Build 22596735 Prüfen Sie, ob Ergänzungen und Updates für diese Versionshinweise zur Verfügung stehen.

Neuigkeiten

• Unterstützung für das Erstellen neuer Cluster in TAS im Manager-Modus. Beachten Sie, dass diese Funktion in der nächsten Version nicht mehr unterstützt wird.

• Unterstützung für die Migration von TAS-Grundeinstellungen aus dem Manager-Modus in den Richtlinienmodus.

• Ein neues Runbook zum Generieren eines Debugging-Berichts für NCP-Konfigurationsschritte.

Einstellungsbenachrichtigung:

• Die NAT-Unterstützung für Ingress-Controller von Drittanbietern ist veraltet und wird in einer zukünftigen Version entfernt.

  Diese Funktion wird durch den Parameter „k8s.ingress_mode“ gesteuert und auf Ingress-Controller-Pods über die Anmerkung „ncp/ingress_controller“ aktiviert. Mit dieser Funktion wird der Ingress-Controller-Pod mit einer DNAT-Regel angezeigt. Die beste Möglichkeit, diese Pods verfügbar zu machen, besteht in der Verwendung eines Diensts vom Typ „LoadBalancer“.

• Die NSX OVS-Kernelmodule sind veraltet und werden in der nächsten Version entfernt.

• Multus wird nicht mehr unterstützt. Es wird in der nächsten Version entfernt.

Kompatibilitätsanforderungen

Produkt	Version
NCP-/NSX-Kachel für Tanzu Application Service (TAS)	4.1.2
NSX	3.2.3, 4.0.1, 4.1.1, 4.1.2
Kubernetes	1.25, 1.26, 1.27
OpenShift 4	4.11, 4.12
Kubernetes-Host-VM-Betriebssystem	Ubuntu 20.04 Ubuntu 22.04 mit Kernel 5.15 (sowohl NSX-OVS-Kernelmodul als auch Upstream-OVS-Kernelmodul werden unterstützt) Ubuntu 22.04 mit Kernel höher als 5.15 (nur Upstream-OVS-Kernelmodul wird unterstützt) RHEL 8.6, 8.8, 9.2 Weitere Informationen finden Sie unten in den Hinweisen.
Tanzu Application Service (TAS)	Ops Manager 2.10 + TAS 2.13 Ops Manager 3.0 + TAS 2.13 Ops Manager 2.10 + TAS 4.0 Ops Manager 3.0 + TAS 4.0 Ops Manager 2.10 + TAS 5.0 Ops Manager 3.0 + TAS 5.0
Tanzu Kubernetes Grid Integrated (TKGI)	1.18.0

Anmerkungen:

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:

• 4.1.0. 4.1.1 und alle 4.0.x-Versionen.

Einschränkungen

• Die Funktion „Baseline-Richtlinie“ für NCP erstellt eine dynamische Gruppe, die alle Mitglieder im Cluster auswählt. NSX-T hat einen Grenzwert von 8.000 effektiven Mitgliedern einer dynamischen Gruppe (weitere Informationen finden Sie unter Maximalwerte für die Konfiguration). Aus diesem Grund sollte diese Funktion nicht für Cluster aktiviert werden, bei denen ein Zuwachs auf über 8.000 Pods erwartet wird. Das Überschreiten dieses Grenzwerts kann zu Verzögerungen bei der Erstellung von Ressourcen für die Pods führen.

• Lastausgleichsdienst im transparenten Modus

  • Nur vertikaler Datenverkehr für einen Kubernetes-Cluster wird unterstützt. Intra-Cluster-Verkehr wird nicht unterstützt.

  • Wird nicht für Dienste unterstützt, die an eine LoadBalancer-CRD angehängt sind oder wenn die automatische Skalierung aktiviert ist. Die automatische Skalierung muss deaktiviert sein, damit diese Funktion funktioniert.

  • Es wird empfohlen, diese Funktion nur auf neu bereitgestellten Clustern zu verwenden.

• Manager-zu-Richtlinien-Migration

  • Es ist nicht möglich, einen Kubernetes-Cluster zu migrieren, wenn eine vorherige Migration fehlgeschlagen ist und für den Cluster ein Rollback durchgeführt wird. Dies ist nur bei NSX 4.0.0.1 oder früheren Versionen der Fall.

• Bei der Implementierung von Netzwerkrichtlinien, die Kriterien für mehrere Selektoren in Ingress-/Egress-Regeln verwenden, besteht das Risiko einer erheblichen Leistungsbeeinträchtigung bei der Berechnung der tatsächlichen Gruppenmitglieder mit Auswirkungen auf den Netzwerkdatenverkehr. Um diese Einschränkung zu beheben, gibt es eine neue Konfigurationsoption, enable_mixed_expression_groups, die sich auf Kubernetes-Netzwerkrichtlinien auswirkt, die Multi-Selektoren im Richtlinienmodus verwenden. Cluster im Manager-Modus sind davon nicht betroffen. Der Standardwert dieses Parameters ist „Falsch“. Wir empfehlen die folgenden Werte für Ihren Cluster:

  • TKGi

    • Neue Cluster, Richtlinienmodus: Falsch

    • Vorhandene Cluster (richtlinienbasiert): Wahr

    • Nach der Manager-zu-Richtlinie-Migration: Wahr

  • OC: Auf „Wahr“ setzen, um die Konformität mit der Kubernetes-Netzwerkrichtlinie sicherzustellen

  • DIY-Kubernetes

    • Neue Cluster (richtlinienbasiert): Falsch

    • Vorhandene Cluster (richtlinienbasiert): Wahr

    • Nach der Manager-zu-Richtlinie-Migration: Wahr

  Diese Einschränkung gilt, wenn enable_mixed_expression_groups auf „Wahr“ festgelegt ist. Das betrifft Installationen, die NCP Version 3.2.0 und höher sowie NSX-T Version 3.2.0 und höher verwenden. Es gibt keine Beschränkung für die Anzahl der Namensräume, die sich auf die Netzwerkrichtlinie auswirkt. Wenn diese Option auf „Wahr“ festgelegt ist und NCP neu gestartet wird, synchronisiert NCP alle Netzwerkrichtlinien erneut, um dieses Verhalten zu implementieren.

  Wenn enable_mixed_expression_groups auf „Falsch“ festgelegt ist, werden Netzwerkrichtlinien, die Kriterien für mehrere Selektoren in Ingress-/Egress-Regeln verwenden, mit dynamischen NSX-Gruppen realisiert, die bei der Berechnung der tatsächlichen Mitglieder nicht von Leistungsbeeinträchtigungen betroffen sind. Die Regeln können jedoch nur für bis zu 5 Namensräume erzwungen werden, abhängig von den anderen Kriterien, die in der Netzwerkrichtlinie definiert sind. Wenn sich die Netzwerkrichtlinie zu einem beliebigen Zeitpunkt auf mehr als 5 Namensräume auswirkt, wird sie mit „ncp/error: NETWORK_POLICY_VALIDATION_FAILED“ und in NSX nicht erzwungen. Beachten Sie, dass dies passieren kann, wenn ein neuer Namensraum erstellt wird, der die Bedingungen für mehrere Selektoren erfüllt, oder wenn ein vorhandener Namensraum aktualisiert wird. Wenn diese Option auf „Falsch“ festgelegt ist und NCP neu gestartet wird, synchronisiert NCP alle Netzwerkrichtlinien erneut, um dieses Verhalten zu implementieren.

Behobene Probleme

• Problem 3239352: Wenn in einer TAS-Umgebung eine Aufgabe nicht zugeteilt werden kann, funktioniert der erneute Versuch möglicherweise nicht

  Wenn in einer NCP TAS-Umgebung eine Aufgabe nicht zugeteilt werden kann, lehnt der Auktionator die Aufgabe ab und BBS versucht die erneute Platzierung der Aufgabe, bis die in der Einstellung „task.max_retries“ angegebenen Anzahl erreicht ist. Wenn der Wert aus „task.max_retries“ erreicht ist, aktualisiert BBS die Aufgabe vom Status AUSSTEHEND auf den Status ABGESCHLOSSEN. Außerdem wird sie als „Fehlgeschlagen“ markiert und eine FailureReason hinzugefügt, in der erklärt wird, dass der Cluster keine Kapazität für die Aufgabe hat.

  Während der Wiederholung kann die Aufgabe auf eine neue Zelle geplant werden, wodurch NCP mit dem Ereignis „task_changed“ benachrichtigt wird. Da das Ereignis „task_changed“ nicht von NCP verarbeitet wird, kann der Aufgabe kein neuer Port in der neuen Zelle zugewiesen werden. Die Aufgabe kann nicht ordnungsgemäß ausgeführt werden.

  Problemumgehung: Deaktivieren Sie die Wiederholung und setzen Sie den Wert von „task.max_retries“ auf 0.

• Problem 3043496: NCP wird nicht mehr ausgeführt, wenn die Manager-zu-Policy-Migration fehlschlägt

  NCP stellt den Migrate-mp2p-Auftrag bereit, um von NCP und TKGI verwendete NSX-Ressourcen zu migrieren. Wenn die Migration fehlschlägt, werden alle migrierten Ressourcen zurückgesetzt, aber NCP wird im Manager-Modus nicht neu gestartet.

  Problemumgehung:

  1. Stellen Sie sicher, dass alle Ressourcen zurückgesetzt wurden. Dies kann durch Überprüfen der Protokolle des migrate-mp2p-Auftrags erfolgen. Die Protokolle müssen mit der Zeile "Alle importierten MP-Ressourcen in Richtlinie vollständig zurückgesetzt" enden.

  2. Wenn alle Ressourcen zurückgesetzt wurden, melden Sie sich bei jedem Master-Knoten per SSH an und führen Sie den Befehl "sudo /var/vcap/bosh/bin/monit start ncp" aus.

• Problem 2939886: Die Migration von Objekten vom Manager- zum Richtlinienmodus schlägt fehl.

  Das Migrieren von Objekten vom Manager- zum Richtlinienmodus schlägt fehl, wenn Egress und Ingress in der Netzwerkrichtlinienspezifikation denselben Selektor aufweisen.

  Problemumgehung: Keine

Bekannte Probleme

• Problem 3293981: Wenn innerhalb eines kurzen Zeitraums zwei Ingresses mit „defaultBackend“ erstellt werden, tritt der Fehler DEFAULT_BACKEND_IN_USE auf

  Wenn innerhalb eines kurzen Zeitraums zwei Ingresses mit der Angabe defaultBackend erstellt werden, tritt möglicherweise bei beiden Ingresses der Fehler DEFAULT_BACKEND_IN_USE auf.

  Problemumgehung: Erstellen Sie jeweils nur ein Ingress. Löschen Sie defaultBackend aus beiden Ingresses und fügen Sie die Angabe jeweils nur zu einem Ingress hinzu, um den Fehler DEFAULT_BACKEND_IN_USE zu beheben.

• Problem 3292003: In einer OCP-Umgebung fällt der Knoten aus, nachdem das Merkmal (Taint) mit dem NoExecute-Effekt angewendet wurde

  Wenn Sie in einer OCP-Umgebung die Tolerierung {"effect":"NoExecute","operator":"Exists"} für das Knoten-Agent-DaemonSet entfernen und auf einem Knoten ein NoExecute-Effekt-Merkmal (Taint) hinzufügen (z. B. test=abc:NoExecute), fällt der Knoten möglicherweise aus. In diesem Szenario wird der Knoten-Agent-Pod aus dem Knoten mit dem Merkmal (Taint) entfernt. Während der Bereinigung des Knoten-Agent-Pods kann es passieren, dass die Verbindung des Knotens abbricht, weil der Knoten-Agent-Pod nicht ordnungsgemäß beendet wird und die Uplink-Schnittstelle des Knotens nicht ordnungsgemäß von „br-int“ zurück zu „ens192“ konfiguriert wird.

  Problemumgehung: Starten Sie die Knoten-VM von vCenter Server aus neu.

• Problem 3293969: Während des NCP-Upgrades in einer OCP-Umgebung wechselt ein Knoten zu „Nicht bereit“

  Während des NCP-Upgrades in einer OCP-Umgebung wird der Knoten-Agent neu gestartet. Es ist möglich, dass ein Knoten die Konnektivität verliert, weil der Knoten-Agent-Pod nicht ordnungsgemäß beendet wird und die Uplink-Schnittstelle des Knotens nicht korrekt von „br-int“ zurück zu „ens192“ konfiguriert wird. Für den Knotenstatus wird „NotReady“ angezeigt.

  Problemumgehung: Starten Sie die Knoten-VM von vCenter Server aus neu.

• Problem 3252571: Die Migration von Manager zu Richtlinie wird nicht abgeschlossen, wenn NSX Manager nicht mehr verfügbar ist

  Wenn NSX Manager während der Manager-zu-Richtlinie-Migration nicht verfügbar ist, wird die Migration möglicherweise nie abgeschlossen. Ein Hinweis darauf ist, dass die Protokolle keine Aktualisierungen zur Migration aufweisen.

  Problemumgehung: Stellen Sie die Verbindung mit NSX Manager wieder her, und starten Sie die Migration neu.

• Problem 3248662: Worker-Knoten kann nicht auf einen Dienst zugreifen. Der OVS-Flow für den Dienst wird nicht auf dem Knoten erstellt.

  Das nsx-kube-proxy-Protokoll enthält die Fehlermeldung „greenlet.error: kann nicht zu einem anderen Thread wechseln“.

  Problemumgehung: Starten Sie nsx-kube-proxy auf dem Knoten neu.

• Problem 3241693: Layer-7-Routen brauchen mehr als 10 Minuten, um zu funktionieren, wenn die Anzahl der erstellten Routen bestimmte Grenzen überschreitet

  In einer OpenShift-Umgebung können Sie mehr als 1000 Routen bereitstellen, indem Sie in der ConfigMap die Flags relax_scale_validation auf Wahr und l4_lb_auto_scaling auf Falsch setzen. Es dauert jedoch mehr als 10 Minuten, bis Routen funktionieren, wenn die Anzahl der erstellten Routen die Beschränkung überschreitet. Die Grenzwerte sind 500 HTTPS-Routen und 2000 HTTP-Routen.

  Problemumgehung: Überschreiten Sie die Grenzwerte für die Anzahl der Routen nicht. Wenn Sie 500 HTTPS plus 2000 HTTP-Routen erstellen, müssen Sie die Routen mithilfe einer großen Edge-VM bereitstellen.

• Problem 3158230: nsx-ncp-bootstrap-Container kann beim Laden von AppArmor-Profilen auf Ubuntu 20.04 nicht initialisiert werden

  Der nsx-ncp-bootstrap-Container in nsx-ncp-bootstrap DaemonSet kann aufgrund unterschiedlicher Paketversionen von AppArmor auf dem Hostbetriebssystem und dem Container-Image nicht initialisiert werden. Die Protokolle des Containers enthalten Meldungen wie „Fehler beim Laden von Richtlinienfunktionen aus '/etc/apparmor.d/abi/2.13': Datei oder Dateipfad nicht vorhanden.“

  Problemumgehung: Aktualisieren Sie AppArmor auf Version 2.13.3-7ubuntu5.2 oder auf die neueste verfügbare Version von focal-updates auf dem Hostbetriebssystem.

• Problem 3179549: Das Ändern des NAT-Modus für einen vorhandenen Namensraum wird nicht unterstützt

  Wenn Sie in einem Namensraum mit vorhandenen Pods den NAT-Modus von SNAT auf NO_SNAT ändern, verwenden die Pods weiterhin IP-Adressen, die von den in container_ip_blocks angegebenen IP-Blöcken zugewiesen werden. Wenn das Segment-Subnetz im Namensraum noch über verfügbare IP-Adressen verfügt, verwenden neu erstellte Pods weiterhin die IP-Adressen des bestehenden Segment-Subnetzes. Für ein neu erstelltes Segment wird das Subnetz aus no_snat_ip_block zugewiesen. Im Namensraum wird die SNAT-Regel jedoch gelöscht.

  Problemumgehung: Keine.

• Problem 3218243: Sicherheitsrichtlinien in NSX, die für Kubernetes-Netzwerkrichtlinien erstellt wurden, die Multi-Selektor-Kriterien verwenden, werden nach einem Upgrade von NCP auf Version 4.1.1 oder beim Erstellen/Aktualisieren von Namensräumen entfernt

  Prüfen Sie, ob die Option enable_mixed_expression_groups in NCP auf „Falsch“ festgelegt ist (Standardwert ist „Falsch“). Wenn dies der Fall ist, führt die Netzwerkrichtlinie zur Erstellung von mehr als 5 Gruppenkriterien auf NSX, was nicht unterstützt wird.

  Problemumgehung: Legen Sie enable_mixed_expression_groups in der NCP-Konfigurationszuordnung auf „Wahr“ fest und starten Sie NCP neu. Beachten Sie, dass bei der Berechnung des tatsächlichen Gruppenmitglieds das Risiko erheblicher Leistungsbeeinträchtigungen besteht, was sich in diesem Fall auf den Netzwerkdatenverkehr auswirkt.

• Problem 3235394: Die Baseline-Richtlinie mit der Namensraum-Einstellung funktioniert nicht in einem TKGI-Setup

  Wenn Sie in einer TGKI-Umgebung baseline_policy_type auf allow_namespace oder allow_namespace_strict festlegen, erstellt NCP eine explizite Baseline-Richtlinie, um nur Pods innerhalb desselben Namensraums zu erlauben, miteinander zu kommunizieren und Ingress von anderen Namensräumen abzulehnen. Diese Baseline-Richtlinie verhindert auch, dass ein System-Namensraum wie kube-system auf Pods in anderen Namensräumen zugreift.

  Problemumgehung: Keine. NCP unterstützt diese Funktion in einer TKGI-Einrichtung nicht.

• Problem 3179960: Die Anwendungsinstanz ist nach vMotion nicht erreichbar und hat die gleiche IP-Adresse wie eine andere Anwendungsinstanz

  Wenn viel vMotion stattfindet, z. B. während eines NSX-Host-Upgrades, gehen die Hosts nacheinander in den Wartungsmodus und Diego Cells migriert zwischen den Hosts. Nach dem vMotion-Vorgang fehlen möglicherweise einige Segmentports, einige Anwendungsinstanzen sind möglicherweise nicht erreichbar und zwei Anwendungsinstanzen verfügen möglicherweise über dieselbe IP-Adresse. Dieses Problem tritt eher bei TAS 2.13.18 auf.

  Problemumgehung: Erstellen Sie die von diesem Problem betroffenen Anwendungsinstanzen neu.

• Problem 3108579: Das Löschen von LB-CRD und die sofortige Neuerstellung mit demselben geheimen Schlüssel schlägt fehl

  Wenn Sie im Managermodus den Ingress auf einem LB CRD löschen, LB CRD löschen und sofort den Ingress und LB CRD mit demselben Zertifikat neu erstellen, wird möglicherweise der Fehler „Es wurde versucht, ein Zertifikat zu importieren, das bereits importiert wurde“ angezeigt. Dies ist auf ein Zeitproblem zurückzuführen, da die Löschung von LB CRD warten muss, bis die Löschung von Ingress abgeschlossen ist.

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

  – Führen Sie den folgenden Befehl aus, um zu warten, bis die Löschung von Ingress abgeschlossen ist, und löschen Sie dann LB CRD.

  • kubectl exec -ti <pod name> -nnsx-system -- nsxcli -c get ingress-caches|grep ‘name: <Ingress name>’

  – Warten Sie mindestens 2 Minuten, bevor Sie die Ingress- und LB-CRD neu erstellen.

• Problem 3221191: Die Erstellung einer Domänengruppe schlägt fehl, wenn der Cluster über mehr als 4000 Pods verfügt

  Wenn die NCP-Option k8s.baseline_policy_type auf allow_cluster, allow_namespace oder allow_namespace_strict festgelegt ist und der Cluster über mehr als 4000 Pods verfügt, kann eine Domänengruppe (mit einem Namen wie dg-k8sclustername), die alle IP-Adressen der Pods enthält, nicht erstellt werden. Dies wird durch eine Einschränkung von NSX verursacht.

  Problemumgehung: Nutzen Sie nicht die Option k8s.baseline_policy_type oder stellen Sie sicher, dass sich weniger als 4000 Pods im Cluster befinden.

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

• Problem 2999131: ClusterIP-Dienste sind von den Pods aus nicht erreichbar

  In einer großen TKGi-Umgebung sind ClusterIP-Dienste von den Pods aus nicht erreichbar. Weitere damit verbundene Probleme sind: (1) Der nsx-kube-proxy beendet die Ausgabe der Protokolle von nsx-kube-proxy; und (2) Die OVS-Flows werden nicht auf dem Knoten erstellt.

  Problemumgehung: Starten Sie nsx-kube-proxy neu.

• Problem 2984240: Der Operator "NotIn" in matchExpressions funktioniert nicht in namespaceSelector für die Regel einer Netzwerkrichtlinie

  Wenn Sie beim Angeben einer Regel für eine Netzwerkrichtlinie namespaceSelector, matchExpressions und den Operator "NotIn" angeben, funktioniert die Regel nicht. Das NCP-Protokoll enthält die Fehlermeldung "NotIn-Operator wird in NS-Selektoren nicht unterstützt."

  Problemumgehung: Schreiben Sie matchExpressions um, um die Verwendung des "NotIn"-Operators zu vermeiden.

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

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

• 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 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 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 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 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 2824129: Ein Knoten hat nach einem Neustart mehr als 3 Minuten lang bei „Netzwerk nicht verfügbar“ den Status „true“.

  Wenn Sie den NCP-Operator zum Verwalten des Lebenszyklus von NCP verwenden und ein „nsx-node-agent“-Daemonset aus einem nicht ausgeführten Zustand wiederhergestellt wird, hat sein Knoten bei „Netzwerk nicht verfügbar“ den Status „true“, bis er 3 Minuten lang ausgeführt wurde. Dies ist das erwartete Verhalten.

  Problemumgehung: Warten Sie nach dem Neustart von „nsx-node-agent“ mindestens 3 Minuten.

• Problem 2832480: Für einen Kubernetes-Dienst vom Typ „ClusterIP“ darf „sessionAffinityConfig.clientIP.timeoutSeconds“ 65.535 nicht überschreiten

  Wenn Sie für einen Kubernetes-Dienst vom Typ „ClusterIP“ „sessionAffinityConfig.clientIP.timeoutSeconds“ auf einen Wert über 65.535 festlegen, lautet der tatsächliche Wert 65.535.

  Problemumgehung: Keine

• Problem: 2940772: Das Migrieren von NCP-Ressourcen von Manager zu Richtlinie führt zu einem Fehler mit NSX-T 3.2.0.

  Die Migration von NCP-Ressourcen von Manager zu Richtlinie wird mit NSX-T 3.1.3 und NSX-T 3.2.1, aber nicht mit NSX-T 3.2.0 unterstützt.

  Problemumgehung: Keine

• Problem 2934195: Einige Typen von NSX-Gruppen werden für verteilte Firewall-Regeln nicht unterstützt

  Eine NSX-Gruppe vom Typ „Nur IP-Adressen“ wird für verteilte Firewall-Regeln (DFW) nicht unterstützt. Eine NSX-Gruppe vom Typ "Generisch" mit manuell hinzugefügten IP-Adressen als Mitglieder wird ebenfalls nicht unterstützt.

  Problemumgehung: Keine

• Problem 3066449: Namespace-Subnetze werden nicht immer aus dem ersten verfügbaren IP-Block zugeteilt, wenn use_ip_blocks_in_order auf "True" festgelegt ist

  Wenn beim Erstellen mehrerer Namespaces "use_ip_blocks_in_order" auf "True" gesetzt ist, wird das Subnetz des ersten Namespace manchmal nicht aus dem ersten verfügbaren IP-Block zugeteilt. Angenommen, container_ip_blocks = '172.52.0.0/28,172.53.0.0/28', die Länge des Subnetz-Präfix bist 29 und das Subnetz 172.52.0.0/29 ist bereits zugeteilt. Wenn Sie 2 Namespaces, ns-1 und ns-2, erstellen, kann die Subnetzzuteilung (1) ns-1 sein: 172.52.0.8/29, ns-2: 172.53.0.0/29, oder (2) ns-1: 172.53.0.0/29, ns-2: 172.52.0.8/29.

  Der Parameter use_ip_blocks_in_order stellt nur sicher, dass verschiedene IP-Blöcke in der Reihenfolge verwendet werden, in der sie im Parameter container_ip_blocks festgelegt sind. Wenn Sie mehrere Namespaces gleichzeitig erstellen, kann jeder Namespace ein Subnetz über einen API-Aufruf vor einem anderen Namespace anfordern. Daher gibt es keine Garantie dafür, dass einem bestimmten Namespace ein Subnetz aus einem bestimmten IP-Block zugeteilt wird.

  Problemumgehung: Erstellen Sie die Namespaces separat, d. h. erstellen Sie den ersten Namespace, stellen Sie sicher, dass dessen Subnetz zugeteilt wurde, und erstellen Sie dann den nächsten Namespace.