Versionshinweise zu VMware NSX Container Plugin 3.2.1.1

VMware NSX Container Plugin 3.2.1.1 | 17. Mai 2022 | Build 19750154 Prüfen Sie, ob Ergänzungen und Updates für diese Versionshinweise zur Verfügung stehen.

Neuigkeiten

• Unterstützung für die Bereitstellung von OCP-Worker-Knoten mit mehreren vNICs

  Die Bereitstellung von OCP-Worker-Knoten mit mehreren vNICs wird unterstützt, wobei davon ausgegangen wird, dass die erste vNIC für das Containernetzwerk verwendet wird.

• Unterstützung für die Option „natfirewallmatch“

  Die Option „natfirewallmatch“ gibt an, wie sich die NSX-T-Gateway-Firewall mit NAT-Regeln verhält, die für einen Kubernetes-Namespace erstellt wurden. Diese Option gilt nur für neu erstellte Kubernetes-Namespaces und nicht für vorhandene Namespaces.

Einstellungsbenachrichtigung:

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

Die Funktion, die den Zugriff über NAT auf Ingress-Controller-Pods mithilfe der Anmerkung ncp/ingress_controller ermöglicht, ist veraltet und wird 2023 entfernt. Die empfohlene Möglichkeit, Ingress-Controller-Pods verfügbar zu machen, ist die Verwendung von Diensten vom Typ LoadBalancer.

Kompatibilitätsanforderungen

Produkt	Version
NCP-/NSX-T-Kachel für Tanzu Application Service (TAS)	3.2.1
NSX-T	3.1.3, 3.2, 3.2.1 (siehe Hinweise unten)
vSphere	6.7, 7.0
Kubernetes	1.21, 1.22, 1.23
OpenShift 4	4.7, 4.8, 4.9
OpenShift-Host-VM-Betriebssystem	RHCOS 4.7, 4.8
Kubernetes-Host-VM-Betriebssystem	Ubuntu 18.04, 20.04 CentOS 8.2 RHEL 8.4, 8.5 Weitere Informationen finden Sie unten in den Hinweisen.
Tanzu Application Service	Ops Manager 2.10 + TAS 2.11 Ops Manager 2.10 + TAS 2.12 (Ende des Supports: 31. März 2023)
Tanzu Kubernetes Grid Integrated (TKGI)	1.13.6, 1.14

Anmerkungen:

Die Installation des NSX-OVS-Kernelmoduls unter CentOS/RHEL erfordert eine bestimmte Kernelversion. Die unterstützten CentOS/RHEL-Kernelversionen sind unabhängig von der CentOS/RHEL-Version 193, 305 und 348. Beachten Sie, dass die Standardkernelversion 193 für RHEL 8.2, 305 für RHEL 8.4 und 348 für RHEL 8.5 ist. Wenn Sie eine andere Kernel-Version ausführen, können Sie (1) Ihre Kernel-Version in eine unterstützte Version ändern. Stellen Sie beim Ändern der Kernel-Version und anschließendem Neustart der VM sicher, dass die IP-Adresse und die statischen Routen auf der Uplink-Schnittstelle (angegeben durch ovs_uplink_port) beibehalten werden, damit die Konnektivität zum Kubernetes-API-Server nicht unterbrochen wird. Oder (2) überspringen Sie die Installation des NSX-OVS-Kernelmoduls, 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/CentOS auszuführen, müssen Sie die Option „UEFI Secure Boot“ unter „Startoptionen“ in den VM-Einstellungen in vCenter Server deaktivieren.

Ab NCP 3.1.2 wird das RHEL-Image nicht 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.

TKGI 1.14.0 ist im Lieferumfang von NCP 3.2.1.0 enthalten, das NSX-T 3.2.1 nicht unterstützt.

TKGI 1.13.x und TKGI 1.14.x sind nicht kompatibel mit NSX-T 3.2.0.x.

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

• Alle 3.1.x-Versionen

• Alle vorherigen 3.2.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.

Behobene Probleme

• Problem 3042916: nsx-kube-proxy schlägt nach dem Start mit dem Fehler "Ungültiger oder unbekannter Port für in_port" fehl

  In seltenen Fällen schlägt nsx-kube-proxy kurz nach dem Start fehl, da der OVS-Uplink "ofport" zu diesem Zeitpunkt leer ist. Das Protokoll enthält die Fehlermeldung "RuntimeError: Schwerwiegender Fehler beim Ausführen von xxx: (): Ungültiger oder unbekannter Port für in_port."

  Problemumgehung: Starten Sie nsx-kube-proxy neu.

• Problem 2863155: Einige Cluster-IP-Dienste sind in einer großen Umgebung nicht über Pods erreichbar.

  In einer großen Umgebung kann die große Protokollgröße Probleme mit nsx-kube-proxy verursachen. Einige Cluster-IP-Dienste sind von Pods nicht erreichbar und nsx-kube-proxy kann den eigenen Status nicht in nsxcli melden.

  Problemumgehung: Starten Sie nsx-kube-proxy neu.

• Problem 2944368: Eine Ingress-Regel mit der Angabe „host“ entspricht sowohl dem Host als auch dem Host mit einem Suffix.

  Beispiel: Eine Regel, die als Host „test.co“ angibt, stimmt mit „test.co“ und „test.de“ überein.

  Problemumgehung: Keine

• Problem 2882699: In einer IPv6-Umgebung führt die Einstellung von baseline_policy_type auf allow_namespace_strict zu Kommunikationsfehlern.

  In einer IPv6-Umgebung, in der baseline_policy_type auf allow_namespace_strict festgelegt ist, können Pods nicht auf Kubernetes-Knoten zugreifen.

  Problemumgehung: Fügen Sie eine Regel für die verteilte Firewall mit einer höheren Priorität als die Baseline-Regel hinzu, um Datenverkehr von Pods zu Kubernetes-Knoten zuzulassen.

• Problem 2867871: Der Zugriff auf den „clusterIP“-Dienst von Pods, auf die der Dienst verweist, schlägt fehl, wenn sich der Kubernetes-Knotenname der Pods vom Hostnamen unterscheidet.

  NCP unterstützt derzeit den Pod-Self-Access auf den „clusterIP“-Dienst nur dann, wenn der Kubernetes-Knotenname mit dem Hostnamen identisch ist. Dies liegt daran, dass „nsx-kube-proxy“ den Selbstzugriffsablauf nur dann hinzufügt, wenn der Hostname mit dem Knotennamen identisch ist.

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

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

• Problem 2960121: Die Dienste des Typs „LoadBalancer-Konnektivität“ mit Pods auf Windows Worker-Knoten schlagen fehl, wenn sie nicht ordnungsgemäß konfiguriert sind.

  Die Dienste des Typs „LoadBalancer-Konnektivität“ mit Pods auf Windows Worker-Knoten schlagen fehl, wenn NCP für die Verwendung des LB-Segment-Subnetzes konfiguriert ist. Das Standard-Subnetz 169.254.128.0/22 gehört zum linklokalen IPv4-Bereich und wird nicht auf einem Windows-Knoten weitergeleitet.

  Problemumgehung: Konfigurieren Sie NCP für die Verwendung eines nicht standardmäßigen LB-Segment-Subnetzes. Legen Sie dazu den Parameter „lb_segment_subnet“ im Abschnitt „nsx_v3“ fest. Beachten Sie, dass dies nur Auswirkungen auf neu erstellte NSX Load Balancer hat.

• Problem 2972811: In einer großen Umgebung fällt die Hyperbus-Verbindung zu einigen Worker-Knoten aus.

  In einer großen Umgebung kann die Pod-Erstellung aufgrund einer Zeitüberschreitung des RPC-Kanals für 10 bis 15 Minuten hängenbleiben. Folgende Probleme können auftreten:

  • In einem Kubernetes-Cluster weisen einige Pods für 10 bis 15 Minuten den Status „ContainerCreating“ auf.

  • Im cfgAgent hat der Tunnel 10 bis 15 Minuten lang den Status „COMMUNICATION_ERROR“.

  • In der NSX-Benutzeroberfläche wird möglicherweise ein Alarm generiert, der darauf hinweist, dass die Hyperbus-Verbindung ausgefallen ist.

  Problemumgehung: Nicht erforderlich. Dieses Problem wird nach 10 bis 15 Minuten automatisch behoben.

• Problem: 2966586: Nach der Migration von Manager-Objekten zur Richtlinie schlägt die Namespace-Erstellung fehl.

  Wenn ein IP-Block im Managermodus erstellt wird, schlägt die Namespace-Erstellung nach der Migration von Managerobjekten zur Richtlinie fehl, da NCP keine Subnetze aus diesem IP-Block zuteilen kann.

  Problemumgehung: Erstellen Sie neue IP-Blöcke im Richtlinienmodus und konfigurieren Sie NCP für die Verwendung dieser neuen IP-Blöcke.

• Problem: 2961789: Nach der Migration von Manager-Objekten zur Richtlinie können einige der Ressourcen des Integritätsprüfungs-Pods nicht gelöscht werden.

  Wenn Sie nach der Migration von Manager-Objekten zur Richtlinie den Integritätsprüfungs-Pod löschen, werden der zugehörige Segmentport des Pods und die Zielgruppe der Regel für die verteilte Firewall nicht gelöscht.

  Problemumgehung: Löschen Sie diese Ressourcen manuell.

• Problem 2923436: Ein langer Kubernetes-Ressourcenname führt zu einem Fehler.

  Wenn ein Kubernetes-Ressourcenname zu lang ist, kann die entsprechende NSX-Ressource nicht erstellt werden, da der NSX-Ressourcenname die Grenzwerte für Anzeigenamen in NSX überschreitet. Das Protokoll zeigt eine Fehlermeldung wie „Validierungsfehler auf Feldebene: {display_name ipp-k8scl-two-aaaaaa... hat die maximal zulässige Länge von 255 Zeichen überschritten}“. Für NSX gelten folgende Grenzwerte:

  • Anzeigenamen für Segmente: 80 Zeichen

  • Gruppen- + Domänenname: 245 Zeichen

  • Anzeigename für andere NSX-Ressourcen: 255 Zeichen

  Problemumgehung: Verkürzen Sie den Kubernetes-Ressourcennamen.

• 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

• Problem 2936436: Die NSX Manager-Benutzeroberfläche zeigt die NCP-Version nicht auf der Seite des Container-Clusters an.

  Wenn die NSX Manager-Benutzeroberfläche die Container-Cluster auf der Registerkarte „Bestandsliste“ anzeigt, wird die NCP-Version nicht angezeigt.

  Problemumgehung: Die NCP-Version ist durch Aufrufen der API /policy/api/v1/fabric/container-clusters verfügbar.

• 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: 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 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 2868572: Open vSwitch (OVS) muss auf der Host-VM deaktiviert werden, bevor NCP ausgeführt wird.

  Um NCP auf einer Host-VM bereitzustellen, müssen Sie zuerst OVS-bezogene Prozesse beenden und einige Dateien auf dem Host mit den folgenden Befehlen löschen:

  1. sudo systemctl disable openvswitch-switch.service

  2. sudo systemctl stop openvswitch-switch.service

  3. rm -rf /var/run/openvswitch

  Wenn Sie NCP bereits auf einer Host-VM bereitgestellt haben und OVS nicht ordnungsgemäß ausgeführt wird, führen Sie die folgenden Schritte zur Wiederherstellung aus:

  1. Führen Sie die 3 oben genannten Schritte aus.

  2. Löschen Sie „nsx-node-agent“-Pods auf den Knoten, die das Problem haben, die Knotenagent-Pods mit dem Befehl „kubectl delete pod $agent-pod -n nsx-system“ neu zu starten.

  Problemumgehung: Siehe oben.

• Problem 2867361: „nsx-node-agent“- und „hyperbus“-Alarme werden nach der NCP-Bereinigung nicht entfernt.

  Wenn „nsx-node-agent“- und „hyperbus“-Alarme aus irgendeinem Grund angezeigt werden (z. B. beim Beenden aller NSX-Knoten-Agents) und Sie NCP anhalten sowie das Bereinigungsskript ausführen, bleiben die Alarme nach der Bereinigung erhalten.

  Problemumgehung: Keine

• 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 2841030: Bei Kubernetes 1.22 lautet der Status von „nsx-node-agent“ immer „AppArmor“.

  Wenn in Kubernetes 1.22 die „nsx-node-agent“-Pods „Bereit“ sind, wird ihr Status nicht von „AppArmor“ auf „Wird ausgeführt“ aktualisiert. Dies hat keine Auswirkungen auf die Funktionalität von NCP oder „nsx-node-agent“.

  Problemumgehung: Starten Sie die „nsx-node-agent“-Pods neu.

• Problem 2860091: DNS-Datenverkehr schlägt fehl, wenn für „baseline_policy_type“ „allow_namespace“ festgelegt ist.

  Wenn für „baseline_policy_type“ in einer OpenShift- oder Kubernetes-Umgebung „allow_namespace“ festgelegt ist, werden Pods (hostNetwork: False) in anderen Namespaces für den Zugriff auf den DNS-Dienst blockiert.

  Problemumgehung: Fügen Sie eine Regelnetzwerkrichtlinie hinzu, um Datenverkehr von anderen Pods zu den DNS-Pods zuzulassen.

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

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

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