|
VMware NSX Container Plugin 3.2.0.1 | 11. November 2021 | Build 18876345 Ü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
- Unterstützung für die Verwendung desselben Wildcard-Zertifikats in Kubernetes-Ingress für mehrere Kubernetes-Cluster (mehrere NCP-Instanzen).
- Unterstützung für die Installation von OpenShift mit NCP mithilfe der Methode IPI (Installer Provisioned Infrastructure) zusätzlich zur METHODE UPI (User Provisioned Infrastructure).
- Neue Konfigurationsoption "baseline_policy_type: allow_namespace_strict". Wenn diese Option festgelegt ist, besteht die Standardrichtlinie darin, jegliche Kommunikation zwischen Namespaces und an externe Dienste zu verwerfen, es sei denn, dies ist ausdrücklich von der Kubernetes-Netzwerkrichtlinie oder manuellen NSX-T-Administratorrichtlinien zulässig.
- Unterstützung für das neue endPort-Feld für Kubernetes-Netzwerkrichtlinien.
- Subnetze für einen Kubernetes-Namespace können angegeben werden. (Wenn IPv6-Subnetze angegeben werden, wird das 64-Bit-Subnetzpräfix nicht unterstützt.)
- Persistente IP-Zuteilung für StatefulSet basierend auf Namespace-Subnetz.
- Mögliche Erstellung der Client-IP-basierten Sitzungsaffinität für einen Kubernetes-Dienst des Typs „ClusterIP“. Diese Funktion ist auch im Manager-Modus verfügbar.
- TAS im Richtlinienmodus.
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.2 |
| NSX-T | 3.1.2, 3.1.3 |
| vSphere | 6.7, 7.0 |
| Kubernetes | 1.19, 1.20, 1.21, 1.22 |
| OpenShift 4 | RHCOS 4.6, 4.7, 4.8 |
| Kubernetes-Host-VM-Betriebssystem | Ubuntu 18.04, 20.04 CentOS 7.8, 7.9, 8.2 RHEL 8.2, 8.4 Weitere Informationen finden Sie unten in den Hinweisen. |
| Tanzu Application Service | Ops Manager 2.7 + TAS 2.7 (LTS) (Ende des Supports: 30. April 2022) Ops Manager 2.10 + TAS 2.10 (Ende des Supports: 31. März 2022) 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 |
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 1127, 1160, 193, 240 und 305. Beachten Sie, dass die Standardkernelversion 1127 für RHEL 7.8, 1160 für RHEL 7.9, 193 für RHEL 8.2, 240 für RHEL 8.3 und 305 für RHEL 8.4 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 8.2 (Kernelversion 193) 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.
Unterstützung für das Upgrade auf diese Version:
- Alle vorherigen 3.1.x-Versionen
Behobene Probleme
- 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
- 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 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 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.
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 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.
- 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 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 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 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.
- 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 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 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 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 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 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 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 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 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 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 2869247: Auf dem Ubuntu 18.04-Hostbetriebssystem wird der „nsx-ovs“-Container weiterhin neu gestartet.
Der „nsx-ovs“-Container wird weiterhin neu gestartet, da seine Aktivitätsprobe weiterhin fehlschlägt. „/var/log/nsx-ujo/openvswitch/ovs-vswitchd.log“ enthält ein Protokoll, das angibt, dass er weiterhin neu gestartet wird. Beispiel:
2021-10-28T17:38:49.364Z|00004|backtrace(monitor)|WARN|Backtrace using libunwind not supported. 2021-10-28T17:38:49.364Z|00005|daemon_unix(monitor)|WARN|2 crashes: pid 282 died, killed (Aborted), core dumped, waiting until 10 seconds since last restart 2021-10-28T17:38:57.364Z|00006|daemon_unix(monitor)|ERR|2 crashes: pid 282 died, killed (Aborted), core dumped, restarting
Dieses Problem wird durch eine Inkompatibilität zwischen den installierten Upstream-OVS-Benutzerspeicherplatzpaketen im „nsx-ovs“-Container und dem OVS-Kernelmodul auf dem Host verursacht.
Problemumgehung: Aktualisieren Sie das Hostbetriebssystem auf Ubuntu 20.0 oder führen Sie die folgenden Schritte aus, um die von NSX bereitgestellten OVS-Kernelmodule zu verwenden:
- Legen Sie für „use_nsx_ovs_kernel_module“ in der Konfigurationszuordnung von „nsx-node-agent“ „True“ fest.
- Heben Sie die Kommentierung der Volume-Mounts im „nsx-ncp-bootstrap“-DaemonSet auf (suchen Sie in der Datei „ncp-ubuntu*.yaml“ nach „Kommentierung dieser Mounts bei der Installation des NSX-OVS-Kernelmoduls aufheben“ und „Kommentierung dieser Volumes beim Installieren des NSX-OVS-Kernelmoduls aufheben“).
- Wenden Sie die Datei „ncp-ubuntu*.yaml“ erneut an und starten Sie die „nsx-node-agent“-Pods neu.
- 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 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:
- sudo systemctl disable openvswitch-switch.service
- sudo systemctl stop openvswitch-switch.service
- 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:
- Führen Sie die 3 oben genannten Schritte aus.
- 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 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 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 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 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 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 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 FailureReasion 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.
