nsx container plug-in 3.0, 3.0.1 vmware nsx-t data center 3€¦ · nsx container plug-in für...

NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch

NSX Container Plug-in 3.0, 3.0.1, 3.0.2

VMware NSX-T Data Center 3.0

Die aktuellste technische Dokumentation finden Sie auf der VMware-Website unter:

https://docs.vmware.com/de/

VMware, Inc.3401 Hillview Ave.Palo Alto, CA 94304www.vmware.com

VMware Global, Inc.Zweigniederlassung DeutschlandWilly-Brandt-Platz 281829 MünchenGermanyTel.: +49 (0) 89 3706 17 000Fax: +49 (0) 89 3706 17 333www.vmware.com/de

Copyright ©

2017-2020 VMware, Inc. Alle Rechte vorbehalten. Urheberrechts- und Markenhinweise.


VMware, Inc. 2

https://docs.vmware.com/de/

http://pubs.vmware.com/copyright-trademark.html

Inhalt

NSX Container Plug-in für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch 5

1 Übersicht über NSX Container Plug-in 6Kompatibilitätsanforderungen 7

Überblick über die Installation 7

2 Einrichten von NSX-T-Ressourcen 9Konfigurieren von NSX-T-Ressourcen im Richtlinienmodus 9

Konfigurieren von NSX-T-Ressourcen im Managermodus 12

Konfigurieren von SNAT 15

3 Installieren von NCP in einer Kubernetes-Umgebung 22Herunterladen der Protokolldateien 22

Vorbereiten von Kubernetes-Knoten 23

Erstellen von geheimen Schlüsseln – Kubernetes 25

Konfigurieren von NSX-T Data Center-Netzwerken für Kubernetes-Knoten 25

Bearbeiten der NCP-YAML-Datei 26

Die nsx-ncp-config ConfigMap 32

Die nsx-node-agent-config ConfigMap 43

Anwenden der NCP-YAML-Datei 47

Bereitstellen einer Zertifikatdatei im NCP-Pod 47

Konfigurieren von IPv6 48

Konfigurieren von Syslog 49

Erstellen eines Sidcar-Containers für Syslog 50

Erstellen eines DaemonSet-Replikats für Syslog 52

Beispiel: Konfigurieren der Protokollrotation und des in einem Sidecar-Container ausgeführten Syslogs 53

Sicherheitsüberlegungen 60

Konfigurieren von Netzwerkressourcen 61

Kubernetes-Knoten bereinigen 63

4 Installieren von NCP in einer Pivotal Cloud Foundry(PCF)-Umgebung 66Installieren von NCP in einer Pivotal Cloud Foundry(PCF)-Umgebung 66

Verarbeiten von in PAS erstellten benutzerdefinierten Bezeichnungen 69

5 Load Balancing 70Konfigurieren von Load Balancing 70

VMware, Inc. 3

Festlegen der Persistenz für den Load Balancer auf Schicht 4 und Schicht 7 71

Ingress 72

LoadBalancer CRDs to Handle Ingress Scaling 81

Dienst vom Typ LoadBalancer 84

Load Balancer und Netzwerkrichtlinie 86

Beispielskript zum Generieren eines von einer Zertifizierungsstelle signierten Zertifikats 87

Ingress-Controller von Drittanbietern 87

6 Upgrade von NCP 91Upgrade von NCP in einer Kubernetes-Umgebung 91

Upgrade von NCP in einer Pivotal Cloud Foundry(PCF)-Umgebung 93

7 Importieren von Managerobjekten in den Richtlinienmodus 94Workflow zum Importieren von Managerobjekten in den Richtlinienmodus 94

Importieren von gemeinsam genutzten Ressourcen 95

Importieren eines Kubernetes-Clusters 97

Grundlegendes zum Importvorgang 98

Fehler und Wiederherstellung 100

Benutzerdefinierte Ressourcen 100

Einschränkungen und Problemumgehungen 102

Reihenfolge der Ressourcenspezifikation 103

Beispiel für config.yaml 104

Beispiel für user-spec.yaml 106

8 Verwalten von NSX Container Plug-in 111Anzeigen von in der Kubernetes-Ressource NSXError gespeicherten Fehlerinformationen 111

Bereinigen der NSX-T-Umgebung 113

Ändern des Cluster-Namens eines laufenden Clusters 115

CLI-Befehle 115

Fehlercodes 133


VMware, Inc. 4

NSX Container Plug-in für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch

In diesem Handbuch wird die Installation und Verwaltung von NSX Container Plug-in (NCP) zur Bereitstellung von Integration zwischen NSX-T Data Center und Kubernetes sowie zwischen NSX-T Data Center und Pivotal Cloud Foundry (PCF) beschrieben.

Zielgruppe

Dieses Handbuch ist für die System-und Netzwerkadministratoren bestimmt. Es wird vorausgesetzt, dass Sie mit der Installation und Verwaltung von NSX-T Data Center, Kubernetes und Pivotal Cloud Foundry vertraut sind.

VMware Technical Publications – Glossar

VMware Technical Publications enthält ein Glossar mit Begriffen, die Ihnen möglicherweise unbekannt sind. Definitionen von Begriffen, die in der technischen Dokumentation von VMware verwendet werden, finden Sie unter http://www.vmware.com/support/pubs.

VMware, Inc. 5

http://www.vmware.com/support/pubs

Übersicht über NSX Container Plug-in 1NSX Container Plug-in (NCP) stellt Integration zwischen NSX-T Data Center und Container-Orchestrierung wie z. B. Kubernetes sowie Integration zwischen NSX-T Data Center und Container-basierten PaaS-Produkten (Platform-as-a-Service), wie z. B. OpenShift und Pivotal Cloud Foundry, bereit. In diesem Handbuch wird die Einrichtung von NCP mit Kubernetes und Pivotal Cloud Foundry beschrieben.

Die Hauptkomponente von NCP wird in einem Container ausgeführt und kommuniziert mit NSX Manager und mit der Kubernetes-Control Plane. NCP überwacht Änderungen an den Containern und anderen Ressourcen und verwaltet Netzwerkressourcen wie logische Ports, Switches, Router und Sicherheitsgruppen für die Container per Aufruf der NSX API.

Das NSX CNI-Plugin wird auf jedem Kubernetes-Knoten ausgeführt. Es überwacht Ereignisse im Container-Lebenszyklus, verbindet eine Containerschnittstelle mit dem Gast-vSwitch und programmiert den Gast-vSwitch für die Kennzeichnung und Weiterleitung des Containerdatenverkehrs zwischen den Containerschnittstellen und der VNIC.

NCP bietet die folgenden Funktionen:

n Es erstellt automatisch eine logische NSX-T Data Center-Topologie für einen Kubernetes-Cluster und erstellt ein separates logisches Netzwerk für jeden Kubernetes-Namespace.

n Es verbindet Kubernetes-Pods mit dem logischen Netzwerk und weist IP- und MAC-Adressen zu.

n Es unterstützt Netzwerkadressübersetzung (Network Address Translation – NAT) und weist eine separate SNAT-IP für jeden Kubernetes-Namespace zu.

Hinweis Bei der Konfiguration von NAT darf die Gesamtzahl der übersetzten IPs 1000 nicht überschreiten.

n Es implementiert Kubernetes-Netzwerkrichtlinien mit verteilter NSX-T Data Center-Firewall.

n Unterstützung für Ingress- und Egress-Netzwerkrichtlinien.

n Unterstützung für IPBlock-Selektor in Netzwerkrichtlinien.

n Unterstützung für matchLabels und matchExpression beim Angeben von Bezeichnungsselektoren für Netzwerkrichtlinien.

VMware, Inc. 6

n Unterstützung für die Auswahl von Pods in einem anderen Namespace.

n Es implementiert einen Kubernetes-Dienst des Typs ClusterIP und einen Dienst des Typs LoadBalancer.

n Es implementiert Kubernetes-Ingress mit NSX-T-Load Balancer der Schicht 7.

n Unterstützung für HTTP-Ingress und HTTPS-Ingress mit TLS-Edge-Beendigung.

n Unterstützung für Standard-Backend-Konfiguration für den Ingress.

n Unterstützung für Umleitung auf HTTPS, Pfad Umschreibung und Pfad Musterübereinstimmung.

n Es erstellt auf dem logischen NSX-T Data Center-Switch Port Tags für den Namespace, den Pod-Namen und die Bezeichnungen eines Pods und lässt zu, dass der Administrator die NSX-T-Sicherheitsgruppen und -richtlinien basierend auf den Tags festlegt.

In dieser Version unterstützt NCP einen einzelnen Kubernetes-Cluster. Es besteht die Möglichkeit, für mehrere Kubernetes-Cluster, jeweils mit einer eigenen eindeutigen NCP-Instanz, die gleiche NSX-T Data Center-Bereitstellung zu verwenden.

Dieses Kapitel enthält die folgenden Themen:

n Kompatibilitätsanforderungen

n Überblick über die Installation

Kompatibilitätsanforderungen

Informationen zu den Kompatibilitätsanforderungen finden Sie in den Versionshinweisen.

Versionshinweise für NCP 3.0.0: https://docs.vmware.com/de/VMware-NSX-T-Data-Center/3.0/rn/NSX-Container-Plugin-30-Release-Notes.html

Versionshinweise für NCP 3.0.1: https://docs.vmware.com/de/VMware-NSX-T-Data-Center/3.0/rn/NSX-Container-Plugin-301-Release-Notes.html

Überblick über die Installation

In einer Umgebung, in der Kubernetes bereits installiert ist, beinhaltet die NCP-Installation und -Konfiguration in der Regel die folgenden Schritte. Zur erfolgreichen Durchführung der Schritte müssen Sie mit NSX-T Data Center sowie der Installation und Verwaltung von Kubernetes vertraut sein.

1 Installieren Sie NSX-T Data Center.

2 Erstellen Sie eine Overlay-Transportzone.

3 Erstellen Sie einen logischen Overlay-Switch, und verbinden Sie die Kubernetes-Knoten mit dem Switch.

4 Erstellen Sie einen logischen Tier-0-Router.


VMware, Inc. 7

https://docs.vmware.com/de/VMware-NSX-T-Data-Center/3.0/rn/NSX-Container-Plugin-30-Release-Notes.html




5 Erstellen Sie IP-Blöcke für Kubernetes-Pods.

6 Erstellen Sie IP-Pools für SNAT (Source Network Address Translation).

7 Installieren Sie das NSX CNI-Plugin (Containernetzwerkschnittstelle) auf jedem Knoten.

8 Installieren Sie OVS (Open vSwitch) auf jedem Knoten.

9 Konfigurieren Sie das NSX-T-Netzwerk für Kubernetes-Knoten.

10 Installieren Sie den NSX-Knotenagent als DaemonSet.

11 Installieren Sie NCP als ReplicationController.

12 Stellen Sie Sicherheitszertifikate im NCP-Pod bereit.


VMware, Inc. 8

Einrichten von NSX-T-Ressourcen 2Vor der Installation von NCP müssen Sie bestimmte NSX-T-Ressourcen einrichten.

Hinweis: Wenn Sie NSX-T installieren, können Sie mit der Standardlizenz keine Objekte erstellen oder aktualisieren, die Sie zur Unterstützung von NCP benötigen. Weitere Informationen finden Sie unter https://docs.vmware.com/de/VMware-NSX-T-Data-Center/3.0/administration/GUID-8E665EAC-A44D-4FB3-B661-E00C467B2ED5.html.

Die NSX Manager-Webschnittstelle bietet zwei Methoden zum Konfigurieren von Netzwerkressourcen: Richtlinienmodus und Manager-Modus. Weitere Informationen finden Sie unter https://docs.vmware.com/de/VMware-NSX-T-Data-Center/3.0/administration/GUID-BB26CDC8-2A90-4C7E-9331-643D13FEEC4A.html.

Sie müssen eine der beiden Methoden verwenden, um das NSX-T-Netzwerk für NCP zu konfigurieren, aber nicht beide. Sie müssen die Option policy_nsxapi in der NCP-YAML-Datei auf True festlegen, wenn Sie den Richtlinienmodus verwenden, bzw. False, wenn Sie den Managermodus verwenden.

In den folgenden Abschnitten wird davon ausgegangen, dass Sie mit der Installation und Verwaltung von NSX-T Data Center vertraut sind. Weitere Informationen finden Sie im Installationshandbuch für NSX-T Data Center und im NSX-T Data Center-Administratorhandbuch.


n Konfigurieren von NSX-T-Ressourcen im Richtlinienmodus

n Konfigurieren von NSX-T-Ressourcen im Managermodus

n Konfigurieren von SNAT

Konfigurieren von NSX-T-Ressourcen im Richtlinienmodus

Es gibt zwei Methoden zum Konfigurieren bestimmter Netzwerkressourcen für NCP. In diesem Abschnitt wird die Konfiguration von Ressourcen im Richtlinienmodus beschrieben.

VMware, Inc. 9

https://docs.vmware.com/de/VMware-NSX-T-Data-Center/3.0/administration/GUID-8E665EAC-A44D-4FB3-B661-E00C467B2ED5.html

https://docs.vmware.com/de/VMware-NSX-T-Data-Center/3.0/administration/GUID-8E665EAC-A44D-4FB3-B661-E00C467B2ED5.html

https://docs.vmware.com/de/VMware-NSX-T-Data-Center/3.0/administration/GUID-BB26CDC8-2A90-4C7E-9331-643D13FEEC4A.html

https://docs.vmware.com/de/VMware-NSX-T-Data-Center/3.0/administration/GUID-BB26CDC8-2A90-4C7E-9331-643D13FEEC4A.html

In der NCP-Konfigurationsdatei ncp.ini müssen Sie NSX-T-Ressourcen mit den jeweiligen Ressourcen-IDs angeben. In der Regel sind Name und ID einer Ressource identisch. Um wirklich sicherzugehen, klicken Sie auf der NSX Manager-Webschnittstelle auf das 3-Punkt-Symbol, das Optionen für eine Ressource anzeigt, und wählen Sie Pfad in die Zwischenablage kopieren aus. Fügen Sie den Pfad in einer Anwendung wie Notepad ein. Der letzte Teil des Pfads ist die Ressourcen-ID.

Gateways und Segment

1 Erstellen Sie ein Segment für die Kubernetes-Knoten, z. B. Segment1.

2 Erstellen Sie ein Tier-0-Gateway, z. B. T0GW1. Legen Sie die Option top_tier_router im Abschnitt [nsx_v3] der ncp.ini mit der ID des Gateways fest, wenn Sie über keine gemeinsam genutzte Tier-1-Topologie verfügen. Weitere Informationen zum Konfigurieren einer gemeinsam genutzten Tier-1-Topologie finden Sie unten. Legen Sie den HA-Modus auf „Aktiv-Standby“ fest, wenn Sie NAT-Regeln auf diesem Gateway konfigurieren möchten. Andernfalls legen Sie ihn auf „aktiv-aktiv“ fest. Aktivieren Sie Route Redistribution. Konfigurieren Sie dieses Gateway auch für den Zugriff auf das externe Netzwerk.

3 Erstellen Sie ein Tier-1-Gateway, z. B. T1GW1. Verbinden Sie dieses Gateway mit dem Tier-0-Gateway.

4 Konfigurieren Sie die Router-Ankündigung für T1GW1. Mindestens NSX-verbundene und NAT-Routen müssen aktiviert sein.

5 Verbinden Sie T1GW1 mit Segment1. Stellen Sie sicher, dass die IP-Adresse des Gateway-Ports nicht mit den IP-Adressen der Kubernetes-Knoten in Konflikt steht.

6 Stellen Sie für jede Knoten-VM sicher, dass die vNIC für den Container-Datenverkehr an den logischen Switch angehängt ist, der automatisch erstellt wird. Sie finden sie auf der Registerkarte Netzwerk mit demselben Namen wie das Segment, also Segment1.

NCP muss die VIF-ID der vNIC kennen. Sie können Segment1-Ports anzeigen, die automatisch erstellt werden, indem Sie „Netzwerk“ > „Segmente“ öffnen. Diese Ports können mit Ausnahme ihrer Tag-Eigenschaft nicht bearbeitet werden. Diese Ports müssen die folgenden Tags aufweisen: Geben Sie bei einem Tag den Namen des Knotens an. Für das andere Tag geben Sie den Namen des Clusters an. Geben Sie für den Geltungsbereich den entsprechenden Wert wie unten angegeben an.

Tag Geltungsbereich

Knotenname ncp/node_name

Clustername ncp/cluster

Diese Tags werden automatisch an die entsprechenden Ports des logischen Switches weitergegeben. Wenn der Knotenname geändert wird, müssen Sie das Tag aktualisieren. Um den Knotennamen abzurufen, können Sie den folgenden Befehl ausführen:

kubectl get nodes


VMware, Inc. 10

Wenn Sie den Kubernetes-Cluster erweitern möchten, während NCP läuft, z. B. um weitere Knoten zum Cluster hinzufügen, müssen Sie die Tags zu den entsprechenden Switch-Ports hinzufügen, bevor Sie „kubeadm join“ ausführen. Wenn Sie vergessen haben, die Tags vor dem Ausführen von „kubeadm join“ hinzuzufügen, haben die neuen Knoten keine Konnektivität. In diesem Fall müssen Sie die Tags hinzufügen und NCP neu starten, um das Problem zu beheben.

Um den Switch-Port für eine Knoten-VM zu identifizieren, können Sie den folgenden API-Aufruf durchführen:

/api/v1/fabric/virtual-machines

Suchen Sie in der Antwort nach der Knoten-VM und rufen Sie den Wert für das Attribut „external_id“ ab. Sie können auch den folgenden API-Aufruf durchführen:

/api/v1/search -G --data-urlencode "query=(resource_type:VirtualMachine AND

display_name:<node_vm_name>)"

Wenn Sie über die externe ID verfügen, können Sie sie verwenden, um die VIFs für die VM mit der folgenden API abzurufen. Beachten Sie, dass VIFs erst nach dem Start der VM ausgefüllt werden.

/api/v1/search -G --data-urlencode \

"query=(resource_type:VirtualNetworkInterface AND external_id:<node_vm_ext_id> AND \

_exists_:lport_attachment_id)"

Das Attribut lport_attachment_id ist die VIF-ID für die Knoten-VM. Sie können den logischen Port für diese VIF dann suchen und die erforderlichen Tags hinzufügen.

IP-Blöcke für Kubernetes-Pods

Navigieren Sie zu Netzwerk > IP-Adressverwaltung > IP-Adresspools > IP-Adressblöcke, um mindestens einen IP-Blöcke zu erstellen. Geben Sie den IP-Block im CIDR-Format an. Legen Sie die Option container_ip_blocks im Abschnitt [nsx_v3] der ncp.ini auf die UUIDs der IP-Blöcke fest. Wenn Sie möchten, dass NCP automatisch IP-Blöcke erstellt, können Sie die Option container_ip_blocks mit einer kommagetrennten Liste von Adressen im CIDR-Format festlegen. Beachten Sie, dass Sie container_ip_blocks nicht sowohl für UUIDs als auch für CIDR-Adressen festlegen können.

Standardmäßig verwenden Projekte die in container_ip_blocks angegebenen IP-Blöcke. Sie können IP-Blöcke speziell für Nicht-SNAT-Namespaces (für Kubernetes) oder Cluster (für PCF) erstellen, indem Sie die Option no_snat_ip_blocks im Abschnitt [nsx_v3] der ncp.ini festlegen.

Wenn Sie Nicht-SNAT-IP-Blöcke erstellen, während NCP ausgeführt wird, müssen Sie NCP neu starten. Andernfalls verwendet NCP weiterhin die freigegebenen IP-Blöcke, bis sie erschöpft sind.

Wenn Sie einen IP-Block erstellen, darf das Präfix nicht größer als der Wert der Option subnet_prefix in der NCP-Konfigurationsdatei ncp.ini sein. Die Standardeinstellung ist 24.


VMware, Inc. 11

Externe IP-Pools

Ein Pool an externen IPs wird für die Zuweisung von IP-Adressen, die für die Übersetzung von Pod-IPs unter Verwendung von SNAT-Regeln genutzt werden, und für die Freilegung von Ingress-Controllern sowie Diensten des Typs Lastausgleich unter Verwendung von SNAT/DNAT-Regeln genutzt, genau wie Openstack-Floating-IPs. Diese IP-Adressen werden auch als „externe IP-Adressen“ bezeichnet.

Navigieren Sie zu Netzwerk > IP-Adressverwaltung > IP-Adresspools, um einen IP-Pool zu erstellen. Legen Sie die Option external_ip_pools im Abschnitt [nsx_v3] der ncp.ini auf die UUIDs der IP-Pools fest. Wenn Sie möchten, dass NCP automatisch IP-Pools erstellt, können Sie die Option external_ip_pools mit einer kommagetrennten Liste von Adressen im CIDR-Format oder IP-Bereichen festlegen. Beachten Sie, dass Sie external_ip_pools nicht sowohl für UUIDs als auch für CIDR-Adressen festlegen können.

Mehrere Kubernetes-Cluster verwenden denselben externen IP-Pool. Jede NCP-Instanz verwendet einen Teil dieses Pools für den Kubernetes-Cluster, den sie verwaltet. Standardmäßig wird dasselbe Subnetzpräfix für Pod-Subnetze verwendet. Wen Sie eine andere Subnetzgröße verwenden möchten, aktualisieren Sie die external_subnet_prefix-Option im [nsx_v3]-Abschnitt in ncp.ini.

Sie können zu einem anderen IP-Pool wechseln, indem Sie die Konfigurationsdatei ändern und NCP neu starten.

Gemeinsam genutzte Tier-1-Topologie

Um eine gemeinsam genutzte Tier-1-Topologie zu aktivieren, nehmen Sie folgende Konfigurationen vor:

n Legen Sie die Option top_tier_router auf die ID eines Tier-1-Gateways fest. Verbinden Sie das Tier-1-Gateway mit einem Tier-0-Gateway für externe Verbindungen.

n Wenn SNAT für Pod-Datenverkehr aktiviert ist, ändern Sie den Uplink des Segments für Kubernetes-Knoten auf dasselbe Tier-0- oder Tier-1-Gateway, das unter top_tier_router festgelegt ist.

n Legen Sie die Option single_tier_topology auf True fest. Der Standardwert lautet False.

n Wenn NCP den Top-Tier-Router automatisch als Tier-1-Gateway konfigurieren soll, heben Sie die Option top_tier_router auf und legen Sie die Option tier0_gateway fest. NCP erstellt ein Tier-1-Gateway und einen Uplink zum Tier-0-Gateway, das in der Option tier0_gateway angegeben ist.

Konfigurieren von NSX-T-Ressourcen im Managermodus

Es gibt zwei Methoden zum Konfigurieren bestimmter Netzwerkressourcen für NCP. In diesem Abschnitt wird die Konfiguration von Ressourcen im Managermodus beschrieben.


VMware, Inc. 12

In der NCP-Konfigurationsdatei ncp.ini können Sie NSX-T-Ressourcen mit den jeweiligen UUIDs oder Namen angeben.

Logische Router und logische Switches

1 Erstellen Sie einen logischen Switch für die Kubernetes-Knoten, z. B. LS1.

2 Erstellen Sie einen logischen Tier-0-Router, z. B. T0LR1. Legen Sie die Option tier0_router im Abschnitt [nsx_v3] der ncp.ini mit der ID des logischen Routers fest, wenn Sie über keine gemeinsam genutzte Tier-1-Topologie verfügen. Weitere Informationen zum Konfigurieren einer gemeinsam genutzten Tier-1-Topologie finden Sie unten. Legen Sie den HA-Modus auf „Aktiv-Standby“ fest, wenn Sie NAT-Regeln auf diesem logischen Router konfigurieren möchten. Andernfalls legen Sie ihn auf „aktiv-aktiv“ fest. Aktivieren Sie Route Redistribution. Konfigurieren Sie diesen Router auch für den Zugriff auf das externe Netzwerk.

3 Erstellen Sie einen logischen Tier-1-Router, z. B. T1LR1. Verbinden Sie diesen logischen Router mit dem logischen Tier-0-Router.

4 Konfigurieren Sie die Router-Ankündigung für T1LR1. Mindestens NSX-verbundene und NAT-Routen müssen aktiviert sein.

5 Verbinden Sie T1LR1 mit LS1. Stellen Sie sicher, dass die Port-IP-Adresse des logischen Routers nicht mit den IP-Adressen der Kubernetes-Knoten in Konflikt steht.

6 Stellen Sie für jede Knoten-VM sicher, dass die vNIC für den Container-Datenverkehr an den logischen Switch angehängt ist, der automatisch erstellt wird. Sie finden sie auf der Registerkarte Netzwerk mit demselben Namen des logischen Switches, also LS1.

NCP muss die VIF-ID der vNIC kennen. Die entsprechenden Ports der logischen Switches müssen die folgenden zwei Tags aufweisen: Geben Sie bei einem Tag den Namen des Knotens an. Für das andere Tag geben Sie den Namen des Clusters an. Geben Sie für den Geltungsbereich den entsprechenden Wert wie unten angegeben an.

Tag Geltungsbereich



Wenn der Knotenname geändert wird, müssen Sie das Tag aktualisieren. Um den Knotennamen abzurufen, können Sie den folgenden Befehl ausführen:

kubectl get nodes

Wenn Sie den Kubernetes-Cluster erweitern möchten, während NCP läuft, z. B. um weitere Knoten zum Cluster hinzufügen, müssen Sie die Tags zu den entsprechenden Switch-Ports hinzufügen, bevor Sie „kubeadm join“ ausführen. Wenn Sie vergessen haben, die Tags vor dem Ausführen von „kubeadm join“ hinzuzufügen, haben die neuen Knoten keine Konnektivität. In diesem Fall müssen Sie die Tags hinzufügen und NCP neu starten, um das Problem zu beheben.


VMware, Inc. 13

Um den Switch-Port für eine Knoten-VM zu identifizieren, können Sie den folgenden API-Aufruf durchführen:

/api/v1/fabric/virtual-machines

Suchen Sie in der Antwort nach der Knoten-VM und rufen Sie den Wert für das Attribut „external_id“ ab. Sie können auch den folgenden API-Aufruf durchführen:

/api/v1/search -G --data-urlencode "query=(resource_type:VirtualMachine AND

display_name:<node_vm_name>)"

Wenn Sie über die externe ID verfügen, können Sie sie verwenden, um die VIFs für die VM mit der folgenden API abzurufen. Beachten Sie, dass VIFs erst nach dem Start der VM ausgefüllt werden.

/api/v1/search -G --data-urlencode \

"query=(resource_type:VirtualNetworkInterface AND external_id:<node_vm_ext_id> AND \

_exists_:lport_attachment_id)"

Das Attribut lport_attachment_id ist die VIF-ID für die Knoten-VM. Sie können den logischen Port für diese VIF dann suchen und die erforderlichen Tags hinzufügen.

IP-Blöcke für Kubernetes-Pods

Navigieren Sie zu Netzwerk > IP-Adresspools, um mindestens einen IP-Block zu erstellen. Geben Sie den IP-Block im CIDR-Format an. Legen Sie die Option container_ip_blocks im Abschnitt [nsx_v3] der ncp.ini auf die UUIDs der IP-Blöcke fest.

Standardmäßig verwenden Projekte die in container_ip_blocks angegebenen IP-Blöcke. Sie können IP-Blöcke speziell für Nicht-SNAT-Namespaces (für Kubernetes) oder Cluster (für PCF) erstellen, indem Sie die Option no_snat_ip_blocks im Abschnitt [nsx_v3] der ncp.ini festlegen.

Wenn Sie Nicht-SNAT-IP-Blöcke erstellen, während NCP ausgeführt wird, müssen Sie NCP neu starten. Andernfalls verwendet NCP weiterhin die freigegebenen IP-Blöcke, bis sie erschöpft sind.

Wenn Sie einen IP-Block erstellen, darf das Präfix nicht größer als der Wert der Option subnet_prefix in der NCP-Konfigurationsdatei ncp.ini sein. Die Standardeinstellung ist 24.

NCP weist zusätzliche Subnetze für einen Namespace zu, wenn das ursprünglich zugewiesene Subnetz ausgeschöpft ist.

Externe IP-Pools

Ein Pool an externen IPs wird für die Zuweisung von IP-Adressen, die für die Übersetzung von Pod-IPs unter Verwendung von SNAT-Regeln genutzt werden, und für die Freilegung von Ingress-Controllern sowie Diensten des Typs Lastausgleich unter Verwendung von SNAT/DNAT-Regeln genutzt, genau wie Openstack-Floating-IPs. Diese IP-Adressen werden auch als „externe IP-Adressen“ bezeichnet.


VMware, Inc. 14

Navigieren Sie zu Netzwerk > IP-Adresspools > IP-Pools, um einen IP-Pool zu erstellen. Legen Sie die Option external_ip_pools im Abschnitt [nsx_v3] der ncp.ini auf die UUIDs der IP-Pools fest.

Mehrere Kubernetes-Cluster verwenden denselben externen IP-Pool. Jede NCP-Instanz verwendet einen Teil dieses Pools für den Kubernetes-Cluster, den sie verwaltet. Standardmäßig wird dasselbe Subnetzpräfix für Pod-Subnetze verwendet. Wen Sie eine andere Subnetzgröße verwenden möchten, aktualisieren Sie die external_subnet_prefix-Option im [nsx_v3]-Abschnitt in ncp.ini.

Sie können zu einem anderen IP-Pool wechseln, indem Sie die Konfigurationsdatei ändern und NCP neu starten.

Gemeinsam genutzte Tier-1-Topologie

Um eine gemeinsam genutzte Tier-1-Topologie zu aktivieren, nehmen Sie folgende Konfigurationen vor:

n Legen Sie die Option top_tier_router auf die ID eines logischen Tier-0-Routers oder logischen Tier-1-Routers fest. Wenn es sich um einen logischen Tier-1-Router handelt, müssen Sie ihn für externe Verbindungen mit einem logischen Tier-0-Router verbinden. Diese Option ersetzt die Option tier0_router.

n Wenn SNAT für Pod-Datenverkehr aktiviert ist, trennen Sie T1LR1 von LS1 (der logische Switch für die Kubernetes-Knoten) und verbinden Sie den Tier-0 oder Tier-1 Router, der unter top_tier_router auf LS1 festgelegt ist.

n Legen Sie die Option single_tier_topology auf True fest. Der Standardwert lautet False.

(Optional, nur für Kubernetes) Firewall-Markierungsabschnitte

Damit der Administrator Firewallregeln erstellen kann und diese die von NCP erstellten, auf Netzwerkrichtlinien basierenden Firewallabschnitte nicht beeinträchtigen, öffnen Sie Sicherheit > Verteilte Firewall > Allgemein und erstellen Sie zwei Firewallabschnitte.

Geben Sie Firewall-Markierungsabschnitte an, indem Sie die Optionen bottom_firewall_section_marker und top_firewall_section_marker im Abschnitt [nsx_v3] der Datei ncp.ini festlegen.

Der untere Firewallabschnitt muss sich unterhalb des oberen Firewallabschnitts befinden. Wenn diese Firewallabschnitte erstellt sind, werden alle von NCP zur Isolierung erstellten Firewallabschnitte oberhalb des unteren Firewallabschnitts und alle von NCP für Richtlinien erstellten Firewallabschnitte unterhalb des oberen Firewallabschnitts erstellt. Wenn diese Markierungsabschnitte nicht erstellt werden, werden alle Isolierungsregeln unten und alle Richtlinienabschnitte oben erstellt. Mehrere markierte Firewallabschnitte mit demselben Wert pro Cluster werden nicht unterstützt und führen zu einem Fehler.

Konfigurieren von SNAT


VMware, Inc. 15

Einschränken eines SNAT-IP-Pools auf bestimmte Kubernetes-Namespaces oder PCF-Organisationen

Sie können durch Hinzufügen der folgenden Tags zum IP-Pool festlegen, welchem Kubernetes-Namespace oder welcher PCF Org IPs aus dem SNAT-IP-Pool zugeteilt werden können.

n Für einen Kubernetes-Namespace: scope: ncp/owner, tag: ns:<namespace_UUID>

n Für eine PCF Org: Geltungsbereich: scope: ncp/owner, tag: org:<org_UUID>

Sie können die Namespace- oder Org-UUID mit einem der folgenden Befehle abrufen:

kubectl get ns -o yaml

cf org <org_name> --guid

Beachten Sie Folgendes:

n Jedes Tag sollte eine UUID enthalten. Sie können mehrere Tags für denselben Pool erstellen.

n Wenn Sie die Tags ändern, nachdem einigen Namespaces oder Orgs IPs basierend auf den alten Tags zugewiesen wurden, werden diese IPs nicht wiederhergestellt, bis sich die SNAT-Konfigurationen der Kubernetes-Dienste oder PCF-Anwendungen ändern oder NCP neu gestartet wird.

n Die Owner-Tags für Namespace und PCF Org sind optional. Ohne diese Tags können jedem Namespace bzw. jeder PCF Org IPs aus dem SNAT-IP-Pool zugeteilt werden.

Konfigurieren eines SNAT-IP-Pools für einen Dienst

Sie können einen SNAT-IP-Pool für einen Dienst konfigurieren, indem Sie dem Dienst eine Anmerkung hinzufügen. Beispiel:

apiVersion: v1

kind: Service

metadata:

name: svc-example

annotations:

ncp/snat_pool: <external IP pool ID or name>

selector:

app: example

...

Der von ncp/snat_pool angegebene-IP-Pool muss über das Tag scope: ncp/owner, tag: cluster:<cluster_name> verfügen.

NCP konfiguriert die SNAT-Regel für diesen Dienst. Bei der Quell-IP der Regel handelt es sich um die Gruppe der Backend-Pods. Bei der Ziel-IP handelt es sich um die SNAT-IP, die aus dem angegebenen externen IP-Pool zugeteilt wurde. Falls bei der Konfiguration der SNAT-Regel durch NCP ein Fehler auftritt, wird der Dienst mit der Anmerkung ncp/error.snat:<error> versehen. Dies sind die möglichen Fehler:

n IP_POOL_NOT_FOUND: Der SNAT-IP-Pool wurde in NSX Manager nicht gefunden.


VMware, Inc. 16

n IP_POOL_EXHAUSTED: Der SNAT-IP-Pool ist ausgeschöpft.

n IP_POOL_NOT_UNIQUE: Der durch ncp/snat_pool angegebene Pool verweist auf mehrere Pools in NSX Manager.

n SNAT_POOL_ACCESS_DENY: Das Owner-Tag des Pools stimmt nicht mit dem Namespace des Diensts überein, der die Zuteilungsanforderung sendet.

n SNAT_RULE_OVERLAPPED: Eine neue SNAT-Regel wird erstellt, aber der Pod des SNAT-Diensts gehört auch zu einem anderen SNAT-Dienst, d. h., für denselben Pod sind mehrere SNAT-Regeln vorhanden.

n POOL_ACCESS_DENIED – Der von ncp/snat_pool angegebene IP-Pool weist das Tag scope: ncp/owner, tag: cluster:<cluster_name> nicht auf, oder das Owner-Tag des Pools stimmt nicht mit dem Namespace des Diensts überein, der die Zuteilungsanforderung sendet.


n Der von ncp/snat_pool angegebene Pool sollte bereits in NSX-T Data Center vorhanden sein, bevor der Dienst konfiguriert wird.

n In NSX-T Data Center ist die Priorität der SNAT-Regel für den Dienst höher als die für das Projekt.

n Wenn ein Pod mit mehreren SNAT-Regeln konfiguriert wird, funktioniert nur eine der Regeln.

n Sie können zu einem anderen IP-Pool wechseln, indem Sie die Anmerkung ändern und NCP neu starten.

Konfigurieren eines SNAT-IP-Pools für einen Namespace

Sie können einen SNAT-IP-Pool für einen Namespace konfigurieren, indem Sie dem Namespace eine Anmerkung hinzufügen. Beispiel:

apiVersion: v1

kind: Namespace

metadata:

name: ns-sample

annotations:

ncp/snat_pool: <external IP pool ID or name>

...

NCP konfiguriert die SNAT-Regel für diesen Namespace. Bei der Quell-IP der Regel handelt es sich um die Gruppe der Backend-Pods. Bei der Ziel-IP handelt es sich um die SNAT-IP, die aus dem angegebenen externen IP-Pool zugeteilt wurde. Falls bei der Konfiguration der SNAT-Regel durch NCP ein Fehler auftritt, wird der Namespace mit der Anmerkung ncp/error.snat:<error> versehen. Dies sind die möglichen Fehler:

n IP_POOL_NOT_FOUND: Der SNAT-IP-Pool wurde in NSX Manager nicht gefunden.



VMware, Inc. 17

n IP_POOL_NOT_UNIQUE: Der durch ncp/snat_pool angegebene Pool verweist auf mehrere Pools in NSX Manager.

n POOL_ACCESS_DENIED – Der von ncp/snat_pool angegebene IP-Pool weist das Tag scope: ncp/owner, tag: cluster:<cluster_name> nicht auf, oder das Owner-Tag des Pools stimmt nicht mit dem Namespace überein, der die Zuteilungsanforderung sendet.


n Sie können nur einen SNAT-IP-Pool in der Anmerkung angeben.

n Der SNAT-IP-Pool muss nicht in ncp.ini konfiguriert sein.

n Der von ncp/snat_pool angegebene-IP-Pool muss über das Tag scope: ncp/owner, tag: cluster:<cluster_name> verfügen.

n Der mit ncp/snat_pool angegebene IP-Pool kann auch ein Namespace-Tag, scope: ncp/owner, tag: ns:<namespace_UUID>, aufweisen.

n Wenn die Anmerkung ncp/snat_pool fehlt, verwendet der Namespace den SNAT-IP-Pool für den Cluster.

n Sie können zu einem anderen IP-Pool wechseln, indem Sie die Anmerkung ändern und NCP neu starten.

Konfigurieren einer SNAT-IP-Adresse für einen Dienst

Sie können eine SNAT-IP-Adresse für einen Dienst konfigurieren, indem Sie dem Dienst eine Anmerkung hinzufügen. Beispiel:

apiVersion: v1

kind: Service

metadata:

name: svc-example

annotations:

ncp/static_snat_ip: "1.2.3.4"

...

Wenn die Anmerkung ncp/snat_pool ebenfalls angegeben wird, muss sich die SNAT-IP-Adresse im angegebenen SNAT-Adresspool befinden. Andernfalls muss sie sich im externen IP-Pool befinden, der in der ncp.ini angegeben ist. Wenn es keine Fehler gibt, erstellt oder aktualisiert NCP die SNAT-Regel mithilfe der notierten SNAT-IP-Adresse für diesen Dienst. Der Status der Konfiguration der SNAT-Regel wird mit ncp/snat_ip_status im Dienst kommentiert. Mögliche Werte sind:

n IP_ALLOCATED_SUCCESSFULLY

n IP_ALREADY_ALLOCATED: IP-Adresse wurde bereits zugeteilt.

n IP_NOT_IN_POOL: IP-Adresse befindet sich nicht im SNAT-IP-Pool.


n SNAT_PROCESS_FAILED: Unbekannter Fehler ist aufgetreten.


VMware, Inc. 18

Konfigurieren einer SNAT-IP-Adresse für einen Namespace

Sie können eine SNAT-IP-Adresse für einen Namespace konfigurieren, indem Sie dem Namespace eine Anmerkung hinzufügen. Beispiel:

apiVersion: v1

kind: Namespace

metadata:

name: svc-example

annotations:

ncp/static_snat_ip: "1.2.3.4"

...

Wenn die Anmerkung ncp/snat_pool ebenfalls angegeben wird, muss sich die SNAT-IP-Adresse im angegebenen SNAT-Adresspool befinden. Andernfalls muss sie sich im externen IP-Pool befinden, der in der ncp.ini angegeben ist. Wenn es keine Fehler gibt, erstellt oder aktualisiert NCP die SNAT-Regel mithilfe der notierten SNAT-IP-Adresse für diesen Namespace. Der Status der Konfiguration der SNAT-Regel wird mit ncp/snat_ip_status im Namespace kommentiert. Mögliche Werte sind:

n IP_ALLOCATED_SUCCESSFULLY

n IP_ALREADY_ALLOCATED: IP-Adresse wurde bereits zugeteilt.

n IP_NOT_IN_POOL: IP-Adresse befindet sich nicht im SNAT-IP-Pool.

n IP_NOT_REALIZED: In NSX-T ist ein Fehler aufgetreten.


n SNAT_PROCESS_FAILED: Unbekannter Fehler ist aufgetreten.

Konfigurieren eines SNAT-Pools für eine PAS-App

Standardmäßig konfiguriert NCP die SNAT-IP für eine PAS-Organisation (Pivotal Application Service). Sie können eine SNAT-IP für eine App konfigurieren, indem Sie eine App mit einer manifest.xml erstellen, die die SNAT-IP-Pool-Informationen enthält. Beispiel:

applications:

- name: frontend

memory: 32M

disk_quota: 32M

buildpack: go_buildpack

env:

GOPACKAGENAME: example-apps/cats-and-dogs/frontend

NCP_SNAT_POOL: <external IP pool ID or name>

...


VMware, Inc. 19

NCP konfiguriert die SNAT-Regel für diese Anwendung. Die Quell-IP der Regel ist der Satz von IP-Adressen der Instanzen, und ihre Ziel-IP ist die SNAT-IP, die aus einem externen IP-Pool zugewiesen wurde. Beachten Sie Folgendes:

n Der von NCP_SNAT_POOL angegebene Pool sollte bereits in NSX-T Data Center vorhanden sein, bevor die Anwendung mithilfe von Push übertragen wird.

n Die SNAT-Regel für eine Anwendung hat eine höhere Priorität als diejenige für eine Organisation.

n Eine Anwendung kann nur mit einer SNAT-IP konfiguriert werden.

n Sie können zu einem anderen IP-Pool wechseln, indem Sie die Konfiguration ändern und NCP neu starten.

Konfigurieren von SNAT für PCF Version 3Mit PCF Version 3 können Sie SNAT auf zwei Arten konfigurieren:

n Konfigurieren Sie NCP_SNAT_POOL in manifest.yml, wenn Sie die App erstellen.

Die App trägt beispielsweise den Namen bread und die manifest.yml enthält die folgenden Informationen:

applications:

- name: bread

stack: cflinuxfs2

random-route: true

env:

NCP_SNAT_POOL: AppSnatExternalIppool

processes:

- type: web

disk_quota: 1024M

instances: 2

memory: 512M

health-check-type: port

- type: worker

disk_quota: 1024M

health-check-type: process

instances: 2

memory: 256M

timeout: 15

Führen Sie die folgenden Befehle aus:

cf v3-push bread

cf v3-apply-manifest -f manifest.yml

cf v3-apps

cf v3-restart bread

n Konfigurieren Sie NCP_SNAT_POOL mithilfe des Befehls cf v3-set-env.


VMware, Inc. 20

Führen Sie die folgenden Befehle aus (unter der Annahme, dass die App den Namen app3 trägt):

cf v3-set-env app3 NCP_SNAT_POOL AppSnatExternalIppool

(optional) cf v3-stage app3 -package-guid <package-guid> (You can get package-guid with "cf v3-

packages app3".)

cf v3-restart app3


VMware, Inc. 21

Installieren von NCP in einer Kubernetes-Umgebung 3Für die Installation von NSX Container Plug-in (NCP) müssen Komponenten auf den Master- und Worker-Knoten installiert werden. Die meisten Schritte sind automatisiert.


n Herunterladen der Protokolldateien

n Vorbereiten von Kubernetes-Knoten

n Erstellen von geheimen Schlüsseln – Kubernetes

n Konfigurieren von NSX-T Data Center-Netzwerken für Kubernetes-Knoten

n Bearbeiten der NCP-YAML-Datei

n Die nsx-ncp-config ConfigMap

n Die nsx-node-agent-config ConfigMap

n Anwenden der NCP-YAML-Datei

n Bereitstellen einer Zertifikatdatei im NCP-Pod

n Konfigurieren von IPv6

n Konfigurieren von Syslog

n Sicherheitsüberlegungen

n Konfigurieren von Netzwerkressourcen

n Kubernetes-Knoten bereinigen

Herunterladen der Protokolldateien

Zum Installieren von NCP laden Sie die NCP-YAML-Datei und das Docker-Image für Ihre Umgebung herunter.

Für einen Kubernetes-Cluster mit Ubuntu-Knoten laden Sie ncp-ubuntu.yaml und das nsx-ncp-ubuntu-Image herunter. Für einen Kubernetes-Cluster mit RHEL-Knoten laden Sie ncp-rhel.yaml und das nsx-ncp-rhel-Image herunter.

Führen Sie den folgenden Befehl aus, um das Docker-Image zu laden:

VMware, Inc. 22

docker load -i nsx-ncp-ubuntu-<version>.<build_no>.tar

oder

docker load -i nsx-ncp-rhel-<version>.<build_no>.tar

Führen Sie den folgenden Befehl aus, um den Namen des geladenen Images zu überprüfen:

docker images ls | grep ncp

Vorbereiten von Kubernetes-Knoten

Die meisten Schritte zur Vorbereitung der Kubernetes-Knoten werden durch zwei Container (nsx-ovs- und nsx-ncp-Bootstrap) automatisiert, die jeweils in den nsx-node-agent- und nsx-ncp-Bootstrap-DaemonSets ausgeführt werden.

Stellen Sie vor der Installation von NCP sicher, dass Python auf den Kubernetes-Knoten installiert und über die Befehlszeilenschnittstelle zugänglich ist. Sie können Ihren Linux-Paketmanager verwenden, um es zu installieren. Beispielsweise können Sie auf Ubuntu den Befehl apt install python ausführen.

Bei Ubuntu wird beim Installieren des NSX-T-CNI-Plug-Ins die AppArmor-Profildatei ncp-apparmor in /etc/apparmor.d kopiert und geladen. Vor der Installation muss der AppArmor-Dienst ausgeführt werden, und das Verzeichnis /etc/apparmor.d muss vorhanden sein. Andernfalls schlägt die Installation fehl. Sie können mit dem folgenden Befehl prüfen, ob das AppArmor-Modul aktiviert ist:

sudo cat /sys/module/apparmor/parameters/enabled

Sie können mit dem folgenden Befehl prüfen, ob der AppArmor-Dienst gestartet wurde:

sudo /etc/init.d/apparmor status

Die ncp-apparmor-Profildatei stellt ein AppArmor-Profil für den NSX-Knotenagent mit dem Namen node-agent-apparmor bereit, das sich vom docker-default-Profil wie folgt unterscheidet:

n Die deny mount-Regel wird entfernt.

n Die mount-Regel wird hinzugefügt.

n Einige network-, capability-, file- und umount-Optionen werden hinzugefügt.

Sie können das node-agent-apparmor-Profil durch ein anderes Profil ersetzen. In diesem Fall müssen Sie den Profilnamen node-agent-apparmor in der NCP-YAML-Datei ändern.

Der NSX-NCP-Bootstrap-Container automatisiert die Installation und das Update von NSX-CNI auf dem Host. In früheren Versionen wurde NSX-CNI über ein deb/rpm-Paket installiert. In der Version werden die Dateien einfach auf den Host kopiert. Der Bootstrap-Container entfernt die zuvor installierten NSX-CNI-Komponenten aus der Datenbank des Paketmanagers. Die folgenden Verzeichnisse und Dateien werden gelöscht:

n /etc/cni/net.d


VMware, Inc. 23

n /etc/apparmor.d/ncp-apparmor

n /opt/cni/bin/nsx

Der Bootstrap-Container überprüft die Datei 10-nsx.conf und sucht im Tag nsxBuildVersion nach der CNI-Versionsnummer. Wenn diese Version älter ist als die im Bootstrap-Container, werden die folgenden Dateien auf den Host kopiert:

n /opt/cni/bin/nsx

n /etc/cni/net.d/99-loopback.conf

n /etc/cni/net.d/10-nsx.conf

n /etc/apparmor.d/ncp-apparmor

Wenn die Dateien /opt/cni/bin/loopback und /etc/cni/net.d/99-loopback.conf vorhanden sind, werden Sie nicht überschrieben. Wenn es sich bei dem Betriebssystemtyp um Ubuntu handelt, wird die Datei ncp-apparmor ebenfalls auf den Host kopiert.

Der Bootstrap-Container verschiebt die IP-Adresse und die Routen von br-int auf node-if. Außerdem wird OVS gestoppt, wenn es auf dem Host ausgeführt wird, da OVS innerhalb des nsx-ovs-Containers läuft. Der nsx-ovs-Container erstellt die br-int-Instanz, wenn Sie nicht vorhanden ist, fügen Sie die Netzwerkschnittstelle (node-if) hinzu, die mit dem logischen Switch des Knotens auf br-int angefügt ist, und stellen Sie sicher, dass der Linkstatus br-int und node-if aktiviert ist. Außerdem werden IP-Adresse und Routen von node-if auf br-int verschoben.

Hinweis Wenn das NSX-Node-Agent-DaemonSet entfernt wird, wird OVS nicht mehr auf dem Host (im Container oder in der PID des Hosts) gestartet.

Aktualisieren Sie die Netzwerkkonfiguration, damit IP-Adresse und Routen persistent werden. Bearbeiten Sie z. B. für Ubuntu /etc/network/interfaces (verwenden Sie ggf. tatsächliche Werte aus Ihrer Umgebung), damit IP-Adresse und Routen persistent werden:

auto eth1

iface eth1 inet static

address 172.16.1.4/24

#persistent static routes

up route add -net 172.16.1.3/24 gw 172.16.1.1 dev eth1

Führen Sie dann den Befehl ifdown eth1; ifup eth1 aus.

Erstellen und bearbeiten Sie für RHEL /etc/sysconfig/network-scripts/ifcfg-<node-if> (verwenden Sie ggf. tatsächliche Werte aus Ihrer Umgebung), damit die IP-Adresse persistent wird:

HWADDR=00:0C:29:B7:DC:6F

TYPE=Ethernet

PROXY_METHOD=none

BROWSER_ONLY=no

BOOTPROTO=none

IPADDR=172.10.0.2

PREFIX=24


VMware, Inc. 24

DEFROUTE=yes

IPV4_FAILURE_FATAL=no

IPV4_DNS_PRIORITY=100

IPV6INIT=no

NAME=eth1

UUID=39317e23-909b-45fc-9951-849ece53cb83

DEVICE=eth1

ONBOOT=yes

Führen Sie dann den Befehl systemctl restart network.service aus.

Informationen zum Konfigurieren von persistenten Routen für RHEL finden Sie unter https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-configuring_static_routes_in_ifcfg_files.

Hinweis IP- und statische Routen müssen auf der Uplink-Schnittstelle beibehalten werden (angegeben durch ovs_uplink_port), um sicherzustellen, dass die Konnektivität mit dem Kubernetes-API-Server nach einem Neustart der VM nicht verloren geht.

Bei Bedarf können Sie die vom Bootstrap-Container vorgenommenen Änderungen rückgängig machen. Weitere Informationen finden Sie unter Kubernetes-Knoten bereinigen.

Erstellen von geheimen Schlüsseln – Kubernetes

Sie können geheime Schlüssel erstellen, um Zertifikat und Schlüssel des NSX-Clientzertifikats oder des Load Balancer zu speichern.

Der einfachste Weg für das Erstellen geheimer Schlüssel ist die Verwendung des kubectl-Befehls:

kubectl create ns nsx-system

kubectl create secret tls ${CERT_NAME} --key ${KEY_FILE} --cert ${CERT_FILE} -n nsx-system

Sie können auch mithilfe der NCP-YAML-Datei geheime Schlüssel erstellen, indem Sie die geheimen Beispielabschnitte in der Datei auskommentieren und die base64-kodierten Werte des Zertifikats und Schlüssels eingeben. Verwenden Sie die folgenden Befehle, um die base64-kodierte Zeichenfolge aus der Zertifikats- oder Schlüsseldatei abzurufen:

cat cert_file.crt | base64 -w 0

cat key_file.crt | base64 -w 0

Konfigurieren von NSX-T Data Center-Netzwerken für Kubernetes-Knoten

In diesem Abschnitt wird die Konfiguration von NSX-T Data Center-Netzwerken für Kubernetes Master- und Worker-Knoten beschrieben.


VMware, Inc. 25

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-configuring_static_routes_in_ifcfg_files



Jeder Knoten muss über mindestens zwei Netzwerkschnittstellen verfügen. Die erste ist eine Verwaltungsschnittstelle, die zur NSX-T Data Center-Fabric gehören kann oder nicht. Die anderen Schnittstellen stellen das Netzwerk für die Pods bereit, gehören zur NSX-T Data Center-Fabric und sind mit einem logischen Switch verbunden, der als logischer Switch-Knoten bezeichnet wird. Die IP-Adressen für Verwaltung und Pod müssen routingfähig sein, damit die Kubernetes-Systemdiagnose funktioniert. Für die Kommunikation zwischen der Verwaltungsschnittstelle und den Pods erstellt NCP automatisch eine DFW-Regel, damit die Systemdiagnose und anderweitiger Datenverkehr für die Verwaltung zulässig ist. Details zu dieser Regel finden Sie auf der NSX Manager-GUI. Diese Regel darf nicht geändert oder gelöscht werden.

Stellen Sie für jeden VM-Knoten sicher, dass die virtuelle Netzwerkkarte, die für das Containernetzwerk vorgesehen ist, mit dem logischen Knoten-Switch verbunden ist.

Die VIF-ID der für den Containerdatenverkehr in den einzelnen Knoten verwendeten virtuellen Netzwerkkarte muss NSX Container Plug-in (NCP) bekannt sein. Die entsprechenden Ports der logischen Switches müssen die folgenden Tags aufweisen: Geben Sie bei einem Tag den Namen des Knotens an. Für das andere Tag geben Sie den Namen des Clusters an. Geben Sie für den Geltungsbereich den entsprechenden Wert wie unten angegeben an.

Tag Geltungsbereich



Sie können den logischen Switch-Port für eine virtuelle Maschine eines Knotens bestimmen, indem Sie auf der NSX Manager-GUI zu Bestand > Virtuelle Maschinen navigieren.

Wenn der Kubernetes-Knotenname geändert wird, müssen Sie das Tag ncp/node_name aktualisieren und NCP neu starten. Mithilfe des folgenden Befehls können Sie die Knotennamen abrufen:

kubectl get nodes

Wenn Sie einem Cluster einen Knoten hinzufügen, während NCP ausgeführt wird, müssen Sie die Tags dem logischen Switch-Port hinzufügen, bevor Sie den kubeadm join-Befehl ausführen. Andernfalls wird der neue Knoten nicht über Netzwerkkonnektivität verfügen. Wenn die Tags falsch oder nicht vorhanden sind, können Sie die folgenden Schritte ausführen, um das Problem zu beheben:

n Wenden Sie auf dem logischen Switch-Port die richtigen Tags an.

n Starten Sie NCP neu.

Bearbeiten der NCP-YAML-Datei

Die NCP-YAML-Datei enthält Informationen zum Konfigurieren, Installieren und Ausführen aller NCP-Komponenten.


VMware, Inc. 26

Die NCP-YAML-Datei enthält die folgenden Informationen:

n RBAC-Definitionen.

n Verschiedene CRDs (CustomResourceDefinitions).

n ConfigMap mit ncp.ini, die für NCP dediziert ist. Einige empfohlene Konfigurationsoptionen sind bereits festgelegt.

n NCP-Bereitstellung.

n ConfigMap mit ncp.ini, die für nsx-node-agent dediziert ist. Einige empfohlene Konfigurationsoptionen sind bereits festgelegt.

n nsx-node-agent-DaemonSet, einschließlich nsx-node-agent, nsx-kube-proxy und nsx-ovs.

n nsx-ncp-bootstrap-DaemonSet

Die NSX-CNI- und OpenvSwitch-Kernel-Module werden automatisch von nsx-ncp-bootstrap-initContainers installiert. Die OpenvSwitch-Userspace-Daemons werden auf jedem Knoten im nsx-ovs-Container gestartet.

Aktualisieren der NCP-Bereitstellungsspezifikationen

Suchen Sie die ConfigMap mit dem Namen nsx-ncp-config. Eine vollständige Liste der ConfigMap-Optionen finden Sie unter Die nsx-ncp-config ConfigMap. Einige Optionen sind bereits mit empfohlenen Werten konfiguriert. Sie können alle Optionen für Ihre Umgebung anpassen. Beispiel:

n Protokollebene und -verzeichnis.

n Kubernetes-API-Server-IP, Zertifikatspfad und Client-Token-Pfad. Standardmäßig wird die API-Server-ClusterIP aus der Umgebungsvariablen verwendet, und Zertifikat sowie Token werden automatisch von ServiceAccount gemountet. In der Regel ist keine Änderung erforderlich.

n Kubernetes-Clustername.

n NSX Manager-IP und Anmeldedaten.

n NSX-Ressourcenoptionen wie overlay_tz, top_tier_router, container_ip_blocks, external_ip_blocks usw.

Standardmäßig werden Kubernetes-Dienst-VIP/-Port und ServiceAccount-Token sowie ca_file für den Kubernetes-API-Zugriff verwendet. Hier ist keine Änderung erforderlich, Sie müssen jedoch einige NSX API-Optionen der ncp.ini eingeben.

n Spezifizieren Sie die Option nsx_api_managers. Es kann sich um eine kommagetrennte Liste mit NSX Manager-IP-Adressen oder URL-Spezifikationen handeln, die mit RFC3896 kompatibel sind. Beispiel:

nsx_api_managers = 192.168.1.181, 192.168.1.182, 192.168.1.183


VMware, Inc. 27

n Geben Sie die Optionen nsx_api_user und nsx_api_password jeweils mit dem Benutzernamen und dem Kennwort an, wenn Sie NCP für die Verbindung mit NSX-T mithilfe der Standardauthentifizierung konfigurieren. Diese Authentifizierungsmethode wird nicht empfohlen, da Sie weniger sicher ist. Diese Optionen werden ignoriert, wenn NCP für die Authentifizierung mithilfe von Clientzertifikaten konfiguriert ist. Diese Optionen werden in der NCP-YAML-Datei nicht angezeigt. Sie müssen Sie manuell hinzufügen.

n Geben Sie die Optionen nsx_api_cert_file und nsx_api_private_key_file für die Authentifizierung mit NSX-T an. Die Option nsx_api_cert_file ist der vollständige Pfad zu einer Clientzertifikatdatei im PEM-Format. Der Inhalt dieser Datei sollte wie folgt aussehen:

-----BEGIN CERTIFICATE-----

<certificate_data_base64_encoded>

-----END CERTIFICATE-----

Die Option nsx_api_private_key_file ist der vollständige Pfad zu einer privaten Clientschlüsseldatei im PEM-Format. Der Inhalt dieser Datei sollte wie folgt aussehen:

-----BEGIN PRIVATE KEY-----

<private_key_data_base64_encoded>

-----END PRIVATE KEY-----

Mithilfe der Clientzertifikatauthentifizierung kann NCP ihre Prinzipalidentität zum Erstellen von NSX-T-Objekten verwenden. Dies bedeutet, dass nur eine Identität mit demselben Identitätsnamen die Objekte ändern oder löschen kann. Dadurch wird verhindert, dass NSX-T-Objekte, die von NCP erstellt wurden, versehentlich geändert oder gelöscht werden. Beachten Sie, dass ein Administrator beliebige Objekte ändern oder löschen kann. Wenn das Objekt mit einer Prinzipalidentität erstellt wurde, wird dies in Form einer Warnung angegeben.

n (Optional) Spezifizieren Sie die Option ca_file. Der Wert sollte einer CA-Paketdatei entsprechen, die beim Überprüfen des NSX Manager-Serverzertifikats verwendet wird. Wenn Sie keine Festlegung treffen, werden die System-Root-CAs verwendet. Wenn Sie eine IP-Adresse für nsx_api_managers angeben, geben Sie eine Zertifizierungsstellendatei an. Wenn Sie drei IP-Adressen für nsx_api_managers angeben, können Sie eine oder drei Zertifizierungsstellendatei(en) angeben. Wenn Sie eine Zertifizierungsstellendatei angeben, wird sie für alle drei Manager verwendet. Wenn Sie drei Zertifizierungsstellendateien angeben, wird jede davon für die entsprechende IP-Adresse in nsx_api_managers verwendet. Beispiel:

nsx_api_managers = 192.168.1.181,192.168.1.182,192.168.1.183

ca_file = ca_file_for_all_mgrs

or

nsx_api_managers = 192.168.1.181,192.168.1.182,192.168.1.183

ca_file = ca_file_for_mgr1,ca_file_for_mgr2,ca_file_for_mgr3

n (Optional) Spezifizieren Sie die Option insecure. Wenn diese Option auf True festgelegt ist, wird das NSX Manager-Serverzertifikat nicht verifiziert. Die Standardeinstellung lautet False.


VMware, Inc. 28

Wenn Sie einen geheimen Kubernetes-Schlüssel zum Speichern des NSX Clientzertifikats und des standardmäßigen Load Balancer-Zertifikats verwenden möchten, müssen Sie zuerst mithilfe eines kubectl-Befehls geheime Schlüssel erstellen und dann die Bereitstellungsspezifikation aktualisieren:

n Fügen Sie der NCP-Pod-Spezifikation geheime Volumes hinzu oder kommentieren Sie geheime Beispiel-Volumes aus.

n Fügen Sie der NCP-Container-Spezifikation Datenträger-Mounts hinzu oder kommentieren Sie die Beispiel-Volume-Mounts aus.

n Aktualisieren Sie die ncp.ini in der ConfigMap, um den Pfad der Zertifikatsdatei festzulegen, der auf die Datei im gemounteten Volume verweist.

Wenn Sie nicht über eine gemeinsam genutzte Tier-1-Topologie verfügen, müssen Sie die Option edge_cluster auf die Edge-Cluster-ID festlegen, damit NCP ein Tier-1-Gateway oder -Router für den Lastausgleichdienst erstellt. Sie können die Edge-Cluster-ID finden, indem Sie System > Fabric > Knoten öffnen, die Registerkarte Edge-Cluster auswählen und auf den Namen des Edge-Clusters klicken.

HA (Hochverfügbarkeit) ist automatisch aktiviert. In einer Produktionsumgebung wird empfohlen, HA nicht zu deaktivieren.

Hinweis: Standardmäßig werden die Pods von kube-scheduler nicht auf dem Master-Knoten geplant. In der NCP-YAML-Datei wird eine Toleranz hinzugefügt, damit NCP-Pod auf dem Master-Knoten ausgeführt werden kann.

Konfigurieren von SNAT

Standardmäßig konfiguriert NCP SNAT für jedes Projekt. SNAT wird für Namespaces mit der folgenden Anmerkung nicht konfiguriert:

ncp/no_snat: True

Wenn Sie SNAT für keinen Namespace im Cluster verwenden möchten, konfigurieren Sie die folgende Option in der ncp.ini:

[coe]

enable_snat = False

Hinweis: Das Aktualisieren einer vorhandenen Namespace-SNAT-Anmerkung wird nicht unterstützt. Wenn Sie eine solche Aktion durchführen, wird die Topologie für den Namespace in einem inkonsistenten Zustand angezeigt, da möglicherweise eine veraltete SNAT-Regel verbleibt. Um einen solchen inkonsistenten Zustand wiederherzustellen, müssen Sie den Namespace neu erstellen.


VMware, Inc. 29

(Nur Richtlinienmodus) Wenn SNAT für einen Cluster konfiguriert ist, ist BGP auf dem Tier-0-Router aktiviert, und Connected Interfaces & Segments ist unter Advertised tier-1 subnets ausgewählt. Wenn Sie die Route Redistribution für den Tier-0-Router konfigurieren, können Sie die folgende Option verwenden, um die Route Redistribution zu steuern:

[nsx_v3]

configure_t0_redistribution = True

Wenn configure_t0_redistribution auf True festgelegt ist, fügt NCP in der Neuverteilungsregel den Route-Map-Eintrag deny hinzu, um zu verhindern, dass der Tier-0-Router die internen Subnetze des Clusters an BGP-Nachbarn weitergibt. Dies wird hauptsächlich für Cluster vom Typ „vSphere with Kubernetes“ verwendet. Wenn Sie keine Route Map für die Neuverteilungsregel erstellen, erstellt NCP eine Route Map unter Verwendung seiner Prinzipalidentität und wendet sie in der Regel an. Wenn Sie diese Route Map bearbeiten möchten, müssen Sie sie durch eine neue Route Map ersetzen, die Einträge aus der von NCP erstellten Route Map kopieren und neue Einträge hinzufügen. Sie müssen alle potenziellen Konflikte zwischen den neuen Einträgen und den von NCP erstellten Einträgen verwalten. Wenn Sie die von NCP erstellte Route Map einfach aufheben, ohne eine neue Route Map für die Neuverteilungsregel zu erstellen, wendet NCP die zuvor erstellte Route Map erneut auf die Neuverteilungsregel an, sobald NCP neu startet.

Aktualisieren der nsx-node-agent-DaemonSet-Spezifikationen

Suchen Sie die ConfigMap mit dem Namen nsx-node-agent-config. Eine vollständige Liste der ConfigMap-Optionen finden Sie unter Die nsx-node-agent-config ConfigMap. Einige Optionen sind bereits mit empfohlenen Werten konfiguriert. Sie können alle Optionen für Ihre Umgebung anpassen. Beispiel:

n Protokollebene und -verzeichnis.

n Kubernetes-API-Server-IP, Zertifikatspfad und Client-Token-Pfad. Standardmäßig wird die API-Server-ClusterIP aus der Umgebungsvariablen verwendet, und Zertifikat sowie Token werden automatisch von ServiceAccount gemountet. In der Regel ist keine Änderung erforderlich.

n OpenvSwitch-Uplink-Port. Beispielsweise: ovs_uplink_port=eth1

Das nsx-ncp-bootstrap-DaemonSet installiert CNI- und OVS-Kernel-Module auf dem Knoten. Anschließend werden OVS-Daemons auf dem Knoten heruntergefahren, sodass der nsx-ovs-Container später OVS-Daemons in einem Docker-Container ausführen kann. Wenn CNI nicht installiert ist, befinden sich alle Kubernetes-Knoten im Status „Nicht bereit“. Das Bootstrap-DaemonSet weist eine Toleranz auf, damit es auf Knoten mit dem Status „Nicht bereit“ ausgeführt werden kann. Nachdem das CNI-Plug-In installiert wurde, sollten die Knoten „Bereit“ sein.


VMware, Inc. 30

Wenn Sie nicht das NSX OVS-Kernelmodul verwenden, müssen Sie den Volume-Parameter host-original-ovs-db mit dem richtigen Pfad aktualisieren, in dem die OpenvSwitch-Datenbank während der Zusammenstellung des OVS-Kernelmoduls konfiguriert ist. Wenn Sie beispielsweise --sysconfdir=/var/lib angeben, legen Sie host-original-ovs-db auf /var/lib/openvswitch fest.

Wenn Sie das NSX OVS-Kernelmodul verwenden, müssen Sie use_nsx_ovs_kernel_module = True festlegen und die Kommentare der Zeilen über die bereitzustellenden Volumes entfernen:

# Uncomment these mounts if installing NSX-OVS kernel module

# # mount host lib modules to install OVS kernel module if needed

# - name: host-modules

# mountPath: /lib/modules

# # mount openvswitch database

# - name: host-config-openvswitch

# mountPath: /etc/openvswitch

# - name: dir-tmp-usr-ovs-kmod-backup

# # we move the usr kmod files to this dir temporarily before

# # installing new OVS kmod and/or backing up existing OVS kmod backup

# mountPath: /tmp/nsx_usr_ovs_kmod_backup

# # mount linux headers for compiling OVS kmod

# - name: host-usr-src

# mountPath: /usr/src

...

# Uncomment these volumes if installing NSX-OVS kernel module

# - name: host-modules

# hostPath:

# path: /lib/modules

# - name: host-config-openvswitch

# hostPath:

# path: /etc/openvswitch

# - name: dir-tmp-usr-ovs-kmod-backup

# hostPath:

# path: /tmp/nsx_usr_ovs_kmod_backup

# - name: host-usr-src

# hostPath:

# path: /usr/src

Der NSX-Knotenagent ist ein DaemonSet, wobei von jedem Pod 3 Container ausgeführt werden.

n nsx-node-agent verwaltet Container-Netzwerkschnittstellen. Er interagiert mit dem CNI-Plugin und dem Kubernetes-API-Server.

n nsx-kube-proxy implementiert die Kubernetes-Dienstabstraktion, indem Cluster-IPs in Pod-IPs übersetzt werden. Dadurch wird die gleiche Funktionalität wie der Upstream-kube-proxy implementiert, dieser ist jedoch nicht gegenseitig exklusiv.


VMware, Inc. 31

n nsx-ovs führt die OpenvSwitch-Userspace-Daemons aus. Darüber hinaus wird die OVS-Bridge automatisch erstellt und IP-Adresse sowie Routen werden von node-if auf br-int zurückverschoben. Sie müssen ovs_uplink_port=ethX in der ncp.ini hinzufügen, damit sie ethX als OVS Bridge-Uplink verwenden kann.

Wenn die Worker-Knoten Ubuntu verwenden, geht ncp-ubuntu.yaml davon aus, dass das AppArmor-Kernel-Modul aktiviert ist, andernfalls lehnt Kubelet die Ausführung des nsx-node-agent-DaemonSets ab, da es mit der Option AppArmor konfiguriert ist. Für Ubuntu und SUSE ist es standardmäßig aktiviert. Um zu überprüfen, ob das Modul aktiviert ist, überprüfen Sie die Datei /sys/module/apparmor/parameters/enabled.

Wenn AppArmor absichtlich deaktiviert ist, müssen die folgenden Änderungen auf die YAML-Datei angewendet werden:

n Entfernen Sie die Option AppArmor :

annotations:

# The following line needs to be removed

container.apparmor.security.beta.kubernetes.io/nsx-node-agent: localhost/node-agent-apparmor

n Aktivieren des privilegierten Modus sowohl für die nsx-node-agent- als auch die nsx-kube-proxy-Container

securityContext:

# The following line needs to be appended

privileged: true

Hinweis: Wenn Kubelet innerhalb eines Containers ausgeführt wird, der das Hyperkube-Image verwendet, meldet Kubelet AppArmor unabhängig vom Ist-Zustand immer als deaktiviert. Dieselben Änderungen wie oben müssen vorgenommen und auf die YAML-Datei angewendet werden.

Aktualisieren des Namespace-Namens

In der YAML-Datei werden alle Namespace-Objekte, z. B. ServiceAccount, ConfigMap und Deployment, unter dem nsx-system-Namespace erstellt. Wenn Sie einen anderen Namespace verwenden, ersetzen Sie alle Instanzen von nsx-system.

Die nsx-ncp-config ConfigMap

Die NCP-YAML-Datei enthält die nsx-ncp-config ConfigMap. Sie können die Optionen für Ihre Umgebung aktualisieren. Im Folgenden finden Sie die nsx-ncp-config-ConfigMap von ncp-ubuntu-policy.yaml für NCP 3.0.2.

# ConfigMap for ncp.ini

apiVersion: v1

kind: ConfigMap

metadata:

name: nsx-ncp-config

namespace: nsx-system


VMware, Inc. 32

labels:

version: v1

data:

ncp.ini: |

[vc]

# IpAddress or Hostname of VC

#vc_endpoint = <None>

# The SSO domain associated with the deployment

#sso_domain = vsphere.local

# VC API server HTTPS port.

#https_port = 443

[coe]

# Container orchestrator adaptor to plug in.

#adaptor = kubernetes

# Specify cluster for adaptor.

#cluster = k8scluster

# Log level for NCP operations

# Choices: NOTSET DEBUG INFO WARNING ERROR CRITICAL

#loglevel = <None>

# Log level for NSX API client operations


#nsxlib_loglevel = <None>

# Enable SNAT for all projects in this cluster. Modification of topologies

# for existing Namespaces is not supported if this option is reset.

#enable_snat = True

# Option to enable profiling

#profiling = False

# The interval of reporting performance metrics (0 means disabled)

#metrics_interval = 0

# Name of log file for outputting metrics only (if not defined, use default

# logging facility)

#metrics_log_file = <None>

# The type of container host node

# Choices: HOSTVM BAREMETAL CLOUD WCP_WORKER

#node_type = HOSTVM

# The time in seconds for NCP/nsx_node_agent to recover the connection to

# NSX manager/container orchestrator adaptor/Hyperbus before exiting. If

# the value is 0, NCP/nsx_node_agent won't exit automatically when the

# connection check fails

#connect_retry_timeout = 0


VMware, Inc. 33

# Enable system health status report for SHA

#enable_sha = True

[DEFAULT]

# If set to true, the logging level will be set to DEBUG instead of the

# default INFO level.

#debug = False

# If set to true, log output to standard error.

#use_stderr = True

# If set to true, use syslog for logging.

#use_syslog = False

# The base directory used for relative log_file paths.

#log_dir = <None>

# Name of log file to send logging output to.

#log_file = <None>

# max MB for each compressed file. Defaults to 100 MB.

#log_rotation_file_max_mb = 100

# Total number of compressed backup files to store. Defaults to 5.

#log_rotation_backup_count = 5

[nsx_v3]

# Set NSX API adaptor to NSX Policy API adaptor. If unset, NSX adaptor will

# be set to the NSX Manager based adaptor. If unset or False, the NSX

# resource ID in other options can be resource name or UUID

#policy_nsxapi = False

# Path to NSX client certificate file. If specified, the nsx_api_user and

# nsx_api_password options will be ignored. Must be specified along with

# nsx_api_private_key_file option

#nsx_api_cert_file = <None>

# Path to NSX client private key file. If specified, the nsx_api_user and

# nsx_api_password options will be ignored. Must be specified along with

# nsx_api_cert_file option

#nsx_api_private_key_file = <None>

# IP address of one or more NSX managers separated by commas. The IP

# address should be of the form:

# [<scheme>://]<ip_adress>[:<port>]

# If scheme is not provided https is used. If port is not provided port 80

# is used for http and port 443 for https.

#nsx_api_managers = []

# If True, skip fatal errors when no endpoint in the NSX management cluster


VMware, Inc. 34

# is available to serve a request, and retry the request instead

#cluster_unavailable_retry = False

# Maximum number of times to retry API requests upon stale revision errors.

#retries = 10

# Specify one or a list of CA bundle files to use in verifying the NSX

# Manager server certificate. This option is ignored if "insecure" is set

# to True. If "insecure" is set to False and "ca_file" is unset, the

# "thumbprint" will be used. If "thumbprint" is unset, the system root CAs

# will be used to verify the server certificate.

#ca_file = []

# Specify one or a list of thumbprint strings to use in verifying the NSX

# Manager server certificate. This option is ignored if "insecure" is set

# to True or "ca_file" is defined.

#thumbprint = []

# If true, the NSX Manager server certificate is not verified. If false the

# CA bundle specified via "ca_file" will be used or if unset the

# "thumbprint" will be used. If "thumbprint" is unset, the default system

# root CAs will be used.

#insecure = False

# The time in seconds before terminating a HTTP connection to a NSX manager.

#http_timeout = 10

# The time in seconds before terminating a HTTP read response from a NSX

# manager.

#http_read_timeout = 180

# Maximum number of times to retry a HTTP connection.

#http_retries = 3

# Maximum concurrent connections to all NSX managers. If multiple NSX

# managers are configured, connections will be spread evenly across all

# managers, rounded down to the nearest integer. Each NSX manager will have

# at least 1 connection. This value should be a multiple of

# [nsx_v3]nsx_api_managers length.

#concurrent_connections = 10

# The amount of time in seconds to wait before ensuring connectivity to the

# NSX manager if no manager connection has been used.

#conn_idle_timeout = 10

# Number of times a HTTP redirect should be followed.

#redirects = 2

# Subnet prefix of IP block.

#subnet_prefix = 24

# Subnet prefix for v6 IP blocks

#v6_subnet_prefix = 64

# Indicates whether distributed firewall DENY rules are logged.


VMware, Inc. 35

#log_dropped_traffic = False

# Indicates whether distributed firewall rules are logged. Option 'ALL'

# will enable logging for all DFW rules (both DENY and ALLOW), and option

# 'DENY' will enable logging only for DENY rules. Remove this config if no

# logging is desired

# Choices: ALL DENY <None>

#log_firewall_traffic = <None>

# Option to use native load balancer or not

#use_native_loadbalancer = True

# Option to auto scale layer 4 load balancer or not. If set to True, NCP

# will create additional LB when necessary upon K8s Service of type LB

# creation/update.

#l4_lb_auto_scaling = True

# Option to use native load balancer or not when ingress class annotation

# is missing. Only effective if use_native_loadbalancer is set to true

#default_ingress_class_nsx = True

# Path to the default certificate file for HTTPS load balancing. Must be

# specified along with lb_priv_key_path option

#lb_default_cert_path = <None>

# Path to the private key file for default certificate for HTTPS load

# balancing. Must be specified along with lb_default_cert_path option

#lb_priv_key_path = <None>

# Option to set load balancing algorithm in load balancer pool object.

# Choices: ROUND_ROBIN LEAST_CONNECTION IP_HASH WEIGHTED_ROUND_ROBIN

#pool_algorithm = ROUND_ROBIN

# Option to set load balancer service size. MEDIUM Edge VM (4 vCPU, 8GB)

# only supports SMALL LB. LARGE Edge VM (8 vCPU, 16GB) only supports MEDIUM

# and SMALL LB. Bare Metal Edge (IvyBridge, 2 socket, 128GB) supports

# LARGE, MEDIUM and SMALL LB

# Choices: SMALL MEDIUM LARGE

#service_size = SMALL

# Option to set load balancer persistence option. If cookie is selected,

# cookie persistence will be offered.If source_ip is selected, source IP

# persistence will be offered for ingress traffic through L7 load balancer

# Choices: <None> cookie source_ip

#l7_persistence = <None>

# An integer for LoadBalancer side timeout value in seconds on layer 7

# persistence profile, if the profile exists.

#l7_persistence_timeout = 10800

# Option to set load balancer persistence option. If source_ip is selected,

# source IP persistence will be offered for ingress traffic through L4 load

# balancer

# Choices: <None> source_ip

#l4_persistence = <None>


VMware, Inc. 36

# Option to set distributed load balancer source ip persistence option,

# only available when use_native_dlb = True

# Choices: <None> source_ip

#dlb_l4_persistence = <None>

# Resource ID of the container ip blocks that will be used for creating

# subnets. If name, it must be unique. If policy_nsxapi is enabled, it also

# support automatically creating the IP blocks. The definition is a comma

# separated list: CIDR,CIDR,... Mixing different formats (e.g. UUID,CIDR)

# is not supported.

#container_ip_blocks = []

# Resource ID of the container ip blocks that will be used for creating

# subnets for no-SNAT projects. If specified, no-SNAT projects will use

# these ip blocks ONLY. Otherwise they will use container_ip_blocks

#no_snat_ip_blocks = []

# Resource ID of the external ip pools that will be used for allocating IP

# addresses which will be used for translating container IPs via SNAT

# rules. If policy_nsxapi is enabled, it also support automatically

# creating the ip pools. The definition is a comma separated list:

# CIDR,IP_1-IP_2,... Mixing different formats (e.g. UUID, CIDR&IP_Range) is

# not supported.

#external_ip_pools = []

# Resource ID of the top-tier router for the container cluster network,

# which could be either tier0 or tier1. If policy_nsxapi is enabled, should

# be ID of a tier0/tier1 gateway.

#top_tier_router = <None>

# Option to use single-tier router for the container cluster network

#single_tier_topology = False

# Resource ID of the external ip pools that will be used only for

# allocating IP addresses for Ingress controller and LB service. If

# policy_nsxapi is enabled, it also supports automatically creating the ip

# pools. The definition is a comma separated list: CIDR,IP_1-IP_2,...

# Mixing different formats (e.g. UUID, CIDR&IP_Range) is not supported.

#external_ip_pools_lb = []

# Resource ID of the NSX overlay transport zone that will be used for

# creating logical switches for container networking. It must refer to an

# already existing resource on NSX and every transport node where VMs

# hosting containers are deployed must be enabled on this transport zone

#overlay_tz = <None>

# Name of the enforcement point used to look up overlay transport zones and

# edge cluster paths, e.g. vmc-enforcementpoint, default, etc.

#enforcement_point = <None>

# Resource ID of the lb service that can be attached by virtual servers

#lb_service = <None>

# Resource ID of the IPSet containing the IPs of all the virtual servers


VMware, Inc. 37

#lb_vs_ip_set = <None>

# Enable X_forward_for for ingress. Available values are INSERT or REPLACE.

# When this config is set, if x_forwarded_for is missing, LB will add

# x_forwarded_for in the request header with value client ip. When

# x_forwarded_for is present and its set to REPLACE, LB will replace

# x_forwarded_for in the header to client_ip. When x_forwarded_for is

# present and its set to INSERT, LB will append client_ip to

# x_forwarded_for in the header. If not wanting to use x_forwarded_for,

# remove this config

# Choices: <None> INSERT REPLACE

#x_forwarded_for = <None>

# Resource ID of the firewall section that will be used to create firewall

# sections below this mark section

#top_firewall_section_marker = <None>

# Resource ID of the firewall section that will be used to create firewall

# sections above this mark section

#bottom_firewall_section_marker = <None>

# Replication mode of container logical switch, set SOURCE for cloud as it

# only supports head replication mode

# Choices: MTEP SOURCE

#ls_replication_mode = MTEP

# The resource which NCP will search tag 'node_name' on, to get parent VIF

# or transport node uuid for container LSP API context field. For HOSTVM

# mode, it will search tag on LSP. For BM mode, it will search tag on LSP

# then search TN. For CLOUD mode, it will search tag on VM. For WCP_WORKER

# mode, it will search TN by hostname.

# Choices: tag_on_lsp tag_on_tn tag_on_vm hostname_on_tn

#search_node_tag_on = tag_on_lsp

# Determines which kind of information to be used as VIF app_id. Defaults

# to pod_resource_key. In WCP mode, pod_uid is used.

# Choices: pod_resource_key pod_uid

#vif_app_id_type = pod_resource_key

# If this value is not empty, NCP will append it to nameserver list

#dns_servers = []

# Set this to True to enable NCP to report errors through NSXError CRD.

#enable_nsx_err_crd = False

# Maximum number of virtual servers allowed to create in cluster for

# LoadBalancer type of services.

#max_allowed_virtual_servers = 9223372036854775807

# Edge cluster ID needed when creating Tier1 router for loadbalancer

# service. Information could be retrieved from Tier0 router

#edge_cluster = <None>


VMware, Inc. 38

# Inventory feature switch

#enable_inventory = True

# For internal container network CIDR, NCP adds redistribution deny rule to

# stop T0 router advertise subnets to external network outside of T0

# router. If BGP or route redistribution is disabled, or

# T1_CONNECTED/TIER1_SEGMENT option is not selected, NCP would not add the

# deny rule. If users enable BGP and route redistribution, or select

# T1_CONNECTED/TIER1_SEGMENT option after NCP starts, user needs to restart

# NCP to let NCP set deny rule. If there is already a route map attached,

# NCP will create IP prefix list on the existing route map. Otherwise NCP

# will create a new route map and attach it. This option could be used only

# in SNAT mode and when policy_nsxapi = True.

#configure_t0_redistribution = False

# Health check interval for nsx lb monitor profile

#lb_hc_profile_interval = 5

# Health check timeout for nsx lb monitor profile

#lb_hc_profile_timeout = 15

# Health check failed count for nsx lb monitor profile. Pool member failed

# for this amount will be marked as down.

#lb_hc_profile_fall_count = 3

# Health check rise count for nsx lb monitor profile. Pool members

# previously marked down will be brought up, if succeed in the health check

# for this amount fo time.

#lb_hc_profile_rise_count = 3

# Maximum size of the buffer used to store HTTP request headers for L7

# virtual servers in cluster. A request with header larger than this value

# will be processed as best effort whereas a request with header below this

# value is guaranteed to be processed.

#lb_http_request_header_size = 1024

# Maximum size of the buffer used to store HTTP response headers for all L7

# virtual servers in cluster. A response with header larger than this value

# will be dropped.

#lb_http_response_header_size = 4096

# Maximum server idle time in seconds for L7 virtual servers in cluster. If

# backend server does not send any packet within this time, the connection

# is closed.

#lb_http_response_timeout = 60

# Determines the behavior when a Tier-1 instance restarts after a failure.

# If set to PREEMPTIVE, the preferred node will take over, even if it

# causes another failure. If set to NON_PREEMPTIVE, then the instance that

# restarted will remain secondary. Applicable to Tier-1 across cluster that

# was created by NCP and has edge cluster configured.

# Choices: PREEMPTIVE NON_PREEMPTIVE

#failover_mode = NON_PREEMPTIVE


VMware, Inc. 39

# Set this to ENABLE to enable NCP enforced pool member limit for all load

# balancer servers in cluster. Set this to CRD_LB_ONLY will only enforce

# the limit for load balancer servers created using lb CRD. Set this to

# DISABLE to turn off all limit checks. This option requires

# relax_scale_validation set to True, l4_lb_auto_scaling set to False, and

# works on Policy API only. When not disabled, NCP will enforce a pool

# member limit on LBS to prevent one LBS from using up all resources on

# edge nodes.

# Choices: DISABLE ENABLE CRD_LB_ONLY

#ncp_enforced_pool_member_limit = DISABLE

# Maximum number of pool member allowed for each small load balancer

# service. Requires ncp_enforced_pool_member_limit set to ENABLE or

# CRD_LB_ONLY to take effect.

#members_per_small_lbs = 2000

# Maximum number of pool member allowed for each medium load balancer

# service. Requires ncp_enforced_pool_member_limit set to ENABLE or

# CRD_LB_ONLY to take effect.

#members_per_medium_lbs = 2000

# Interval in seconds to clean empty segments.

#segment_gc_interval = 600

# Determines the mode NCP limits rate when sending API calls to NSX.

# Choices: NO_LIMIT SLIDING_WINDOW ADAPTIVE_AIMD

#api_rate_limit_mode = ADAPTIVE_AIMD

# When nsx_v3.api_rate_limit_mode is not set to NO_LIMIT, determines the

# maximum number of API calls sent per manager ip per second. Should be a

# positive integer.

#max_api_rate = 40

# Resource ID of the client SSL profile which will be used by Loadbalancer

# while participating in TLS handshake with the client

#client_ssl_profile = <None>

[ha]

# Time duration in seconds of mastership timeout. NCP instance will remain

# master for this duration after elected. Note that the heartbeat period

# plus the update timeout must not be greater than this period. This is

# done to ensure that the master instance will either confirm liveness or

# fail before the timeout.

#master_timeout = 18

# Time in seconds between heartbeats for elected leader. Once an NCP

# instance is elected master, it will periodically confirm liveness based

# on this value.

#heartbeat_period = 6

# Timeout duration in seconds for update to election resource. The default

# value is calculated by subtracting heartbeat period from master timeout.

# If the update request does not complete before the timeout it will be

# terminated. Used for master heartbeats to ensure that the update finishes or


VMware, Inc. 40

# is terminated before the master timeout occurs.

#update_timeout = <None>

[k8s]

# Kubernetes API server IP address.

#apiserver_host_ip = <None>

# Kubernetes API server port.

#apiserver_host_port = <None>

# Full path of the Token file to use for authenticating with the k8s API

# server.

client_token_file = /var/run/secrets/kubernetes.io/serviceaccount/token

# Full path of the client certificate file to use for authenticating with

# the k8s API server. It must be specified together with

# "client_private_key_file".

#client_cert_file = <None>

# Full path of the client private key file to use for authenticating with


# "client_cert_file".

#client_private_key_file = <None>

# Specify a CA bundle file to use in verifying the k8s API server

# certificate.

ca_file = /var/run/secrets/kubernetes.io/serviceaccount/ca.crt

# Specify whether ingress controllers are expected to be deployed in

# hostnework mode or as regular pods externally accessed via NAT

# Choices: hostnetwork nat

#ingress_mode = hostnetwork

# Log level for the kubernetes adaptor


#loglevel = <None>

# The default HTTP ingress port

#http_ingress_port = 80

# The default HTTPS ingress port

#https_ingress_port = 443

# Specify thread pool size to process resource events

#resource_watcher_thread_pool_size = 1

# User specified IP address for HTTP and HTTPS ingresses

#http_and_https_ingress_ip = <None>

# Set this to True to enable NCP to create tier1 router, first segment and

# default SNAT IP for VirtualNetwork CRD, and then create segment port for

# VM through VirtualNetworkInterface CRD.

#enable_vnet_crd = False


VMware, Inc. 41

# Set this to True to enable NCP to create LoadBalancer on a Tier-1 for

# LoadBalancer CRD. This option does not support LB autoscaling.

#enable_lb_crd = False

# Option to set the type of baseline cluster policy. ALLOW_CLUSTER creates

# an explicit baseline policy to allow any pod to communicate any other pod

# within the cluster. ALLOW_NAMESPACE creates an explicit baseline policy

# to allow pods within the same namespace to communicate with each other.

# By default, no baseline rule will be created and the cluster will assume

# the default behavior as specified by the backend. Modification is not

# supported after the value is set.

# Choices: <None> allow_cluster allow_namespace

#baseline_policy_type = <None>

# Maximum number of endpoints allowed to create for a service.

#max_allowed_endpoints = 1000

# Set this to True to enable NCP reporting NSX backend error to k8s object

# using k8s event

#enable_ncp_event = False

# Set this to True to enable multus to create multiple interfaces for one

# pod. If passthrough interface is usedas additional interface, user should

# deploy device plugin to provide device allocation information for NCP.Pod

# annotations under prefix "k8s.v1.cni.cncf.io" cannot be modified after

# pod realized. User defined IP will not be allocated from Segment IPPool.

# "gateway" in NetworkAttachmentDefinition is not used to configure

# secondary interfaces. Default gateway of pod is configured by primary

# interface. User must define IP and/or MAC if no "ipam" is configured.Only

# available if node type is HOSTVM

#enable_multus = True

# Interval of polling loadbalancer statistics. Default to60 seconds.

#lb_statistic_monitor_interval = 60

# This option is for toggling process of network CRD.It should be set to

# False when the network status setting is done by OCP4 NetworkOperator

#process_oc_network = True

#[nsx_v3]

# Deprecated option: tier0_router

# Replaced by [nsx_v3] top_tier_router

# Deprecated option: deny_subnets_redistribution

# Replaced by [nsx_v3] configure_t0_redistribution


VMware, Inc. 42

Die nsx-node-agent-config ConfigMap

Die NCP-YAML-Datei enthält die nsx-node-agent-config ConfigMap. Sie können die Optionen für Ihre Umgebung aktualisieren. Im Folgenden finden Sie die nsx-node-agent-config-ConfigMap von ncp-ubuntu-policy.yaml für NCP 3.0.2.

kind: ConfigMap

metadata:

name: nsx-node-agent-config

namespace: nsx-system

labels:

version: v1

data:

ncp.ini: |

[DEFAULT]

# If set to true, the logging level will be set to DEBUG instead of the

# default INFO level.

#debug = False

# If set to true, log output to standard error.

#use_stderr = True

# If set to true, use syslog for logging.

#use_syslog = False

# The base directory used for relative log_file paths.

#log_dir = <None>

# Name of log file to send logging output to.

#log_file = <None>

# max MB for each compressed file. Defaults to 100 MB.

#log_rotation_file_max_mb = 100

# Total number of compressed backup files to store. Defaults to 5.

#log_rotation_backup_count = 5

[k8s]

# Kubernetes API server IP address.

#apiserver_host_ip = <None>

# Kubernetes API server port.

#apiserver_host_port = <None>

# Full path of the Token file to use for authenticating with the k8s API

# server.


# Full path of the client certificate file to use for authenticating with


# "client_private_key_file".

#client_cert_file = <None>


VMware, Inc. 43

# Full path of the client private key file to use for authenticating with


# "client_cert_file".

#client_private_key_file = <None>

# Specify a CA bundle file to use in verifying the k8s API server

# certificate.


# Specify whether ingress controllers are expected to be deployed in

# hostnework mode or as regular pods externally accessed via NAT

# Choices: hostnetwork nat

#ingress_mode = hostnetwork

# Log level for the kubernetes adaptor


#loglevel = <None>

# The default HTTP ingress port

#http_ingress_port = 80

# The default HTTPS ingress port

#https_ingress_port = 443

# Specify thread pool size to process resource events

#resource_watcher_thread_pool_size = 1

# User specified IP address for HTTP and HTTPS ingresses

#http_and_https_ingress_ip = <None>

# Set this to True to enable NCP to create tier1 router, first segment and

# default SNAT IP for VirtualNetwork CRD, and then create segment port for

# VM through VirtualNetworkInterface CRD.

#enable_vnet_crd = False

# Set this to True to enable NCP to create LoadBalancer on a Tier-1 for

# LoadBalancer CRD. This option does not support LB autoscaling.

#enable_lb_crd = False

# Option to set the type of baseline cluster policy. ALLOW_CLUSTER creates

# an explicit baseline policy to allow any pod to communicate any other pod

# within the cluster. ALLOW_NAMESPACE creates an explicit baseline policy

# to allow pods within the same namespace to communicate with each other.

# By default, no baseline rule will be created and the cluster will assume

# the default behavior as specified by the backend. Modification is not

# supported after the value is set.

# Choices: <None> allow_cluster allow_namespace

#baseline_policy_type = <None>

# Maximum number of endpoints allowed to create for a service.

#max_allowed_endpoints = 1000

# Set this to True to enable NCP reporting NSX backend error to k8s object

# using k8s event


VMware, Inc. 44

#enable_ncp_event = False

# Set this to True to enable multus to create multiple interfaces for one

# pod. If passthrough interface is usedas additional interface, user should

# deploy device plugin to provide device allocation information for NCP.Pod

# annotations under prefix "k8s.v1.cni.cncf.io" cannot be modified after

# pod realized. User defined IP will not be allocated from Segment IPPool.

# "gateway" in NetworkAttachmentDefinition is not used to configure

# secondary interfaces. Default gateway of pod is configured by primary

# interface. User must define IP and/or MAC if no "ipam" is configured.Only

# available if node type is HOSTVM

#enable_multus = True

# Interval of polling loadbalancer statistics. Default to60 seconds.

#lb_statistic_monitor_interval = 60

# This option is for toggling process of network CRD.It should be set to

# False when the network status setting is done by OCP4 NetworkOperator

#process_oc_network = True

[coe]

# Container orchestrator adaptor to plug in.

#adaptor = kubernetes

# Specify cluster for adaptor.

#cluster = k8scluster

# Log level for NCP operations


#loglevel = <None>

# Log level for NSX API client operations


#nsxlib_loglevel = <None>

# Enable SNAT for all projects in this cluster. Modification of topologies

# for existing Namespaces is not supported if this option is reset.

#enable_snat = True

# Option to enable profiling

#profiling = False

# The interval of reporting performance metrics (0 means disabled)

#metrics_interval = 0

# Name of log file for outputting metrics only (if not defined, use default

# logging facility)

#metrics_log_file = <None>

# The type of container host node

# Choices: HOSTVM BAREMETAL CLOUD WCP_WORKER

#node_type = HOSTVM

# The time in seconds for NCP/nsx_node_agent to recover the connection to


VMware, Inc. 45

# NSX manager/container orchestrator adaptor/Hyperbus before exiting. If

# the value is 0, NCP/nsx_node_agent won't exit automatically when the

# connection check fails

#connect_retry_timeout = 0

# Enable system health status report for SHA

#enable_sha = True

[nsx_kube_proxy]

# The way to process service configuration, set into OVS flow or write to

# nestdb,

# Choices: ovs nestdb

#config_handler = ovs

[nsx_node_agent]

# Prefix of node /proc and /var/run/netns path to mount on nsx_node_agent

# DaemonSet

#proc_mount_path_prefix = /host

# The log level of NSX RPC library


#nsxrpc_loglevel = ERROR

# OVS bridge name

#ovs_bridge = br-int

# The time in seconds for nsx_node_agent to wait CIF config from HyperBus

# before returning to CNI

#config_retry_timeout = 300

# The time in seconds for nsx_node_agent to backoff before re-using an

# existing cached CIF to serve CNI request. Must be less than

# config_retry_timeout.

#config_reuse_backoff_time = 15

# The OVS uplink OpenFlow port where to apply the NAT rules to.

#ovs_uplink_port = <None>

# Set this to True if you want to install and use the NSX-OVS kernel

# module. If the host OS is supported, it will be installed by nsx-ncp-

# bootstrap and used by nsx-ovs container in nsx-node-agent pod. Note that

# you would have to add (uncomment) the volumes and mounts in the nsx-ncp-

# bootstrap DS and add SYS_MODULE capability in nsx-ovs container spec in

# nsx-node-agent DS. Failing to do so will result in failure of

# installation and/or kernel upgrade of NSX-OVS kernelmodule.

#use_nsx_ovs_kernel_module = False

# The time in seconds for nsx_node_agent to call OVS command. Please

# increase the time if OVS is in heavy load to create/delete ports

#ovs_operation_timeout = 5

# Set to true to allow the CNI plugin to enable IPv6 container interfaces

#enable_ipv6 = False


VMware, Inc. 46

# Set to True if DHCP is configured on the "ovs_uplink_port". "auto" will

# try to automatically infer it but it only works on CoreOS. On other

# types host OS, it defaults to False

# Choices: True False auto

#is_dhcp_configured_on_ovs_uplink_port = auto

Anwenden der NCP-YAML-Datei

Nachdem Sie die NCP-YAML-Datei bearbeitet haben, können Sie die YAML-Datei anwenden, um die Ressourcen zu erstellen und auszuführen.

Führen Sie den folgenden Befehl aus, um die NCP-YAML-Datei anzuwenden. Beispiel:

kubectl apply -f ncp-ubuntu.yaml

Führen Sie den folgenden Befehl zum Prüfen des Ergebnisses aus. Beispiel:

~# kubectl get pods -n nsx-system

nsx-ncp-5df7fdf8b9-b6lmx 1/1 Running 0 77s

nsx-ncp-bootstrap-rv6z2 1/1 Running 0 76s

nsx-ncp-bootstrap-tzbv2 1/1 Running 0 76s

nsx-ncp-bootstrap-z4tt5 1/1 Running 0 76s

nsx-node-agent-ghnjk 3/3 Running 0 76s

nsx-node-agent-jkrct 3/3 Running 0 76s

nsx-node-agent-tz6td 3/3 Running 0 76s

Sie können auch den Befehl kubectl get all -n nsx-system ausführen, um weitere Details anzuzeigen.

Bereitstellen einer Zertifikatdatei im NCP-Pod

Sie müssen eine Zertifikatsdatei im NCP-Pod bereitstellen, um die zertifikatbasierte Authentifizierung mit der NSX-T-API zu konfigurieren, oder um ein Standardzertifikat für die SSL-Auslagerung für den NSX-T Load Balancer zu konfigurieren.

In beiden Fällen gehen Sie wie folgt vor:

n Erstellen Sie einen Schlüssel mit einem Zertifikat und einem privaten Schlüssel.

n Hängen Sie ein geheimes Volume an den NCP-Pod an und mounten Sie das Volume (siehe ConfigMap-Beispiel unten).

Geben Sie für die zertifikatbasierte Authentifizierung mit der NSX-T-API die Optionen nsx_api_cert_file und nsx_api_private_key_file unter [nsx_v3] in nsx-ncp-config ConfigMap mit dem Mount-Pfad für das Zertifikat und den Schlüssel an.

Geben Sie für die SSL-Verschiebung des NSX-T Load Balancer die Optionen lb_default_cert_path und lb_priv_key_path unter [nsx_v3] im NSX-NCP-config-ConfigMap mit dem Mount-Pfad für das Zertifikat und den Schlüssel an.


VMware, Inc. 47

https://opengrok.eng.vmware.com/source/s?path=ncp-ubuntu.yaml&project=nsx-ujo.git

ConfigMap-Abschnitt, in dem Sie die Pfade zum Zertifikat und den Schlüssel angeben:

volumes:

- name: projected-volume

projected:

sources:

# ConfigMap nsx-ncp-config is expected to supply ncp.ini

- configMap:

name: nsx-ncp-config

items:

- key: ncp.ini

path: ncp.ini

# To use cert based auth, uncomment and update the secretName,

# then update ncp.ini with the mounted cert and key file paths

#- secret:

# name: nsx-secret

# items:

# - key: tls.crt

# path: nsx-cert/tls.crt

# - key: tls.key

# path: nsx-cert/tls.key

#- secret:

# name: lb-secret

# items:

# - key: tls.crt

# path: lb-cert/tls.crt

# - key: tls.key

# path: lb-cert/tls.key

# To use JWT based auth, uncomment and update the secretName.

#- secret:

# name: wcp-cluster-credentials

# items:

# - key: username

# path: vc/username

# - key: password

# path: vc/password

Konfigurieren von IPv6

Sie können NCP so konfigurieren, dass IPv6 unterstützt wird.

Beachten Sie bei der Konfiguration von IPv6 Folgendes:

n Nur der Richtlinienmodus wird unterstützt. Weitere Informationen finden Sie unter Kapitel 2 Einrichten von NSX-T-Ressourcen.

n Topologien mit einer und zwei Ebenen werden unterstützt.

n Damit der Nord-Süd-Datenverkehr ordnungsgemäß funktioniert, muss das Tier-0-Gateway über eine IPv6-Adresse verfügen.


VMware, Inc. 48

n Kubernetes-Knoten müssen über eine IPv6-Adresse verfügen. Andernfalls besteht keine Konnektivität zwischen den Knoten und Pods, und Aktivitäts- und Bereitschaftsprüfungen von TCP und HTTP schlagen fehl. Für Kubernetes-Knoten können entweder SLAAC- oder statische IPs verwendet werden. Die Kubernetes-Knoten können sich auch im Dual-Stack-Modus befinden. In diesem Fall müssen Sie den Knoten mit einer IPv6-Adresse in Kubernetes registrieren. Geben Sie dazu die IPv6-Adresse mit der Option -node-ip als einen der Startparameter von Kubelet an. Andernfalls priorisiert Kubelet stets die IPv4-Adresse.

n Der Kubernetes-Cluster muss mit einem IPv6-Dienstcluster-Netzwerk-CIDR erstellt werden. Beachten Sie, dass die maximale Größe für dieses Subnetz 16 Bit beträgt.

n In der NCP-Konfiguration müssen Sie SpoofGuard deaktivieren, indem Sie enable_spoofguard = False im Abschnitt [nsx_v3] festlegen.

n In der nsx-node-agent-Konfiguration muss IPv6 aktiviert sein, um das CNI-Plug-in anzuweisen, IPv6 in Containern zu aktivieren. Legen Sie dazu enable_ipv6 = True im Abschnitt [nsx-node-agent] fest. Stellen Sie sicher, dass Sie diese Konfigurationsoption festlegen, bevor der Bootstrap-Vorgang für NCP ausgeführt wird.

n Alle Namespaces befinden sich im Nicht-SNAT-Modus. SNAT pro Dienst und jede andere SNAT-Funktion sind in IPv6 nicht aktiviert.

n Für Container wird Dual-Stack nicht unterstützt. Jeder Container darf nur über eine IPv6-Adresse verfügen.

n Wenn IPv4- und IPv6-IP-Blöcke in der NCP-Konfiguration gemischt werden, schlägt der Startvorgang fehl.

Konfigurieren von Syslog

Sie können einen Syslog-Agenten, wie z. B. Rsyslog oder Syslog-ng in einem Container ausführen, um Protokolle aus NCP und den zugehörigen Komponenten an einen Syslog-Server zu senden.

Die Protokollierung kann mit folgenden Methoden konfiguriert werden. Weitere Informationen zur Protokollierung in Kubernetes finden Sie unter https://kubernetes.io/docs/concepts/cluster-administration/logging.

n Erstellen Sie einen Sidecar-Container, der im NCP- oder die NSX-Knoten-Agent-Pod ausgeführt wird.

n Führen Sie auf jedem Knoten ein DaemonSet-Replikat aus.

Hinweis Mit der Sidecar-Containermethode können NSX CNI-Plug-In-Protokolle nicht an den Syslog-Server gesendet werden, da das Plugin nicht in einem Pod ausgeführt wird.


VMware, Inc. 49

https://kubernetes.io/docs/concepts/cluster-administration/logging

https://kubernetes.io/docs/concepts/cluster-administration/logging

Erstellen eines Sidcar-Containers für Syslog

Sie können einen Sidecar-Container für Syslog für die Ausführung in demselben Pod wie NCP konfigurieren. Bei dem folgenden Verfahren wird davon ausgegangen, dass das Syslog-Agent-Image „example/rsyslog“ ist.

Verfahren

1 Konfigurieren Sie NCP und den NSX-Knoten-Agent für die Protokollierung in einer Datei.

Legen Sie in der yaml-Datei für NCP und den NSX-Knoten-Agent den Parameter „log_dir“ fest, und geben Sie bereitzustellende Volume an. Beispiel:

[DEFAULT]

log_dir = /var/log/nsx-ujo/

...

spec:

...

containers:

- name: nsx-ncp

...

volumeMounts:

- name: nsx-ujo-log-dir

# Mount path must match [DEFAULT] option "log_dir"

mountPath: /var/log/nsx-ujo

volumes:

...


hostPath:

path: /var/log/nsx-ujo

Sie können den Namen der Protokolldatei ändern, indem Sie den log_file-Parameter festlegen. Die Standardnamen sind ncp.log nsx_node_agent.log und nsx_kube_proxy.log. Wenn die log_dir -Option auf einen anderen Pfad als /var/log/nsx-ujo festgelegt ist, muss entweder ein hostPath- oder emptyDir-Volume erstellt und für die entsprechende Pod-Spezifikation bereitgestellt werden.

2 Stellen Sie sicher, dass der Host-Pfad existiert und vom Benutzer nsx-ncp beschreibbar ist.

a Führen Sie die folgenden Befehle aus.

mkdir -p <host-filesystem-log-dir-path>

chmod +w <host-filesystem-log-dir-path>

b Fügen Sie den Benutzer nsx-ncp hinzu oder ändern Sie den Modus des Hostpfads auf 777.

useradd -s /bin/bash nsx-ncp

chown nsx-ncp:nsx-ncp <host-filesystem-log-dir-path>

or

chmod 777 <host-filesystem-log-dir-path>


VMware, Inc. 50

3 Fügen Sie in der yaml-Spezifikationsdatei des NCP-Pods ein ConfigMap-Objekt für Syslog hinzu. Beispiel:

kind: ConfigMap

metadata:

name: rsyslog-config

labels:

version: v1

data:

ncp.conf: |

module(load="imfile")

ruleset(name="remote") {

action(type="omfwd"

Protocol="tcp"

Target="nsx.example.com"

Port="514")

stop

}

input(type="imfile"

File="/var/log/nsx-ujo/ncp.log"

Tag="ncp"

Ruleset="remote"

4 Fügen Sie in der yaml-Datei des NCP Pods den rsyslog-Container hinzu, und stellen Sie die entsprechenden Volumes bereit, auf denen Rsyslog Konfigurationsdaten finden und Protokolle von anderen Containern lesen kann. Beispiel:

spec:

containers:

- name: nsx-ncp

...

- name: rsyslog

image: example/rsyslog

imagePullPolicy: IfNotPresent

volumeMounts:

- name: rsyslog-config-volume

mountPath: /etc/rsyslog.d

readOnly: true



volumes:

...


configMap:



hostPath:

path: <host-filesystem-log-dir-path>


VMware, Inc. 51

Erstellen eines DaemonSet-Replikats für Syslog

Mithilfe dieser Methode können die Protokolle aller NCP-Komponenten umgeleitet werden. Die Anwendungen müssen für die Protokollierung in stderr konfiguriert werden. Dies ist standardmäßig aktiviert. Bei dem folgenden Verfahren wird davon ausgegangen, dass das Syslog-Agent-Image „example/rsyslog“ ist.

Verfahren

1 Erstellen Sie die yaml-Datei für DaemonSet. Beispiel:

apiVersion: v1

kind: ConfigMap

metadata:


labels:

version: v1

data:

nsx-ncp.conf: |



if $msg contains 'nsx-container' then

action(type="omfwd"

Protocol="tcp"

Target="nsx.example.com"

Port="514")

stop

}

input(type="imfile"

File="/var/log/containers/nsx-node-agent-*.log"

Tag="nsx-node-agent"

Ruleset="remote")

input(type="imfile"

File="/var/log/containers/nsx-ncp-*.log"

Tag="nsx-ncp"

Ruleset="remote")

input(type="imfile"

File="/var/log/syslog"

Tag="nsx-cni"

Ruleset="remote")

---

# rsyslog DaemonSet

apiVersion: extensions/v1beta1

kind: DaemonSet

metadata:

name: rsyslog

labels:

component: rsyslog

version: v1


VMware, Inc. 52

spec:

template:

metadata:

labels:

component: rsyslog

version: v1

spec:

hostNetwork: true

containers:

- name: rsyslog

image: example/rsyslog


volumeMounts:



- name: log-volume

mountPath: /var/log

- name: container-volume

mountPath: /var/lib/docker/containers

volumes:


configMap:


- name: log-volume

hostPath:

path: /var/log

- name: container-volume

hostPath:

path: /var/lib/docker/containers

2 Erstellen Sie das DaemonSet-Objekt.

kubectl apply -f <daemonset yaml file>

Beispiel: Konfigurieren der Protokollrotation und des in einem Sidecar-Container ausgeführten Syslogs

Im folgenden Verfahren wird die Konfiguration der Protokollrotation und des in einem Sidecar-Container ausgeführten Syslogs gezeigt.

Erstellen des Protokollverzeichnisses und Konfigurieren der Protokollrotation

n Erstellen Sie das Protokollverzeichnis auf allen Knoten, einschließlich des Masterknotens, und ändern Sie seinen Besitzer in den Benutzer mit der ID 1000.

mkdir /var/log/nsx-ujo

chown localadmin:localadmin /var/log/nsx-ujo

n Konfigurieren Sie die Protokollrotation auf allen Knoten für das Verzeichnis /var/log/nsx-ujo.

cat <<EOF > /etc/logrotate.d/nsx-ujo

/var/log/nsx-ujo/*.log {


VMware, Inc. 53

copytruncate

daily

size 100M

rotate 4

delaycompress

compress

notifempty

missingok

}

EOF

Erstellen des NCP ReplicationController

n Erstellen Sie die Datei ncp.ini für NCP.

cat <<EOF > /tmp/ncp.ini

[DEFAULT]

log_dir = /var/log/nsx-ujo

[coe]

cluster = k8s-cl1

[k8s]

apiserver_host_ip = 10.114.209.77

apiserver_host_port = 6443



insecure = True

ingress_mode = nat

[nsx_v3]

nsx_api_user = admin

nsx_api_password = Password1!

nsx_api_managers = 10.114.209.68

insecure = True

subnet_prefix = 29

[nsx_node_agent]

[nsx_kube_proxy]

ovs_uplink_port = ens192

EOF

n Erstellen Sie die Konfigrationszuordnung aus der INI-Datei.

kubectl create configmap nsx-ncp-config-with-logging --from-file=/tmp/ncp.ini

n Erstellen Sie die rsyslog-Konfiguration für NCP.

cat <<EOF > /tmp/nsx-ncp-rsyslog.conf

# yaml template for NCP ReplicationController

# Correct kubernetes API and NSX API parameters, and NCP Docker image

# must be specified.

apiVersion: v1

kind: ConfigMap

metadata:


labels:

version: v1


VMware, Inc. 54

data:

ncp.conf: |



action(type="omfwd"

Protocol="tcp"

Target="nsx.licf.vmware.com"

Port="514")

stop

}

input(type="imfile"

File="/var/log/nsx-ujo/ncp.log"

Tag="ncp"

Ruleset="remote")

EOF

n Erstellen Sie die Konfigurationszuordnung aus dem Obenstehenden.

kubectl create -f /tmp/nsx-ncp-rsyslog.conf

n Erstellen Sie den NCP ReplicationController mit dem rsyslog-Sidecar.

cat <<EOF > /tmp/ncp-rc-with-logging.yml

# Replication Controller yaml for NCP

apiVersion: v1

kind: ReplicationController

metadata:

# VMware NSX Container Plugin

name: nsx-ncp

labels:

tier: nsx-networking

component: nsx-ncp

version: v1

spec:

# Active-Active/Active-Standby is not supported in current release.

# so replica *must be* 1.

replicas: 1

template:

metadata:

labels:


component: nsx-ncp

version: v1

spec:

# NCP shares the host management network.

hostNetwork: true

nodeSelector:

kubernetes.io/hostname: k8s-master

tolerations:

- key: "node-role.kubernetes.io/master"

operator: "Exists"


VMware, Inc. 55

effect: "NoSchedule"

containers:

- name: nsx-ncp

# Docker image for NCP

image: nsx-ujo-docker-local.artifactory.eng.vmware.com/nsx-ncp:ob-6236425


readinessProbe:

exec:

command:

- cat

- /tmp/ncp_ready

initialDelaySeconds: 5

periodSeconds: 5

failureThreshold: 5

securityContext:

capabilities:

add:

- NET_ADMIN

- SYS_ADMIN

- SYS_PTRACE

- DAC_READ_SEARCH

volumeMounts:

- name: config-volume

# NCP expects ncp.ini is present in /etc/nsx-ujo

mountPath: /etc/nsx-ujo

- name: log-volume


- name: rsyslog

image: jumanjiman/rsyslog


volumeMounts:



readOnly: true

- name: log-volume


volumes:


# ConfigMap nsx-ncp-config is expected to supply ncp.ini

configMap:

name: nsx-ncp-config-with-logging


configMap:


- name: log-volume

hostPath:

path: /var/log/nsx-ujo/

EOF

n Erstellen Sie NCP mit der oben angegebenen Spezifikation.

kubectl apply -f /tmp/ncp-rc-with-logging.yml


VMware, Inc. 56

Erstellen des DaemonSet des NSX-Knotenagents

n Erstellen Sie die rsyslog-Konfiguration für die Knotenagents.

cat <<EOF > /tmp/nsx-node-agent-rsyslog.conf

# yaml template for NCP ReplicationController

# Correct kubernetes API and NSX API parameters, and NCP Docker image

# must be specified.

apiVersion: v1

kind: ConfigMap

metadata:

name: rsyslog-config-node-agent

labels:

version: v1

data:

ncp.conf: |



action(type="omfwd"

Protocol="tcp"

Target="nsx.licf.vmware.com"

Port="514")

stop

}

input(type="imfile"

File="/var/log/nsx-ujo/nsx_kube_proxy.log"

Tag="nsx_kube_proxy"

Ruleset="remote")

input(type="imfile"

File="/var/log/nsx-ujo/nsx_node_agent.log"

Tag="nsx_node_agent"

Ruleset="remote")

EOF

n Erstellen Sie die configmap aus dem Obenstehenden.

kubectl create -f /tmp/nsx-node-agent-rsyslog.conf

n Erstellen Sie das DaemonSet mit dem configmap-Sidecar.

cat <<EOF > /tmp/nsx-node-agent-rsyslog.yml

# nsx-node-agent DaemonSet


kind: DaemonSet

metadata:

name: nsx-node-agent

labels:


component: nsx-node-agent

version: v1

spec:


VMware, Inc. 57

template:

metadata:

annotations:

container.apparmor.security.beta.kubernetes.io/nsx-node-agent: localhost/node-agent-

apparmor

labels:


component: nsx-node-agent

version: v1

spec:

hostNetwork: true

tolerations:

- key: "node-role.kubernetes.io/master"

operator: "Exists"

effect: "NoSchedule"

containers:

- name: nsx-node-agent




# override NCP image entrypoint

command: ["nsx_node_agent"]

livenessProbe:

exec:

command:

- /bin/sh

- -c

- ps aux | grep [n]sx_node_agent


periodSeconds: 5

securityContext:

capabilities:

add:

- NET_ADMIN

- SYS_ADMIN

- SYS_PTRACE

- DAC_READ_SEARCH

volumeMounts:

# ncp.ini



# mount openvswitch dir

- name: openvswitch

mountPath: /var/run/openvswitch

# mount CNI socket path

- name: cni-sock

mountPath: /var/run/nsx-ujo

# mount container namespace

- name: netns

mountPath: /var/run/netns

# mount host proc

- name: proc

mountPath: /host/proc

readOnly: true

- name: log-volume


VMware, Inc. 58


- name: nsx-kube-proxy




# override NCP image entrypoint

command: ["nsx_kube_proxy"]

livenessProbe:

exec:

command:

- /bin/sh

- -c

- ps aux | grep [n]sx_kube_proxy


periodSeconds: 5

securityContext:

capabilities:

add:

- NET_ADMIN

- SYS_ADMIN

- SYS_PTRACE

- DAC_READ_SEARCH

volumeMounts:

# ncp.ini



# mount openvswitch dir

- name: openvswitch

mountPath: /var/run/openvswitch

- name: log-volume


- name: rsyslog

image: jumanjiman/rsyslog


volumeMounts:



readOnly: true

- name: log-volume


volumes:


configMap:

name: nsx-ncp-config-with-logging

- name: cni-sock

hostPath:

path: /var/run/nsx-ujo

- name: netns

hostPath:

path: /var/run/netns

- name: proc

hostPath:

path: /proc

- name: openvswitch

hostPath:


VMware, Inc. 59

path: /var/run/openvswitch


configMap:

name: rsyslog-config-node-agent

- name: log-volume

hostPath:

path: /var/log/nsx-ujo/

EOF

n Erstellen Sie das DaemonSet-Objekt.

kubectl apply -f /tmp/nsx-node-agent-rsyslog.yml

Sicherheitsüberlegungen

Beim Bereitstellen von NCP ist es wichtig, Schritte zum Sichern der Kubernetes- und der NSX-T Data Center-Umgebungen auszuführen.

Beschränken der NCP-Ausführung auf bestimmte Knoten

NCP hat Zugriff auf die NSX-T Data Center-Management Plane, und die Ausführung sollte auf bestimmte Infrastrukturknoten beschränkt werden. Sie können diese Knoten mit einer entsprechenden Kennzeichnung identifizieren. Anschließend sollte ein nodeSelector-Objekt für diese Kennzeichnung auf die NCP ReplicationController-Spezifikation angewendet werden. Beispiel:

nodeSelector:

nsx-infra: True

Sie können auch andere Mechanismen wie die Affinität verwenden, um Knoten Pods zuzuweisen. Weitere Informationen finden Sie unter https://kubernetes.io/docs/concepts/configuration/assign-pod-node.

Stellen Sie sicher, dass die Docker-Engine aktuell ist

Docker veröffentlicht regelmäßig Sicherheits-Updates. Ein automatisierter Vorgang sollte implementiert werden, um diese Updates anzuwenden.

Nichtzulassen von NET_ADMIN- und NET_RAW-Funktionen nicht vertrauenswürdiger Container

Die Linux-Funktionen NET_ADMIN und NET_RAW können von Angreifern ausgenutzt werden, um das Pod-Netzwerk zu gefährden. Sie sollten diese beiden Funktionen der nicht vertrauenswürdigen Container deaktivieren. Standardmäßig wird die NET_ADMIN-Funktion auf einem nicht Container ohne Berechtigungen nicht gewährt. Seien Sie vorsichtig, wenn sie von


VMware, Inc. 60

https://kubernetes.io/docs/concepts/configuration/assign-pod-node

https://kubernetes.io/docs/concepts/configuration/assign-pod-node

einer Pod-Spezifikation explizit aktiviert oder der Container auf den privilegierten Modus festgelegt wird. Deaktivieren Sie darüber hinaus für nicht vertrauenswürdigen Container NET_RAW, indem Sie NET_RAW in der Liste der verworfenen Funktionen in der SecurityContext-Konfiguration der Container-Spezifikation angeben. Beispiel:

securityContext:

capabilities:

drop:

- NET_RAW

- ...

Rollenbasierte Zugriffssteuerung

Kubernetes verwendet die APIs für die rollenbasierte Zugriffssteuerung (RBAC) für Autorisierungsfestlegungen und ermöglicht Administratoren damit die dynamische Konfiguration von Richtlinien. Weitere Informationen finden Sie unter https://kubernetes.io/docs/admin/authorization/rbac.

Normalerweise ist der Cluster-Administrator der einzige Benutzer mit privilegiertem Zugriff und privilegierten Rollen. Für Benutzer und Dienstkonten muss beim Gewährend des Zugriffs das Prinzip der geringsten Berechtigung befolgt werden.

Die folgenden Richtlinien werden empfohlen:

n Beschränken Sie den Zugriffs auf Kubernetes-API-Token auf Pods, die sie benötigen.

n Beschränken Sie den Zugriff auf die geheimen TLS-Schlüssel des NCP ConfigMap- und NSX-API-Clientzertifikats auf den NCP-Pod.

n Blockieren Sie den Zugriff auf Kubernetes-Netzwerk-API von Pods, die diesen Zugriff nicht benötigen.

n Fügen Sie eine Kubernetes RBAC-Richtlinie hinzu, um anzugeben, welche Pods auf die Kubernetes-API zugreifen können.

Die empfohlene RBAC-Richtlinie befindet sich bereits in der NCP-YAML-Datei und wird bei der Installation von NCP wirksam.

Konfigurieren von Netzwerkressourcen

Beim Konfigurieren einiger Netzwerkressourcen müssen Sie sich bestimmter Einschränkungen bewusst sein.

Grenzwerte für Tags und Bezeichnungen

Tags weisen die folgenden Grenzwerte auf:

n Der Tag-Bereich hat einen Grenzwert von 128 Zeichen.

n Der Tag-Wert hat einen Grenzwert von 256 Zeichen.

n Jedes Objekt kann maximal 30 Tags aufweisen.


VMware, Inc. 61

https://kubernetes.io/docs/admin/authorization/rbac

https://kubernetes.io/docs/admin/authorization/rbac

Diese Grenzwerte können zu Problemen führen, wenn Kubernetes- oder OpenShift-Anmerkungen in NSX-T Data Center-Bereiche und -Tags kopiert und die Grenzwerte überschritten werden. Wenn ein Tag beispielsweise für einen Switch-Port bestimmt ist und das Tag in einer Firewallregel verwendet wird, wird die Regel möglicherweise nicht erwartungsgemäß angewendet, da der Anmerkungsschlüssel oder -wert beim Kopieren in einen Bereich oder ein Tag möglicherweise abgeschnitten wurde.

Bezeichnungen weisen die folgenden Grenzwerte auf:

n Ein Pod darf höchstens 25 Bezeichnungen aufweisen.

n Ein Namespace darf höchstens 27 Bezeichnungen aufweisen.

n Ein Ingress-Controller-Pod darf nicht mehr als 24 Bezeichnungen aufweisen.

Netzwerkrichtlinien

Eine NetworkPolicy-Ressource weist die folgenden Einschränkungen auf:

n Ein podSelector oder namespaceSelector darf nicht mehr als 4 matchLabels aufweisen.

n Wenn Sie im Abschnitt ingress from oder egress to über ein einzelnes Element verfügen, das sowohl namespaceSelector als auch podSelector angibt, darf der namespaceSelector nicht mehr als 5 Namespaces auswählen. Andernfalls tritt ein Fehler auf. Ein Beispiel für eine solche Spezifikation (es gibt keine Bindestriche vor podSelector):

- namespaceSelector:

matchLabels:

project: myproject

podSelector:

matchLabels:

role: db

n Bei jeder Ingress- oder Egress-Regel darf die Gesamtzahl der namespaceSelectoren plus podSelectoren nicht mehr als 5 sein. Beispielsweise ist Folgendes nicht zulässig, weil die Regel aus 6 Selektoren besteht:

ingress:


matchLabels:

project: myproject1


matchLabels:

project: myproject2


matchLabels:

project: myproject3

- podSelector:

matchLabels:

role: db

- podSelector:

matchLabels:


VMware, Inc. 62

role: app

- podSelector:

matchLabels:

role: infra

n Die Netzwerkrichtlinie „Gesamten Egress zulassen“ mit namedPorts im Abschnitt to.ports wird nicht unterstützt.

n Das Feld matchExpressions wird nicht unterstützt.

n Die Netzwerkrichtlinie mit SCTP im Feld protocol wird nicht unterstützt.

Um die Einschränkungen zu umgehen, können Sie eine Netzwerkrichtlinie mit spezifischeren matchLabels erstellen oder eine Netzwerkrichtlinie durch mehrere Netzwerkrichtlinien ersetzen, die nicht mehr als 5 Selektoren benötigen.

Wenn eine Netzwerkrichtlinie von NCP nicht unterstützt wird, wird sie von NCP mit einer Fehleranmerkung versehen. Sie können die Netzwerkrichtlinie aktualisieren, um den Fehler zu beheben, und NCP wird sie erneut verarbeiten.

Wenn in NCP 3.0.0 und 3.0.1 für eine Netzwerkrichtlinie nur ein Egress angegeben ist, sie aber keinen Ingress aufweist, wird eine Firewallregel erstellt, um den gesamten Ingress-Datenverkehr zuzulassen. In ähnlicher Weise wird eine Firewallregel erstellt, um den gesamten Egress-Datenverkehr zuzulassen, wenn für eine Netzwerkrichtlinie nur Ingress angegeben ist, aber kein Egress.

Beginnend mit NCP 3.0.2 wird für den Ingress-Datenverkehr keine Firewallregel erstellt, wenn für eine Netzwerkrichtlinie nur Egress angegeben wurde, aber kein Ingress. In ähnlicher Weise wird eine Firewallregel für den Egress-Datenverkehr zugelassen, wenn für eine Netzwerkrichtlinie nur Ingress angegeben ist, aber kein Egress.

Kubernetes-Knoten bereinigen

Sie können Dateisystemänderungen bereinigen, die vom Bootstrap-Container vorgenommen werden.

Hinweis Wenn das NSX-Node-Agent-DaemonSet entfernt wird, wird OVS nicht mehr auf dem Host (im Container oder in der PID des Hosts) gestartet.

Verfahren für NCP 2.5.0

Sie können die vom Bootstrap-Container vorgenommenen Änderungen rückgängig machen, indem Sie die folgenden Schritte ausführen:

n NSX-CNI entfernen:

n Entfernen Sie /etc/cni/net.d/10-nsx.conf.

n Entfernen Sie /etc/cni/net.d/99-loopback.conf.

n Entfernen Sie /opt/cni/bin/Loopback nur auf RHEL.


VMware, Inc. 63

n Entfernen Sie /opt/cni/bin/nsx.

n Führen Sie nur auf Ubuntu die folgenden Befehle aus:

apparmor_parser -R /etc/apparmor.d/ncp-apparmor

rm -rf /etc/apparmor.d/ncp-apparmor

sudo /etc/init.d/apparmor reload

n NSX-installiertes OVS-kmod entfernen:

OVS-kmod enthält die folgenden Dateien:

openvswitch.ko

vport-geneve.ko

vport-gre.ko

vport-lisp.ko

vport-stt.ko

vport-vxlan.ko

n Suchen Sie Ihre ausgeführte Kernel-Version mit dem Befehl uname -r.

n Entfernen Sie nur auf RHEL alle OVS-kmod-Dateien aus /lib/modules/${kversion}/weak-updates/openvswitch.

n Entfernen Sie nur auf Ubuntu alle OVS-kmod-Dateien aus /lib/modules/${kversion}/updates/dkms.

n Wechseln Sie zu /lib/modules/${kversion}/nsx und überprüfen Sie, ob das Verzeichnis usr-ovs-kmod-backup vorhanden ist. Wenn dies der Fall ist, wurde ein benutzerdefiniertes OVS-Kernel-Modul installiert. Führen Sie die folgenden Schritte aus:

n Wechseln Sie zu /lib/modules/${kversion}/nsx/usr-ovs-kmod-backup.

n Suchen Sie die Datei mit dem Namen INFO. Sie enthält den Pfad, in dem die Dateien gefunden werden können. Verwenden Sie diesen Pfad, um die Dateien wiederherzustellen.

n Führen Sie den Befehl depmod aus.

n Führen Sie den Befehl /usr/share/openvswitch/scripts/ovs-ctl force-reload-kmod --system-id=random aus, wenn OVS auf der Hostmaschine installiert ist.

Verfahren für NCP 2.5.1 und höher

Sie können das NSX-NCP-Cleanup-DaemonSet erstellen, um die von NSX-NCP-Bootstrap-DaemonSet vorgenommenen Systemänderungen rückgängig zu machen. Diesen DaemonSet darf nur erstellt werden, wenn Sie zuvor die NCP YAML-Datei (ncp-ubuntu.yaml oder ncp-rhel.yaml) angewendet und nicht gelöscht haben. Beachten Sie, dass der nsx-ncp-cleanup DaemonSet NSX CNI deinstalliert, was zu einem ungültigen Kubernetes-Knotenstatus führt.


VMware, Inc. 64

Um das DaemonSet zu erstellen, führen Sie die folgenden Schritte aus:

n Löschen Sie die DaemonSets nsx-ncp-bootstrap und nsx-node-agent. Sie können z. b. die folgenden Befehle mit dem entsprechenden Namespacenamen ausführen:

kubectl delete ds nsx-ncp-bootstrap -n <namespace>

kubectl delete ds nsx-node-agent -n <namespace>

n Führen Sie kubectl apply -f ncp-cleanup-ubuntu.yaml oder kubectl apply -f ncp-cleanup-rhel.yaml je nach Hostbetriebssystem über die Befehlszeile auf dem Kubernetes-Masterknoten aus.

Um den Knoten wieder nutzbar zu machen, führen Sie je nach Hostbetriebssystem kubectl apply -f ncp-ubuntu.yaml oder kubectl apply -f ncp-rhel.yaml aus.


VMware, Inc. 65

Installieren von NCP in einer Pivotal Cloud Foundry(PCF)-Umgebung

4Pivotal Cloud Foundry (PCF) ist ein Open Source-PaaS-Anbieter (Platform-as-a-Service). Sie können das NSX Container Plug-in (NCP) in einer PCF-Umgebung installieren, um Netzwerkdienste bereitzustellen.

Über den Pivotal Ops Manager erstellte VMs müssen Schicht-3-Konnektivität zum Containernetzwerk aufweisen, damit sie auf die NSX-T-Funktionen zugreifen können.

Hochverfügbarkeit (HA) ist automatisch aktiviert.

Hinweis Wenn eine Änderung an einer Sicherheitsgruppe vorgenommen wird, müssen alle Anwendungen, für die die Sicherheitsgruppe gilt, erneut bereitgestellt werden. Dies kann passieren, weil die Sicherheitsgruppe für den Speicherbereich gilt, in dem die Anwendungen ausgeführt werden, oder weil es sich um eine globale Sicherheitsgruppe handelt.

Wenn Sie eine Standard-ASG (App Security Group) in Ihrer PAS-Umgebung haben, müssen Sie einen globalen Firewallabschnitt außerhalb von NCP erstellen, um die Standard-ASG zu ersetzen.


n Installieren von NCP in einer Pivotal Cloud Foundry(PCF)-Umgebung

n Verarbeiten von in PAS erstellten benutzerdefinierten Bezeichnungen

Installieren von NCP in einer Pivotal Cloud Foundry(PCF)-Umgebung

NCP wird über die grafische Pivotal Ops Manager-Benutzeroberfläche installiert.

Voraussetzungen

Eine Neuinstallation von Pivotal Ops Manager, NSX-T Data Center und Pivotal Application Service (PAS). Stellen Sie sicher, dass Ops Manager zuerst, dann NSX-T Data Center und dann PAS installiert wird. Weitere Informationen finden Sie in der Pivotal Cloud Foundry-Dokumentation.

VMware, Inc. 66

Verfahren

1 Laden Sie die NCP-Installationsdatei für PCF herunter.

Der Dateiname lautet VMware-NSX-T.<version>.<build>.pivotal.

2 Melden Sie sich bei Pivotal Ops Manager als Administrator an.

3 Klicken Sie auf Produkt importieren.

4 Wählen Sie die heruntergeladene Datei aus.

5 Klicken Sie auf die Kachel Ops Manager Director für VMware vSphere.

6 Wählen Sie auf der Registerkarte Einstellungen für vCenter-Konfiguration die Option NSX-Netzwerk und für NSX-Modus die Option NSX-T aus.

7 Stellen Sie im Feld NSX-CA-Zertifikat das Zertifikat im PEM-Format bereit.

8 Klicken Sie auf Speichern.

9 Klicken Sie in der oberen linken Ecke auf Installations-Dashboard, um zum Dashboard zurückzukehren.

10 Klicken Sie auf die Kachel Pivotal Application Service.

11 Wählen Sie auf der Registerkarte Einstellungen im Navigationsbereich die Option Netzwerk aus.

12 Wählen Sie unter Container-Netzwerkschnittstellen-Plug-In die Option Extern aus.




16 Klicken Sie auf die Kachel VMware NSX-T.

17 Geben Sie die Adresse des NSX Manager an.

18 Wählen Sie die Methode für die NSX Manager-Authentifizierung aus.

Option Aktion

Clientzertifikat-Authentifizierung Stellen Sie das Zertifikat und den privaten Schlüssel für NSX Manager bereit.

Standardauthentifizierung mit Benutzername und Kennwort

Geben Sie den Benutzernamen und das Kennwort eines NSX Manager-Administrators ein.

19 Stellen Sie im Feld NSX Manager-CA-Zertifikat das Zertifikat bereit.


21 Wählen Sie im Navigationsbereich NCP aus.


VMware, Inc. 67

22 Nehmen Sie eine Eingabe unter PAS Foundation-Name vor.

Diese Zeichenfolge dient der eindeutigen Identifizierung einer PAS Foundation in der NSX API. Diese Zeichenfolge wird auch in Namen von NSX-Ressourcen, die von NCP für die PAS Foundation erstellt wurden, als Präfix verwendet.

23 Nehmen Sie eine Eingabe unter Overlay-Transportzone vor.

24 Geben Sie den Tier-0-Router ein.

25 Geben Sie unter IP-Blöcke von Containernetzwerken mindestens einen IP-Block an.

a Klicken Sie auf Hinzufügen.

b Nehmen Sie eine Eingabe unter Name des IP-Blocks vor. Hierbei kann es sich um einen neuen oder vorhandenen IP-Block handeln.

c Geben Sie einen neuen IP-Block im CIDR-Format ein, z. B. 10.1.0.0/16.

26 Geben Sie das Subnetzpräfix der Containernetzwerke an.

27 Klicken Sie auf SNAT für Containernetzwerke aktivieren, um SNAT zu aktivieren.

28 Geben Sie unter IP-Pools, die zum Bereitstellen externer IP-Adressen (NAT) für Organisationsnetzwerke verwendet werden mindestens einen IP-Pool an.

a Klicken Sie auf Hinzufügen.

b Nehmen Sie eine Eingabe unter Name des IP-Pools vor. Hierbei kann es sich um einen neuen oder vorhandenen IP-Pool handeln.

c Geben Sie nur für einen neuen IP-Pool die IP-Adressen an, indem Sie die CIDR- und IP-Bereiche bereitstellen.

29 (Optional) Nehmen Sie eine Eingabe unter Obere Markierung für Firewallabschnitt vor.

30 (Optional) Nehmen Sie eine Eingabe unter Untere Markierung für Firewallabschnitt vor.

31 (Optional) Aktivieren oder deaktivieren Sie die folgenden Optionen.

Option Standardwert

Verloren gegangenen Anwendungsdatenverkehr protokollieren

Deaktiviert. Ist diese Option aktiviert, wird aufgrund einer Firewallregel verloren gegangener Datenverkehr protokolliert.

Debugebene für NCP-Protokollierung aktivieren

Aktiviert.


33 (Optional) Wählen Sie im Navigationsbereich NSX-Knotenagent aus.

a Aktivieren Sie die Option Debugebene der Protokollierung für NSX-Knotenagent aktivieren, um die Protokollierung mit Debugebene zu aktivieren.

b Klicken Sie auf Speichern.


VMware, Inc. 68


35 Klicken Sie auf Änderungen übernehmen.

Verarbeiten von in PAS erstellten benutzerdefinierten Bezeichnungen

NCP kann benutzerdefinierte Labels verarbeiten, die Sie in einer App in PAS erstellen. NCP erstellt für diese Bezeichnungen entsprechende Tags in NSX-T.

In Pas können Sie Beschriftungen mit dem folgenden Befehl erstellen. Beispiel:

cf curl v3/apps/<app-guid> -X PATCH -d '{"metadata": {"labels": {"aaa": "111", "bbb": "222"}}

Sie können eine Bezeichnung auch löschen, indem Sie den Wert einer Bezeichnung auf null festlegen, z. b.

cf curl v3/apps/<app-guid> -X PATCH -d '{"metadata": {"labels":{"aaa": null}}}'

Diese Befehle lösen Ereignisse aus, die NCP abrufen kann. Für eine neue Bezeichnung, z. b. "aaa":"111", erstellt NCP das Tag app_label/aaa:111 für die logischen Ports aller App-Instanzen. Wenn Sie eine Bezeichnung löschen, wird das entsprechende Tag entfernt.


VMware, Inc. 69

Load Balancing 5Der Load Balancer von NSX-T Data Center ist in Kubernetes integriert.


n Konfigurieren von Load Balancing

n Festlegen der Persistenz für den Load Balancer auf Schicht 4 und Schicht 7

n Ingress

n LoadBalancer CRDs to Handle Ingress Scaling

n Dienst vom Typ LoadBalancer

n Load Balancer und Netzwerkrichtlinie

n Beispielskript zum Generieren eines von einer Zertifizierungsstelle signierten Zertifikats

n Ingress-Controller von Drittanbietern

Konfigurieren von Load Balancing

Sie können die Integration von NSX-T Load Balancer mit NCP für Kubernetes LoadBalancer-Dienste und Ingress-Ressourcen konfigurieren.

Beim Konfigurieren eines Kubernetes-Diensts vom Typ "LoadBalancer" wird ein Schicht-4 Load Balancer erstellt, und durch die Konfiguration einer Kubernetes-Ingress-Ressource wird ein Schicht-7 Load Balancer erstellt.

So konfigurieren Sie Load Balancing in der NSX-NCP-config-ConfigMap:

1 Legen Sie use_native_loadbalancer = True fest.

2 (Optional) Legen Sie pool_algorithm auf ROUND_ROBIN oder LEAST_CONNECTION/IP_HASH fest. Die Standardeinstellung ist ROUND_ROBIN.

3 (Optional) Legen Sie service_size = SMALL, MEDIUM oder LARGE fest. Die Standardeinstellung ist SMALL. Legen Sie im Richtlinienmodus diesen Wert auf die Größe der Poolzuteilung des Tier-1-Gateways fest.

VMware, Inc. 70

Der Algorithmus LEAST_CONNECTION/IP_HASH bedeutet, dass Datenverkehr von derselben Quell-IP-Adresse zum selben Backend-Pod gesendet wird.

Weitere Informationen dazu, was von NSX-T-Load Balancern unterschiedlicher Größe unterstützt wird, finden Sie im Administratorhandbuch für NSX-T Data Center.

Nachdem der Load Balancer erstellt wurde, kann seine Größe nicht durch Aktualisierung der Konfigurationsdatei geändert werden. Die Größe kann über die NSX Manager-Benutzeroberfläche oder -API geändert werden.

Sie können ein IPSet konfigurieren, das von NCP mit den IPs aller virtuellen Server aufgefüllt wird. Um diese Funktion zu aktivieren, legen Sie die Option lb_vs_ip_set in der NSX-NCP-config-ConfigMap auf den Namen oder die UUID einer IPSet fest. Die IPSet können von mehreren Clustern gemeinsam genutzt werden. Die IPs müssen in allen Clustern eindeutig sein. NCP verwaltet die Zuteilung der IPs.

Festlegen der Persistenz für den Load Balancer auf Schicht 4 und Schicht 7Mit den Parametern l4_persistence und l7_persistence können Sie im NCP-ConfigMap-Objekt eine Persistenzeinstellung angeben.

Die verfügbare Option für die Schicht-4-Persistenz ist „Quell-IP“. Die verfügbaren Optionen für die Schicht-7-Persistenz sind „Cookie“ und „Quell-IP“. Die Standardeinstellung ist <None>. Beispiel:

# Choice of persistence type for ingress traffic through L7 Loadbalancer.

# Accepted values:

# 'cookie'

# 'source_ip'

l7_persistence = cookie

# Choice of persistence type for ingress traffic through L4 Loadbalancer.

# Accepted values:

# 'source_ip'

l4_persistence = source_ip

Für einen Kubernetes-LoadBalancer-Dienst können Sie sessionAffinity auch in der Dienstspezifikation angeben, um das Persistenzverhalten für den Dienst zu konfigurieren, wenn die globale Schicht-4-Persistenz deaktiviert, also l4_persistence auf <None> festgelegt ist. Wenn l4_persistence auf source_ip festgelegt ist, kann die sessionAffinity auf der Dienstspezifikation verwendet werden, um die Persistenz-Zeitüberschreitung für den Dienst anzupassen. Die standardmäßige Persistenz-Zeitüberschreitung von Layer 4 beträgt 10.800 Sekunden (wie in der Kubernetes-Dokumentation für Dienste (https://kubernetes.io/docs/


VMware, Inc. 71

https://kubernetes.io/docs/concepts/services-networking/service

concepts/services-networking/service) angegeben. Alle Dienste mit standardmäßiger Persistenz-Zeitüberschreitung nutzen das gleiche Persistenz-Profil des NSX-T-Load Balancer. Für jeden Dienst mit einer nicht standardmäßigen Persistenz-Zeitüberschreitung wird ein dediziertes Profil erstellt.

Hinweis Wenn der Backend-Dienst eines Ingress ein Dienst des Typs LoadBalancer ist, dürfen der virtuelle Server der Schicht 4 für den Dienst und der virtuelle Server der Schicht 7 für den Ingress nicht unterschiedliche Persistenzeinstellungen aufweisen, beispielsweise source_ip für Schicht 4 und cookie für Schicht 7. In einem Szenario dieser Art müssen die Persistenzeinstellungen für beide virtuelle Server identisch sein (source_ip, cookie oder None), oder einer davon hat die Einstellung None (in diesem Fall kann die andere Einstellung source_ip oder cookie lauten). Beispiel für ein Szenario dieser Art:


kind: Ingress

metadata:

name: cafe-ingress

spec:

rules:

- host: cafe.example.com

http:

paths:

- path: /tea

backend:

serviceName: tea-svc

servicePort: 80

-----

apiVersion: v1

kind: Service

metadata:

name: tea-svc <==== same as the Ingress backend above

labels:

app: tea

spec:

ports:

- port: 80

targetPort: 80

protocol: TCP

name: tcp

selector:

app: tea

type: LoadBalancer

Ingress

NCP will create one layer 7 load balancer for Ingresses with TLS specification, and one layer 7 load balancer for Ingresses without TLS specification. You can also create CRDs (CustomResourceDefinitions) to handle Ingress scaling.


VMware, Inc. 72

https://kubernetes.io/docs/concepts/services-networking/service

Note the following:

n All Ingresses will get a single IP address.

n The Ingress resource is allocated an IP address from the external IP pool specified by the external_ip_pools option in the [nsx_v3] section in ncp.ini. The load balancer is exposed on this IP address and the HTTP and HTTPS ports (80 and 443).

n The Ingress resource is allocated an IP address from the external IP pool specified by the external_ip_pools_lb option in the [nsx_v3] section in ncp.ini. If the external_ip_pools_lb option does not exist, the pool specified by external_ip_pools is used. The load balancer is exposed on this IP address and the HTTP and HTTPS ports (80 and 443).

n You can change to a different IP pool by changing the configuration and restarting NCP.

n You can specify a default certificate for TLS. See below for information about generating a certificate and mounting a certificate into the NCP pod.

n Ingresses without TLS specification will be hosted on HTTP virtual server (port 80).

n Ingresses with TLS specification will be hosted on HTTPS virtual server (port 443). The load balancer will act as an SSL server and terminate the client SSL connection.

n Modification of Ingress by adding or removing the TLS section is supported. When the tls key is removed from the Ingress specification, the Ingress rules will be transferred from the HTTPS virtual server (port 443) to the HTTP virtual server (port 80). Similarly, when the tls key is added to Ingress specification, the Ingress rules are transferred from the HTTP virtual server (port 80) to the HTTPS virtual server (port 443).

n If there are duplicate rules in Ingress definitions for a single cluster, only the first rule will be applied. The other Ingresses with the duplicate rules will be annotated with error. For example, if you create two Ingresses with the same host and path, and one Ingress is TLS while and the other is non-TLS, and kubernetes.io/ingress.allow-http is false, the two rules will be created on different virtual servers and will not conflict with each other. However, if kubernetes.io/ingress.allow-http is true, the Ingress that is applied later will be annotated with an error. See the "Errors" section below for more information.

n Only a single Ingress with a default backend is supported per cluster. Traffic not matching any Ingress rule will be forwarded to the default backend.

n If there are multiple Ingresses with a default backend, only the first one will be configured. The others will be annotated with an error. See the "Errors" section below for more information.

n (NCP 3.0.0 and 3.0.1) The rules are applied in the following order:

a Rules with both host and path specified, and without regular expression matching.

b Rules with both host and path specified, and with regular expression matching (with the longest Ingress path first).

c Rules with host or path specified, and without regular expression matching.


VMware, Inc. 73

d Rules with host or path specified, and with regular expression matching (with the longest Ingress path first).

n (NCP 3.0.2 and later) The rules are applied in the following order:

a Rules with both host and path specified.

1 Rules with the Exact pathType.

2 Rules with the Prefix pathType.

3 Rules with the Regex pathType.

b Rules with host or path specified.

1 Rules with the Exact pathType.

2 Rules with the Prefix pathType.

3 Rules with the Regex pathType.

Note: If multiple paths match a request, precedence will be given to the longest matching path.

About pathType:

n ImplementationSpecific is treated the same as Exact.

n Two matching paths with different pathTypes can co-exist.

n For the Prefix type, /foo will match /foo/, /foo/bar but not /foo or /foobar. To match /foo, add the Exact path /foo to the Ingress rule.

n (This is applicable if you use Policy mode.) If a TLS Ingress is created with a default backend, it is recommended that you set up the default backend to respond to both HTTP and HTTPS requests because:

n The load balancer will terminate TLS and send HTTP requests to the default backend server if there is a TLS Ingress (in the cluster for the Kubernetes/PKS use case, or in the same namespace for the Project Pacific use case) with host which matches the host in the request.

n The load balancer will re-encrypt and send HTTPS request to the backend server if there is no TLS Ingress (in the cluster for the Kubernetes/PKS use case, or in the same namespace for the Project Pacific use case) with host which matches the host in the request.

n The IngressClass resource is not supported.

n (NCP 3.0.0 and 3.0.1) The pathType attribute is not supported.

n (NCP 3.0.2 and later) The pathType attribute is supported.

n (NCP 3.0.2 and later) JWT (JSON Web Token) client authentication is supported. This feature requires NSX-T Data Center 3.0.0 or later.


VMware, Inc. 74

Feature Annotations

The following table lists annotations that NCP supports:

Annotation Description Supported Values Default Value NCP Version

kubernetes.io/ingress.allow-http

Enables HTTP requests in addition to HTTPS

true, false true 2.5 and later

ncp/use-regex Enables path pattern matching

true, false false 2.5.1 and later

ingress.kubernetes.io/rewrite-target

Rewrites path of incoming request

n (NCP 2.5 and later) Path starting with ‘/’

n (NCP 2.5.1 and later, and NSX-T 2.5.1 and later) Path with a numbered placeholder for a group captured in a regular expression, for example, /$1

No default value See the Supported Values column

ncp/http-redirect Redirects HTTP requests to HTTPS

true, false false 2.5.1 and later

kubernetes.io/ingress.class

Indicates which Ingress controller is responsible for this Ingress

nsx, nginx, etc. nsx 2.5 and later

nsx/loadbalancer Places an Ingress on a dedicated load balancer

Name of a LoadBalancer CRD

No default value 2.5.1 and later

ncp/whitelist-source-range

Limits Ingress access by request source IP

Comma-separated list of CIDRs, IP addresses, or IP ranges.


ncp/ssl-mode Selects SSL mode for all the rules in an Ingress

offload, reencrypt, passthrough

offload 3.0.1 and later

ncp/jwt-alg Determines the algorithm to be used to validate JWT signature. Enables JWT client authentication when set with ncp/jwt-secret.

HS256, RS256 No default value 3.0.2 and later


VMware, Inc. 75

Annotation Description Supported Values Default Value NCP Version

ncp/jwt-secret Specifies the name of the Kubernetes secret that contains the JWT secret or public key used for signature validation. Enables JWT client authentication when set with ncp/jwt-alg.

Name of a Kubernetes secret


ncp/jwt-token Additional location to search for JWT in the HTTP request.

_arg_<param_name>, _cookie_<cookie_name>


ncp/jwt-realm Specifies the Realm header returned with 401 when authentication failed.

String indicating the realm

Hostname of the ingress rule

3.0.2 and later

ncp/jwt-preserve Option to keep JWT and pass to backend after successful authentication.

true, false true 3.0.2 and later

Details about the annotations:

n Path Regex (Regular Expression) Matching

n For NCP 2.5.0 and earlier

In NCP 2.5.0 and earlier, all sub-path matching is automatically enabled using the regular expression characters '.' and '*'. For example, the path /coffee/.* matches /coffee/ followed by zero, one or more characters, such as /coffee/, /coffee/a, and /coffee/b, but not /coffee, /coffeecup or /coffeecup/a.

An Ingress specification example:

kind: Ingress

metadata:

name: cafe-ingress

spec:

rules:

- http:

paths:

- path: /coffee/.* #Matches /coffee/, /coffee/a but NOT /coffee, /coffeecup, etc.

backend:

serviceName: coffee-svc

servicePort: 80

n For NCP 2.5.1 and later


VMware, Inc. 76

You can enable or disable regular expression matching of the Ingress path (but not host) parameter using the annotation ncp/use-regex. If set to false, exact path matching will be performed by doing the equals match. If set to true, regular expression matching will be performed by adding the start of string character (^) and end of string character ($) to the path so that the entire request URI matches the pattern. Note that when using the OR operator (|), always specify the scope with parentheses so that ^ and $ apply to all the operands. For example, path: /(tea|coffee|milk). An Ingress specification example:

kind: Ingress

metadata:

name: cafe-ingress

annotations:

kubernetes.io/ingress.class: "nsx"

ncp/use-regex: "true"

spec:

rules:


http:

paths:

- path: /tea/.*

backend:


servicePort: 80

n Updating Ingresses prior to upgrading NCP to 2.5.1 or later

This is required only if you have Ingresses requiring all sub-path matching using the characters '.' and '*'.

1 Update the Ingresses to include the annotation ncp/use-regex: true.

2 For all sub-path matching, if you have paths such as /coffee/* or /*, change them to /coffee/.* and /.*.

/coffee/.* will match /coffee/, /coffee/a, /coffee/b, /coffee/a/b, and so on. /.* will match /coffee, /tea, /coffee/a, and so on. Omitting the path will produce the same behavior as path: /.*.

n Example of the annotation ingress.kubernetes.io/rewrite-target:

kind: Ingress

metadata:

name: cafe-ingress

annotations:

ingress.kubernetes.io/rewrite-target: /

spec:

rules:


http:

paths:

- path: /tea

backend:



VMware, Inc. 77

servicePort: 80

- path: /coffee

backend:


servicePort: 80

The paths /tea and /coffee will be rewritten to / before the URL is sent to the backend service.

Starting with NCP 2.5.1 and NSX-T 2.5.1, if path is specified using a regular expression, the captured groups are saved in numbered placeholders in the form $1, $2, and so on. These placeholders can be used as parameters in the ingress.kubernetes.io/rewrite-target annotation. Named capture groups and named placeholders are not supported. For example,

kind: Ingress

metadata:

name: cafe-ingress

annotations:


ncp/use-regex: "true"

#/tea/cup will be rewritten to /cup before sending request to endpoint

ingress.kubernetes.io/rewrite-target: /$1

spec:

rules:


http:

paths:

- path: /tea/(.*)

backend:


servicePort: 80

n About the annotation kubernetes.io/ingress.allow-http:

n If the annotation is set to false, rules will be created for the HTTPS virtual server.

n If the annotation is set to true or missing, rules will created for both HTTP and HTTPS virtual servers. Note that HTTPS rules will be created only if the TLS section is present in the Ingress specification.

n About the annotation ncp/http-redirect:

n If the annotation is set to false, Incoming HTTP traffic (port 80) to HTTP Virtual Server will not be redirected to HTTPS Virtual Server.

n If the annotation is set to true, Incoming HTTP traffic (port 80) to HTTP Virtual Server will be redirected to HTTPS Virtual Server (port 443).

This annotation is only valid if the TLS section is present. This annotation takes precedence over kubernetes.io/ingress.allow-http. When set to true, it will direct matched HTTP traffic to HTTPS, regardless of how kubernetes.io/ingress.allow-http is set.


VMware, Inc. 78

n About the annotation kubernetes.io/ingress.class:

n If the value is nsx, this ingress will be handled by NCP. If any other value is specified, the Ingress will be ignored by NCP. For more info see Ingress-Controller von Drittanbietern.

n For more information about the annotation nsx/loadbalancer, see LoadBalancer CRDs to Handle Ingress Scaling.

n About the annotation ncp/whitelist-source-range:

n When set, an incoming request will only be accepted if its source IP is included in this annotation. Otherwise, traffic will be dropped.

n You can specify a combination of CIDR, IP addresses, and IP ranges. For example, 1.1.1.1/24, 2.2.2.2, 3.3.3.3-4.4.4.4.

n Example YAML:

kind: Ingress

metadata:

name: cafe-ingress

annotations:


ncp/whitelist-source-range: "192.168.128.0/17, 192.168.64.0-192.168.64.255, 192.168.16.32"

spec:

tls:

- hosts:

- cafe.example.com

rules:


http:

paths:

- path: /tea

backend:


servicePort: 80

n About the annotation ncp/ssl-mode:

n This annotation applies to all the rules in an Ingress and the load balancer will operate in the selected SSL mode for these rules.

Note: If ncp/ssl-mode is set to reencrypt or passthrough, kubernetes.io/ingress.allow-http must be set to False. This annnotation cannot be set to passthrough if the ingress.kubernetes.io/rewrite-target, ncp/use-regex or ncp/whitelist-source-range annotation is set.

n About JWT client authentication:

n To enable JWT client authentication for all rules under an Ingress, both ncp/jwt-alg and ncp/jwt-secret need to be set to a valid value. When enabled, incoming HTTP traffic will only be passed to the backend if bearing valid JSON web token. Otherwise, traffic will be rejected with the 401 status.


VMware, Inc. 79

n This feature is incompatible with the following annotations:

n kubernetes.io/ingress.allow-http: true

n ncp/http-redirect: true

n ncp/ssl-mode: passthrough

n ncp/jwt-alg:

n Supported symmetrical algorithms: HS256

n Supported asymmetrical algorithms: RS256

n ncp/jwt-secret:

n A symmetrical key or public certificate must be configured in a Kubernetes secret with the name specified in this annotation under the same namespace as the Ingress.

n For symmetrical algorithms, the secret must be stored in the jwt.key field.

n For asymmetrical algorithms, the public cert must be stored in the tls.crt field.

n JWT client authentication will be disabled if the symmetrical secret or public certificate is not stored in the locations mentioned above, or if the data stored in the secret is invalid.

n ncp/jwt-token:

n Only one item can be configured in this annotation.

n _arg_<param_name>: For JWT passed in as a URI parameter. Specify the parameter name that contains JWT.

n _cookie_<cookie_name>: For JWT passed in as a cookie. Specify the cookie name that contains JWT.

Errors

Errors are annotated to the Ingress resource. The error key is ncp/error.loadbalancer and the warning key is ncp/warning.loadbalancer. The possible error and warning are:

n ncp/error.loadbalancer: DEFAULT_BACKEND_IN_USE

This error indicates that an Ingress with a default backend already exists. The Ingress will be inactive. This error will occur if (1) this Ingress is for HTTP and another Ingress for HTTP with a default backend exists; (2) this Ingress is for HTTPS and another Ingress for HTTPS with a default backend exists; or (3) this Ingress is for HTTP and HTTPS and another Ingress for HTTP and HTTPS with a default backend exists. To fix the error, delete and recreate the Ingress with a correct specification.

n ncp/warning.loadbalancer: SECRET_NOT_FOUND


VMware, Inc. 80

This error indicates that the secret specified in the Ingress specification does not exist, or if ncp/jwt-alg and ncp/jwt-secret are anootated but the secret cannot be found under the same namespace as the Ingress. The Ingress will be partially active. To fix the error, create the missing secret. Note that once a warning is in the annotation, it will not be cleared during the life cycle of the Ingress resource.

n ncp/warning.loadbalancer: INVALID_INGRESS

This error indicates that one of the following conditions is true. The Ingress will be inactive. To fix the error, delete and recreate the Ingress with a correct specification.

n An Ingress rule conflicts with another Ingress rule in the same Kubernetes cluster. Conflicts are determined only for Ingresses with the same match strategy, that is, the same ncp/use-regex annotation value.

n The kubernetes.io/ingress.allow-http annotation is set to false and the Ingress does not have a TLS section.

n The ncp/http-redirect annotation is set to true and the Ingress does not have a TLS section.

n An Ingress rule does not have host and path specified. Such an Ingress rule has the same functionality as the Ingress default backend. Use the Ingress default backend instead.

n The Ingress has JWL annotations that cannot be correctly processed. For example:

n Either ncp/jwt-alg or ncp/jwt-secret is missing.

n ncp/jwt-alg is configured with an unsupported algorithm.

n ncp/jwt-alg and ncp/jwt-secret are configured with other HTTP enabling annotations, or with ssl passthrough.

LoadBalancer CRDs to Handle Ingress Scaling

You can create CRDs (CustomResourceDefinitions) to monitor the usage of NSX load balancers and to create additional NSX layer 7 load balancers to handle Ingress workloads that the default load balancer cannot handle. These CRDs are not for scaling layer 4 load balancers that are created for Kubernetes LoadBalancer services.

In Manager mode, this feature is supported starting with NCP 2.5.1. In Policy mode, this feature is supported starting with NCP 3.0.1.

The CRDs are:

n NSXLoadBalancerMonitor - This CRD is used to report usage statistics of the NSX load balancers. In Policy mode, this CRD will only monitor namespace load balancers created using the LoadBalancer CRD.

n LoadBalancer - This CRD is used to create new NSX load balancers. The definition of this resource is in the NCP YAML file. In Policy mode and PKS deployments, this is a namespace resource. In Manager mode deployments, this is a clusterwide resource.


VMware, Inc. 81

In Manager mode, perform the following steps to enable this feature:

n Set the enable_lb_crd option in the k8s section to True.

n Apply the NCP YAML file with the following command:

kubectl apply -f ncp-<platform>.yaml

In Policy mode, perform the following steps to enable this feature:

n If you upgraded NCP from a previous version to 3.0.1, delete the old CRD definitions with the following commands:

kubectl delete crd nsxlbmonitors.vmware.com

kubectl delete crd loadbalancers.vmware.com

n Set the enable_lb_crd and enable_vnet_crd options in the k8s section to True.

n Apply the Policy version of the NCP YAML file with the following command:

kubectl apply -f ncp-<platform>-policy.yaml

In Manager mode, to create a new NSX load balancer, apply a YAML file that defines a LoadBalancer CRD. For example,

apiVersion: vmware.com/v1alpha1

kind: LoadBalancer

metadata:

name: cluster1-lbs0

spec:

httpConfig: {}

In Policy mode, LoadBalancer needs to be created with VirtualNetwork. For example,


kind: VirtualNetwork

metadata:

name: vnet

---


kind: LoadBalancer

metadata:

name: cluster1-lbs0

spec:

virtualNetworkName: vnet # Set to match VirtualNetwork object name

httpConfig: {}

This YAML file will create an NSX load balancer of small size, and a pair of layer 7 virtual servers without persistence, SSL or X-forward settings. The IP of the virtual server is allocated from the configured default external pool for load balancers. The ports by default are 80 and 443. Non-standard ports are supported if the custom port is included in the HTTP HOST header. Note that custom ports are only supported in non-TLS Ingresses.


VMware, Inc. 82

To check the creation status of the LoadBalancer CRD, run the following command:

kubectl get lb <name of the LoadBalancer> -o yaml

The result looks something like the following:

status:

conditions:

- status: "True"

type: Ready

httpVirtualIP: <realized virtual IP>

This result indicates that the creation was successful. If the creation failed, status will be "False" and there will not be a virtual IP.

You can also customize settings for the NSX load balancer and virtual servers. To configure the IP and port for the virtual server:

spec:

httpConfig:

virtualIP: <ip address, default to auto-allocate>

port: <port number, default to 80>

To specify the session affinity and X-forwarded-mode:

spec:

httpConfig:

xForwardedFor: <INSERT or REPLACE, default to None>

affinity:

type: <source_ip or cookie, default to None>

timeout: <timeout number, default to 10800>

To configure TLS settings:

spec:

httpConfig:

tls:

port: <tls port number, default to 443>

secretName: <name of secret, default to None>

secretNamespace: <namespace of secret, default to None>

Note that even if you set the HTTP and HTTPS ports to non-default values, the Ingress printer will always display the default port values (80 and 443) when showing the Ingress status because of a Kubernetes limitation. You should still use the configured ports to access Ingress. For example,

curl -I -HHost:tea.example.com http://$INGRESS_IP:$CRD_LB_HTTP_PORT/tea


VMware, Inc. 83

You can create the secret before or after the creation of LoadBalancer. To update the certificate, remove the secretName and secretNamespace from the LoadBalancer spec first, update the data of the secret, then re-attach the same secret using the above configuration. Creating a new secret and updating the secretName and secretNamespace will also work. Note that sharing the same secret data between different CRD load balancers is not supported. You must configure CRD load balancers with different certificates.

To view the status and statistics of NSX load balancers, run the following command:

kubectl get lbm

This will list all the NSXLoadBlancerMonitors, one for each NSX load balancer. The following information is displayed:

n Usage - The number of workloads on the NSX load balancer.

n Traffic - The aggregated statistics of each Virtual Server.

n Health - This field has two dimensions:

n servicePressureIndex - This indicates the performance of the load balancer. Two values are provided: score and severity.

n infraPressureIndex - This indicates the performance of the underlying infrastructure components. In NCP 2.5.1, this value is not always accurate.

n The field metrics gives an idea of the parameters that are considered when the health score is calculated.

When the servicePressureIndex of a load balancer is HIGH, you can migrate the Ingress workload to other load balancers, which must be the default load balancer or load balancers created using the LoadBalancer CRD.

To place an Ingress on a dedicated load balancer, add an annotation to the Ingress specification. For example,

annotations:

nsx/loadbalancer: <name of the LoadBalancer CRD>

If the annotation is missing or set to null, the Ingress is placed on the default NSX load balancer.

Dienst vom Typ LoadBalancer

NCP erstellt für jeden Dienst-Port einen virtuellen Server und einen Pool des Load Balancers auf Schicht 4.

Details zu dieser Funktion:

n TCP und UDP werden unterstützt.

n Jeder Dienst hat eine eindeutige IP-Adresse.


VMware, Inc. 84

n Dem Dienst wird eine IP-Adresse aus einem externen IP-Pool zugeteilt, die auf dem Feld "loadBalancerIP" in der LoadBalancer-Definition basiert. Das Feld "loadBalancerIP" kann leer sein, eine IP-Adresse oder den Namen oder die ID eines IP-Pools enthalten. Wenn die Spezifikation loadBalancerIP leer ist, wird die IP-Adresse aus dem externen IP-Pool zugeteilt, der durch die external_ip_pools_lb-Option im Abschnitt [nsx_v3] in ncp.ini angegeben ist. Wenn die Option external_ip_pools_lb nicht vorhanden ist, wird der von external_ip_pools angegebene Pool verwendet. Der LoadBalancer-Dienst wird unter dieser IP-Adresse und auf dem Dienst-Port bereitgestellt.

n Sie können zu einem anderen IP-Pool wechseln, indem Sie die Konfiguration ändern und NCP neu starten.

n Der von loadBalancerIP angegebene-IP-Pool muss über das Tag scope: ncp/owner, tag: cluster:<cluster_name> verfügen.

n Beginnend mit NCP 3.0.2 im Richtlinienmodus wird ein Dienst des Typs LoadBalancer ohne Selektor unterstützt. Bei einem solchen Dienst wird die SNAT-IP des NSX-T Load Balancers die IP des Diensts des Typs LoadBalancer sein. Die SNAT-IP des NSX-T Load Balancers wird aktualisiert, wenn Sie die IP-Adresse des Diensts des Typs LoadBalancer aktualisieren.

n Fehler werden im Dienst als Anmerkung dokumentiert. Der Fehlerschlüssel lautet ncp/error.loadbalancer. Dies sind die möglichen Fehler:

n ncp/error.loadbalancer: IP_POOL_NOT_FOUND

Dieser Fehler weist darauf hin, dass Sie loadBalancerIP: <nsx-ip-pool> angeben, <nsx-ip-pool> aber nicht vorhanden ist. Der Dienst ist dann inaktiv. Um den Fehler zu beheben, geben Sie einen gültigen IP-Pool ein, löschen Sie den Dienst und erstellen Sie ihn neu.

n ncp/error.loadbalancer: IP_POOL_EXHAUSTED

Dieser Fehler weist darauf hin, dass Sie loadBalancerIP: <nsx-ip-pool> angeben, die IP-Adressen im IP-Pool aber ausgeschöpft sind. Der Dienst ist dann inaktiv. Um den Fehler zu beheben, geben Sie einen IP-Pool mit verfügbaren IP-Adressen an, löschen Sie den Dienst und erstellen Sie ihn neu.

n ncp/error.loadbalancer: IP_POOL_NOT_UNIQUE

Dieser Fehler weist darauf hin, dass mehrere IP-Pools den von loadBalancerIP angegebenen Namen aufweisen: <nsx-ip-pool>. Der Dienst ist dann inaktiv.

n ncp/error.loadbalancer: POOL_ACCESS_DENIED

Dieser Fehler weist darauf hin, dass der von loadBalancerIP angegebene IP-Pool das Tag scope: ncp/owner, tag: cluster:<cluster_name> nicht aufweist oder der Name des im Tag angegebenen Clusters nicht mit dem Namen des Kubernetes-Clusters übereinstimmt.

n ncp/error.loadbalancer: LB_VIP_CONFLICT

Dieser Fehler weist darauf hin, dass die IP im loadBalancerIP-Feld mit der IP eines aktiven Diensts identisch ist. Der Dienst ist dann inaktiv.


VMware, Inc. 85

n Der Schicht-4-Load Balancer unterstützt automatische Skalierung. Wenn ein Kubernetes-LoadBalancer-Dienst erstellt oder geändert wird, sodass er zusätzliche virtuelle Server erfordert, und der vorhandene Load Balancer auf Schicht 4 nicht über ausreichend Kapazität verfügt, wird ein neuer Load Balancer auf Schicht 4 erstellt. NCP löscht einen Load Balancer auf Schicht 4 auch, wenn keine virtuellen Server mehr an ihn angehängt sind. Diese Funktion ist standardmäßig aktiviert. Wenn Sie diese Funktion deaktivieren möchten, müssen Sie l4_lb_auto_scaling in der NCP-ConfigMap auf false festlegen.

Load Balancer und Netzwerkrichtlinie

Wenn Datenverkehr über den virtuellen Server des NSX-Load Balancer an die Pods weitergeleitet wird, handelt es sich bei der Quell-IP um die IP-Adresse des Uplink-Ports des Tier-1-Routers. Diese Adresse befindet sich im privaten Tier-1-Transit-Netzwerk und kann dazu führen, dass die CIDR-basierten Netzwerkrichtlinien zulässigen Datenverkehr nicht zulassen.

Zur Vermeidung dieses Problems muss die Netzwerkrichtlinie so konfiguriert werden, dass die IP-Adresse des Uplink-Ports des Tier-1-Routers Teil des zulässigen CIDR-Blocks ist. Diese interne IP-Adresse wird im Feld "status.loadbalancer.ingress.ip" und als Anmerkung (ncp/internal_ip_for_policy) auf der Ingress-Ressource angezeigt.

Lautet die externe IP-Adresse des virtuellen Servers beispielsweise 4.4.0.5 und die IP-Adresse des Uplink-Ports des internen Tier-1-Routers 100.64.224.11, sieht der Status folgendermaßen aus:

status:

loadBalancer:

ingress:

- ip: 4.4.0.5

- ip: 100.64.224.11

Die Anmerkung zum Ingress und zum Dienst vom Typ LoadBalancer lautet:

ncp/internal_ip_for_policy: 100.64.224.11

Die IP-Adresse 100.64.224.11 muss zur zulässigen CIDR im ipBlock-Selektor der Netzwerkrichtlinie gehören. Beispiel:

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

...

ingress:

- from:

- ipBlock:

cidr: 100.64.224.11/32


VMware, Inc. 86

Beispielskript zum Generieren eines von einer Zertifizierungsstelle signierten Zertifikats

Sie können ein Skript erstellen, das ein von einer Zertifizierungsstelle signiertes Zertifikat und einen privaten in den Dateien <Dateiname>.crt und <Dateiname>.key gespeicherten privaten Schlüssel generiert.

Der Befehl genrsa generiert einen Zertifizierungsstellen-Schlüssel. Der Zertifizierungsstellen-Schlüssel muss verschlüsselt werden. Sie können eine Verschlüsselungsmethode mit einem Befehl wie zum Beispiel aes256 angeben. Beispiel:

#!/bin/bash

host="www.example.com"

filename=server

openssl genrsa -out ca.key 4096

openssl req -key ca.key -new -x509 -days 365 -sha256 -extensions v3_ca -out ca.crt -subj "/C=US/ST=CA/

L=Palo Alto/O=OS3/OU=Eng/CN=${host}"

openssl req -out ${filename}.csr -new -newkey rsa:2048 -nodes -keyout ${filename}.key -subj "/C=US/

ST=CA/L=Palo Alto/O=OS3/OU=Eng/CN=${host}"

openssl x509 -req -days 360 -in ${filename}.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out $

{filename}.crt -sha256

Ingress-Controller von Drittanbietern

Sie können NCP für die Unterstützung von Ingress-Controllern von Drittanbietern konfigurieren.

Bearbeiten der Datei NCP.ini

Sie müssen die Konfigurationsdatei /var/vcap/data/jobs/ncp/xxxxxxxx/config/ncp.ini bearbeiten (wobei xxxxxxxx die BOSH-Bereitstellungs-ID ist). Diese Datei wird dann in rootfs kopiert und von NCP jedes Mal verwendet, wenn NCP neu gestartet wird. Diese Datei muss auf jedem Master-Knoten bearbeitet werden.

Wichtig Änderungen an ncp. ini sind bei PKS-Cluster-Aktualisierungen nicht persistent. Wenn Sie Änderungen über die PKS-Kachel vornehmen und dann die PKS-Bereitstellung aktualisieren, gehen die Änderungen an ncp. ini verloren.

Die relevanten Optionen befinden sich im Abschnitt nsx_v3.

n use_native_loadbalancer: Wenn dies auf False festgelegt ist, verarbeitet NCP unabhängig von den zugehörigen Anmerkungen keine Ingresses oder Dienste vom Typ LoadBalancer-Aktualisierungen. Diese Einstellung gilt für den gesamten PKS-Cluster. Die Standardeinstellung lautet True.


VMware, Inc. 87

n default_ingress_class_nsx: Wenn dies auf True festgelegt ist, wird NCP zum standardmäßigen Ingress-Controller und verarbeitet sowohl Dateneingänge mit der Anmerkung kubernetes.io/ingress.class: "nsx" als auch Dateneingänge ohne Anmerkung. Wenn der Wert auf False festgelegt ist, verarbeitet NCP nur Ingresses mit der Anmerkung kubernetes.io/ingress.class: "nsx". Die Standardeinstellung lautet True.

Wenn Sie möchten, dass NCP dem NGINX-Controller-Pod eine dynamische IP-Adresse zuweist und den Status von Ingresses mit der dynamischen IP-Adresse aktualisiert, führen Sie die folgenden Schritte aus:

n Legen Sie im Abschnitt k8s in ncp.ini den Wert ingress_mode=nat fest.

n Fügen Sie dem NGINX-Ingress-Controller-Pod die Anmerkung ncp/ingress-controller: "True" hinzu.

NCP aktualisiert den Status von Dateneingängen, die die Anmerkung kubernetes.io/ingress.class: "nginx" aufweisen, mit der dynamischen IP-Adresse des NGINX-Ingress-Controller-Pods. Wenn default_ingress_class_nsx=False festgelegt ist, aktualisiert NCP auch den Status von Dateneingängen ohne die Anmerkung kubernetes.io/ingress.class mit der dynamischen IP-Adresse des NGINX-Ingress-Controller-Pods.

Hinweis: Selbst wenn der NGINX-Ingress-Controller-Pod nicht über die Anmerkung ncp/ingress-controller: "True" verfügt, aktualisiert NCP den Status der oben erwähnten Dateneingänge auf loadBalancer: {}. Die Dateneingänge könnten dann in einer Schleife festgehalten werden, in der der NGINX-Controller den Ingress-Status auf loadBalancer: {ingress: [{ip: <IP>}]} aktualisiert und NCP den Ingress-Status auf loadBalancer: {} aktualisiert. Um diese Situation zu vermeiden, führen Sie die folgenden Schritte aus:

n Wenn der Ingress-Controller von https://github.com/kubernetes/ingress-nginx stammt,

n Ändern Sie ingress-class auf dem Ingress-Controller in einen anderen Wert als "nginx".

n Wenn ein Ingress mit der Anmerkung kubernetes.io/ingress-class: "nginx" vorhanden ist, ändern Sie die Anmerkung in einen anderen Wert.

n Weitere Informationen finden Sie unter https://kubernetes.github.io/ingress-nginx/user-guide/multiple-ingress.

n Wenn der Ingress-Controller von https://github.com/nginxinc/kubernetes-ingress stammt,

n Ändern Sie ingress-class auf dem Ingress-Controller in einen anderen Wert als "nginx".

n Wenn ein Ingress mit der Anmerkung kubernetes.io/ingress-class: "nginx" vorhanden ist, ändern Sie die Anmerkung in einen anderen Wert.

n Legen Sie use-ingress-class-only auf dem Ingress-Controller-Pod auf True fest. Dadurch wird verhindert, dass dieser Controller Ingresses ohne die Anmerkung kubernetes.io/ingress-class aktualisiert.

n Weitere Informationen finden Sie unter https://github.com/nginxinc/kubernetes-ingress/blob/master/docs/multiple-ingress-controllers.md.


VMware, Inc. 88

https://github.com/kubernetes/ingress-nginx

https://kubernetes.github.io/ingress-nginx/user-guide/multiple-ingress

https://kubernetes.github.io/ingress-nginx/user-guide/multiple-ingress

https://github.com/nginxinc/kubernetes-ingress

https://github.com/nginxinc/kubernetes-ingress/blob/master/docs/multiple-ingress-controllers.md

https://github.com/nginxinc/kubernetes-ingress/blob/master/docs/multiple-ingress-controllers.md

Für Ingress-Controller von Drittanbietern, die im NAT-Modus ausgeführt werden, können Sie die Parameter http_ingress_port und https_ingress_port im Abschnitt k8s bearbeiten, um benutzerdefinierte Ports für die für den Ingress-Controller exponierten NAT-Regeln festzulegen.

Szenario 1: NCP verarbeitet Dateneingänge, ist aber nicht der standardmäßige Ingress-Controller.

Befolgen Sie dieses Verfahren, damit NCP die Ingresses von nsx-Klassen verarbeiten kann.

1 Bearbeiten Sie den Abschnitt nsx_v3 in ncp.ini auf jedem Master-Knoten.

a Legen Sie default_ingress_class_nsx auf False fest.

b Lassen Sie use_native_loadbalancer auf True festgelegt. Dies ist der Standardwert.

2 Starten Sie NCP auf jedem Master-Knoten neu. Dies kann zu einem Master-Failover führen.

3 Fügen Sie allen Ingresses, die NCP verarbeiten soll, die Anmerkung kubernetes.io/ingress.class: "nsx" hinzu.

Szenario 2: NCP ist der standardmäßige Ingress-Controller.

Befolgen Sie dieses Verfahren:

1 Es ist nicht erforderlich, ncp.ini zu bearbeiten, sondern es muss sichergestellt werden, dass alle Ingresses mit Anmerkungen versehen sind.

2 Die von NCP zu verarbeitenden Dateneingänge sollten mit der Anmerkung kubernetes.io/ingress.class: "nsx" versehen werden.

Obwohl NCP Dateneingänge ohne die Anmerkung kubernetes.io/ingress.class verarbeitet, besteht die bewährte Vorgehensweise bei mehreren Ingress-Controllern darin, immer über die Anmerkung kubernetes.io/ingress.class zu verfügen und sich nicht auf das Verhalten des standardmäßigen Ingress-Controllers zu verlassen.

3 Dateneingänge, die von Drittanbieter-Ingress-Controllern verarbeitet werden, müssen als Anmerkung mit dem Wert versehen werden, der von diesen Ingress-Controllern benötigt wird.

Wichtig Sofern es nicht das Ziel ist, NGINX als standardmäßigen Ingress-Controller festzulegen, verwenden Sie nginx nicht als NGINX-Ingress-Controller, da NGINX dadurch zum standardmäßigen Ingress-Controller wird.

Szenario 3: NCP verarbeitet unabhängig von der Anmerkung keinen Ingress.

Befolgen Sie dieses Verfahren:

1 Bearbeiten Sie den Abschnitt nsx_v3 in ncp.ini auf jedem Master-Knoten.

a Legen Sie use_native_loadbalancer auf False fest. Der Wert default_ingress_class_nsx ist nun irrelevant.


VMware, Inc. 89

2 Starten Sie NCP auf jedem Master-Knoten neu. Dies kann zu einem Master-Failover führen.

Beachten Sie, dass NCP auch die Dienste vom Typ „LoadBalancer“ nicht verarbeitet.


VMware, Inc. 90

Upgrade von NCP 6Sie können NCP von Version 2.4.* oder 2.5.* auf 3.0.x aktualisieren.


n Upgrade von NCP in einer Kubernetes-Umgebung

n Upgrade von NCP in einer Pivotal Cloud Foundry(PCF)-Umgebung

Upgrade von NCP in einer Kubernetes-Umgebung

In diesem Abschnitt wird beschrieben, wie NCP von Version 2.5.* auf 3.0.x in einer Kubernetes-Umgebung aktualisiert wird.

1 Laden Sie die Installationsdateien herunter. Siehe Herunterladen der Protokolldateien.

2 Führen Sie die folgenden Befehle aus, um die ConfigMap und ncp.ini in Ihrer aktuellen Umgebung anzuzeigen:

kubectl describe configmap nsx-ncp-config -n nsx-system

kubectl describe configmap nsx-node-agent-config -n nsx-system

3 Bearbeiten Sie die NCP-YAML-Datei basierend auf Ihrer aktuellen Umgebung. Referenzen finden Sie unter Bearbeiten der NCP-YAML-Datei.

n Sie müssen ovs_uplink_port unter dem Abschnitt [nsx_node_agent] definieren.

n Ersetzen Sie alle Instanzen von image: nsx-ncp mit dem neuen NCP-Image-Namen.

n Wenn Sie geheime Kubernetes-Schlüssel zum Speichern von Zertifikaten für NCP verwenden, finden Sie weitere Informationen im Abschnitt „Aktualisieren der NCP-Bereitstellungsspezifikationen“ in Bearbeiten der NCP-YAML-Datei zum Mounten der geheimen Volumes.

4 Führen Sie den folgenden Befehl aus, um die Syntax der NCP-YAML-Datei zu überprüfen:

kubectl apply -f ncp-<platform_name>.yml --server-dry-run

VMware, Inc. 91

In der Antwort werden die Ressourcen aufgelistet, die erstellt oder aktualisiert werden sollen (wird in der Ausgabe als „konfiguriert“ angezeigt). Beispiel:

customresourcedefinition.apiextensions.k8s.io/nsxerrors.nsx.vmware.com created (server dry run)

customresourcedefinition.apiextensions.k8s.io/nsxlocks.nsx.vmware.com created (server dry run)

namespace/nsx-system unchanged (server dry run)

serviceaccount/ncp-svc-account unchanged (server dry run)

clusterrole.rbac.authorization.k8s.io/ncp-cluster-role configured (server dry run)

clusterrole.rbac.authorization.k8s.io/ncp-patch-role configured (server dry run)

clusterrolebinding.rbac.authorization.k8s.io/ncp-cluster-role-binding unchanged (server dry run)

clusterrolebinding.rbac.authorization.k8s.io/ncp-patch-role-binding unchanged (server dry run)

serviceaccount/nsx-node-agent-svc-account unchanged (server dry run)

clusterrole.rbac.authorization.k8s.io/nsx-node-agent-cluster-role configured (server dry run)

clusterrolebinding.rbac.authorization.k8s.io/nsx-node-agent-cluster-role-binding unchanged

(server dry run)

configmap/nsx-ncp-config configured (server dry run)

deployment.extensions/nsx-ncp configured (server dry run)

configmap/nsx-node-agent-config configured (server dry run)

daemonset.extensions/nsx-ncp-bootstrap configured (server dry run)

daemonset.extensions/nsx-node-agent configured (server dry run)

5 Führen Sie den folgenden Befehl aus, um alte NCP-Ressourcen zu löschen:

kubectl delete deployment nsx-ncp -n nsx-system

6 Führen Sie den folgenden Befehl aus, um zu überprüfen, ob alle alten NCP-Pods beendet wurden:

kubectl get pods -l component=nsx-ncp -n nsx-system

Es sollten keine Pods aufgelistet werden, wenn alle alten NCP-Pods beendet wurden. Warten Sie, bis alle Pods beendet sind, bevor Sie fortfahren.

7 Löschen Sie die alte Wahlsperre. Wechseln Sie in der NSX Manager-Webschnittstelle zur Seite „Suchen“ und führen Sie eine erweiterte Suche nach Ressourcen mit folgenden Tags durch:

Scope: ncp\/ha Tag: true

Scope: ncp\/cluster Tag: <name of the cluster in ncp.ini>

Es sollte mindestens eine SpoofGuard-Ressource angezeigt werden. Löschen Sie alle Tags auf diesen Ressourcen.

8 Führen Sie den folgenden Befehl zum Starten des Upgrades aus.

kubectl apply -f ncp-{platform_name}.yml

9 Führen Sie den folgenden Befehl aus, um den aktuellen Upgrade-Status zu überprüfen:

kubectl get pods -o wide -n nsx-system


VMware, Inc. 92

In der Ausgabe sollten neue Pods, die erstellt werden, und alte, die beendet werden, angezeigt werden. Nach einem erfolgreichen Upgrade sollte der Status aller Pods als Ausgeführt angezeigt werden.

Upgrade von NCP in einer Pivotal Cloud Foundry(PCF)-Umgebung

In diesem Abschnitt wird beschrieben, wie in einer Pivotal Cloud Foundry(PCF)-Umgebung ein Upgrade von NCP auf Version 3.0.x vorgenommen wird.

Verfahren

1 Führen Sie ein Upgrade der NCP- oder NSX-T-Kachel auf Version 3.0.x durch.

2 (Optional) Führen Sie ein Upgrade von Pivotal Operations Manager und anschließend von Pivotal Application Service durch.

3 (Optional) Führen Sie ein Upgrade von NSX-T Data Center auf 3.0 durch.

Wenn der Hypervisor ESXi ist, führen Sie vor dem Upgrade auf NSX-T Data Center ein Upgrade von ESXi von 6.5 auf mindestens 6.5p03 oder von 6.7 auf mindestens 6.7ep6 durch.

4 (Optional) Führen Sie ein Upgrade des Hypervisors durch (KVM oder Bare-Metal-Container).


VMware, Inc. 93

Importieren von Managerobjekten in den Richtlinienmodus 7NSX-T verfügt über zwei Methoden zum Konfigurieren von Netzwerken: den Managermodus und den Richtlinienmodus. Wenn Sie ein Upgrade von NCP durchführen, haben Sie die Möglichkeit, Managerobjekte in den Richtlinienmodus zu importieren. Sie können das Skript mp_to_policy_importer.py verwenden, das für den Import von Managerobjekten in den Richtlinienmodus bereitgestellt wird.

Diese Funktion wird unterstützt, wenn Sie über eine Kubernetes-Umgebung verfügen, jedoch keine Pivotal Cloud Foundry(PCF)- oder Pivotal Container Service(PKS)-Umgebung haben.


n Workflow zum Importieren von Managerobjekten in den Richtlinienmodus

n Importieren von gemeinsam genutzten Ressourcen

n Importieren eines Kubernetes-Clusters

n Grundlegendes zum Importvorgang

n Fehler und Wiederherstellung

n Benutzerdefinierte Ressourcen

n Einschränkungen und Problemumgehungen

n Reihenfolge der Ressourcenspezifikation

n Beispiel für config.yaml

n Beispiel für user-spec.yaml

Workflow zum Importieren von Managerobjekten in den Richtlinienmodus

Das Importieren eines Kubernetes-Clusters kann einige Zeit dauern. Dazu muss der Cluster gesperrt werden (es sind keine Vorgänge zum Erstellen, Aktualisieren oder Löschen zulässig). Es wird empfohlen, immer nur jeweils einen Cluster zu importieren, sodass Sie nicht alle Cluster gleichzeitig sperren müssen.

Bevor Sie den Importvorgang starten, müssen Sie eine Sicherung von NSX Manager durchführen. Dadurch wird gewährleistet, dass Sie im Falle eines nicht behebbaren Fehlers den Zustand von NSX Manager vor dem Import wiederherstellen können.

VMware, Inc. 94

Das Python3-Skript, das den Import durchführt, mp_to_policy_importer.py, befindet sich im Verzeichnis scripts/mp_to_policy_import. Sie müssen dieses Skript auf dem Kubernetes-Master-Knoten des Clusters ausführen.

Informationen zu Einschränkungen und Problemumgehungen finden Sie unter Einschränkungen und Problemumgehungen. Informationen zur Fehlerbehebung finden Sie unter Fehler und Wiederherstellung.

Der Workflow zum Importieren von Managerobjekten in den Richtlinienmodus:

1 Führen Sie ein Upgrade von NSX-T auf Version 3.0.0 oder höher durch.

2 Führen Sie ein Upgrade von NCP auf Version 3.0.1 durch.

3 Stellen Sie sicher, dass in der NCP-YAML-Datei policy_nsxapi auf false festgelegt ist.

4 Erstellen Sie eine Sicherung.

5 Importieren Sie gemeinsam genutzte Ressourcen. Siehe Importieren von gemeinsam genutzten Ressourcen.

6 Sperren Sie den Kubernetes-Cluster. Der Kubernetes-API-Server befindet sich im schreibgeschützten Modus. Führen Sie keine Vorgänge zum Erstellen, Aktualisieren oder Löschen in Kubernetes-Ressourcen durch. Warten Sie mindestens 10 Minuten, bevor Sie mit dem nächsten Schritt fortfahren.

7 Beenden Sie NCP.

8 Erstellen Sie eine Sicherung.

9 Importieren Sie den Kubernetes-Cluster. Siehe Importieren eines Kubernetes-Clusters.

10 Aktualisieren Sie ncp.ini, falls für diesen Cluster erforderlich. Siehe Importieren von gemeinsam genutzten Ressourcen.

11 Stellen Sie in der NCP-YAML-Datei sicher, dass policy_nsxapi auf true festgelegt ist, und starten Sie NCP.

12 Entsperren Sie den Cluster. Sie können jetzt Vorgänge zum Erstellen, Aktualisieren oder Löschen in Kubernetes-Ressourcen durchführen.

13 Wiederholen Sie die Schritte 4 bis 12 für den nächsten Cluster.

14 Ändern Sie die PKS-Automatisierung und die BOSH CPI, um die Richtlinien-API zu verwenden, sobald alle Cluster in der Bereitstellung importiert wurden.

Importieren von gemeinsam genutzten Ressourcen

Der erste Schritt beim Importieren von Managerobjekten in den Richtlinienmodus ist das Importieren von gemeinsam genutzten Ressourcen wie Routern, IP-Blöcken und -Pools, NsGroups usw.


VMware, Inc. 95

NCP im Richtlinienmodus akzeptiert nur die Richtlinien-ID von NSX-Ressourcen in seiner ncp.ini. Gemeinsam genutzte Ressourcen werden beim Importieren von Managerobjekten in den Richtlinienmodus mit einer Richtlinien-ID importiert, die wie folgt aus den Anzeigenamen abgeleitet wird:

n Jedes Leerzeichenliteral („ “) wird durch einen Unterstrich („_“) ersetzt.

n Jeder Schrägstrich („/“) wird durch einen Unterstrich („_“) ersetzt.

n Wenn der Anzeigename nur Punkte enthält (z. B. „.“, „.....“ usw.), wird ein Unterstrich („_“) vorangestellt.

Beispiele:

n „mp display name“ wird zur Richtlinien-ID „mp_display_name“.

n „mp display/name“ wird zur Richtlinien-ID „mp_display_name“.

n „.....“ wird zur Richtlinien-ID „_.....“

Sie müssen sicherstellen, dass alle NSX-Ressourcen, die Sie erstellt haben, eindeutige Anzeigenamen aufweisen.

Aktualisieren Sie bei Bedarf die Datei ncp.ini basierend auf den obigen Regeln, wenn die Konfiguration die ID der NSX-Ressource liest.

Bearbeiten der user-spec.yaml

Sie müssen user-spec.yaml bearbeiten, um anzugeben, welche Ressourcen importiert werden sollen. Sie können Folgendes angeben:

n Die Ressource, indem Sie entweder den Anzeigenamen oder die ID in der Manager-API verwenden. Wenn die Ressource in der Manager-API nicht gefunden wird, wird sie ignoriert.

n Die zu importierenden IP-Zuteilungen für einen beliebigen IP-Pool in user-spec.yaml unter „ip-allocations“. Zwei Szenarien:

a Mit benutzerdefinierten IpPoolAllocations aus diesem IpPool

Wenn Sie IP-Zuteilungen manuell erstellt haben, geben Sie diese hierunter an. Hierbei entspricht „key“ der Zuteilungs-ID der IP-Pool-Zuteilung und „value“ ist die erwartete Richtlinien-ID. Importieren Sie keine anderen Ressourcen wie IP-Blöcke, Tier-0-Router usw. zur gleichen Zeit. Nachdem die Zuteilungen importiert wurden, führen Sie das Skript erneut aus, um gemeinsam genutzte Ressourcen zu importieren, wie in Schritt 2 unten angegeben.

b Ohne benutzerdefinierte IP-Pool-Zuweisungen aus diesem IP-Pool (Standard)

Bearbeiten Sie die IP-Zuteilungen nicht und geben Sie auch keine IP-Zuteilungen für irgendeinen IP-Pool an. Fügen Sie jedoch alle anderen Ressourcen wie IP-Blöcke, Tier-0-Router usw. in der Spezifikation für den Import hinzu.

n Statische Routen und Routerports, die für einen Tier-1-Router importiert werden sollen.


VMware, Inc. 96

Ändern Sie nicht die Bezeichner „key“ und „value“ in der Spezifikation, sondern nur deren zugewiesene Werte. Die Angabe für „key“ ist die Manager-ID und „value“ entspricht der erwarteten Richtlinien-ID.

Unter Reihenfolge der Ressourcenspezifikation erfahren Sie, wie gemeinsam genutzte Ressourcen in user-spec.yaml angegeben werden sollten.

Schritte zum Importieren gemeinsamer Ressourcen

1 Geben Sie die entsprechenden Informationen in config.yaml ein und legen Sie import_shared_resources_only auf True fest. Siehe Beispiel für config.yaml.

2 Geben Sie die Informationen zu gemeinsam genutzten Ressourcen in user-spec.yaml ein. Siehe Beispiel für user-spec.yaml.

3 Führen Sie mp_to_policy_importer aus, indem Sie entweder die Konfigurationsdatei oder Befehlszeilenargumente verwenden. Beispiel:

python3 mp_to_policy_importer.py --config-file config.yaml

Importieren eines Kubernetes-Clusters

Nachdem Sie gemeinsam genutzte Ressourcen importiert haben, können Sie einen Kubernetes-Cluster importieren.

Bearbeiten der user-spec.yaml

Geben Sie in user-spec.yaml Folgendes an:

n Die ID des Top-Tier-Routers und den Typ des Clusters

n Alle benutzerdefinierten Ressourcen, die im Rahmen jedes Ressourcenimports importiert werden müssen. Beispielsweise können Sie die Manager-ID einer NAT-Regel angeben, die als Teil von Namespace-Ressourcen importiert werden soll. Weitere Informationen finden Sie unter Benutzerdefinierte Ressourcen. Sie müssen hier nichts tun, es sei denn, Sie haben manuell Einstellungen für die von NCP erstellten Ressourcen hinzugefügt. Beispiel: Sie haben eine statische Route für einen von NCP erstellten Tier-1-Router hinzugefügt.

n Manager-ID des LB-Diensts, die von Ihnen als lb-service-mp-id erstellt wird, um den standardmäßig verwendeten LB-Dienst in NCP zu importieren, sofern konfiguriert. Hierbei handelt es sich um dieselbe Ressource wie der LB-Dienst in der NCP-Spezifikation (ncp.ini). Wenn dies nicht verwendet wird, müssen Sie nichts angeben.

Schritte zum Importieren eines Kubernetes-Clusters

1 Geben Sie die entsprechenden Informationen in config.yaml ein und legen Sie import_shared_resources_only auf False fest. Siehe Beispiel für config.yaml.

2 Geben Sie die Informationen zum Kubernetes-Cluster in user-spec.yaml an. Siehe Beispiel für user-spec.yaml.


VMware, Inc. 97

3 Führen Sie mp_to_policy_importer aus, indem Sie entweder die Konfigurationsdatei oder Befehlszeilenargumente verwenden. Beispiel:

python3 mp_to_policy_importer.py --config-file config.yaml

Beachten Sie, dass nur der in config.yaml angegebene Kubernetes-Cluster importiert wird, auch wenn weitere Cluster in user-spec.yaml aufgeführt werden.

Grundlegendes zum Importvorgang

Der Importvorgang besteht aus vier Phasen.

Phase 1

Rufen Sie alle Ressourcen von der Manager-API ab. Filtern Sie die Ressourcen basierend auf dem Kubernetes-Cluster-Tag (ncp/cluster) oder den gemeinsam genutzten Ressourcen, die in user-spec.yaml angegeben sind. Beginnen Sie mit dem Erstellen von Anforderungstexten, die an den Migrationsserver gesendet werden. Falls keine Anforderung generiert werden kann, migriert NCP den Cluster nicht und wird beendet.

Erwartete Fehler und Lösungen:

n Ressourcen können aufgrund eines Konnektivitätsproblems nicht von der Manager-API abgerufen werden

Lösung: Versuchen Sie es nach der Behebung des Konnektivitätsproblems erneut.

n Kubernetes enthält keine Ressource, die von der Manager-API abgerufen wird

Lösung: Führen Sie NCP erneut im Managermodus aus, bis der Status „Leerlauf“ erreicht wird. Dies bedeutet, dass keine Vorgänge zum Erstellen, Lesen, Aktualisieren oder Löschen (CRUD, Create, Read, Update, Delete) durchgeführt werden. Sie sollten mindestens 10 Minuten warten, da dies das maximale Zeitintervall ist, bis NCP Wiederholungsanforderungen sendet. Wenn in den NCP-Protokollen keine Fehler aufgeführt werden, sollte das Problem behoben sein.

Phase 2

Beginnen Sie mit dem Versand der in Phase 1 erstellten Importanforderungen an die Migrations-API. Sobald eine Anforderung erfolgreich verarbeitet wurde, erfassen Sie die in der Anforderung enthaltenen Manager-IDs auf der lokalen Festplatte des Clients. Falls eine Anforderung fehlschlägt, müssen Sie eine Wiederherstellung der bereits importierten Ressourcen mithilfe der auf der lokalen Festplatte gespeicherten Manager-IDs durchführen. Wenn die Migrations-API mitteilt, dass es sich um eine doppelte Anforderung handelt, entfernt die Importfunktion die entsprechende Manager-ID aus dem Anforderungstext und sendet die Anforderung erneut.


n Konnektivitätsproblem



VMware, Inc. 98

n Migrations-API gibt einen Fehler zurück

Lösung: Versuchen Sie es nach einiger Zeit erneut, da es sich um einen Fehler der Richtlinien-API oder Migrations-API handeln kann. Wenn das Problem weiterhin besteht, führen Sie eine Wiederherstellung aller importierten Ressourcen durch, sobald die Importfunktion unerwartet beendet wird, indem Sie die Option rollback_imported_resources in config.yaml verwenden. Standardmäßig führt die Importfunktion eine Wiederherstellung durch, wenn ein Problem in dieser Phase auftritt. Wenn bei der Wiederherstellung jedoch ein Problem auftritt, müssen Sie es manuell erneut versuchen. Wenn die Wiederherstellung mit mp_to_policy_importer fehlschlägt, müssen Sie mithilfe einer Sicherung den Zustand wiederherstellen, den NSX Manager vor dem Import des Kubernetes-Clusters hatte.

Hinweis: Wenn DFW-Abschnitte und -Regeln importiert wurden und die Importanforderungen für Ressourcen danach fehlschlagen, müssen Sie den Zustand des Managers mithilfe der erstellten Sicherung wiederherstellen, bevor Sie den Cluster-Import erneut einleiten.

Phase 3

Leiten Sie die Tags, die den Ressourcen im Richtlinienmodus hinzugefügt bzw. aus ihnen entfernt werden müssen, für alle importierten Ressourcen ab. Falls ein Tag nicht abgeleitet werden kann (Grund: Es könnte die entsprechende Kubernetes-Ressource fehlen), führt die Importfunktion eine Wiederherstellung der bereits importierten Ressourcen mithilfe der auf der lokalen Festplatte gespeicherten Manager-IDs aus. Dies kann passieren, wenn NCP im Managermodus mitten in der Transaktion angehalten wurde. Daher sollten Sie NCP in diesen Fällen erneut im Managermodus starten und eine Weile warten.


n Kubernetes enthält keine Ressource, die von der Manager-API abgerufen wird

Lösung: Führen Sie nach der Wiederherstellung NCP erneut im Managermodus aus, bis der Status „Leerlauf“ erreicht wird. Sie sollten mindestens 10 Minuten warten, da dies das maximale Zeitintervall ist, bis NCP Wiederholungsanforderungen sendet. Wenn in den NCP-Protokollen keine Fehler aufgeführt werden, sollte das Problem behoben sein.

Phase 4

Dies ist die wichtigste Phase. Es wird dringend empfohlen, darauf zu achten, dass in dieser Phase kein unerwarteter Fehler auftritt. In dieser Phase aktualisiert die Importfunktion die Ressourcen im Richtlinienmodus mit neuen Tags und/oder zusätzlichen Informationen (Die Importfunktion aktualisiert beispielsweise den Anzeigenamen von Segmenten). Wenn die Ressource zu diesem Zeitpunkt nicht aktualisiert werden kann, speichert die Importfunktion den aktualisierten Richtlinienressourcentext und die Richtlinienressourcen-URL auf der lokalen Festplatte des Clients und fordert Sie auf, es erneut zu versuchen, nachdem Sie das Problem behoben haben (es handelt sich um ein Problem der Richtlinien-API oder ein Konnektivitätsproblem).


n Konnektivitätsproblem


VMware, Inc. 99


In allen vier Phasen besteht auch die Gefahr, dass ein unerwarteter Stromausfall und andere Probleme auftreten, die wie unter Fehler und Wiederherstellung beschrieben behandelt werden.

Fehler und Wiederherstellung

Möglicherweise kann der Importvorgang nicht abgeschlossen werden, da ein externes Problem auftritt, wie z. B. ein Stromausfall, unzureichender Festplattenspeicher, Konnektivitätsprobleme usw. In solchen Szenarien gibt es Möglichkeiten zur Wiederherstellung.

Wenn der Fehler in Phase 1, 2 oder 3 auftritt, können Sie in config.yaml die Option rollback_imported_resources manuell auf True festlegen und das Skript erneut ausführen. Dadurch wird eine Wiederherstellung für alle importierten Ressourcen durchgeführt. Wenn Sie das Flag nicht auf True festlegen, versucht NCP erneut, den Vorgang auszuführen, und setzt den Import der Ressourcen fort. Standardmäßig ist rollback_imported_resources auf False festgelegt.

Wenn der Fehler in Phase 4 auftritt, führen Sie mp_to_policy_importer erneut aus. NCP versucht, die zwischengespeicherten aktualisierten Ressourcentexte des Richtlinienmodus auf den NSX Manager weiterzugeben. Wenn ein Fehler aufgetreten ist und die Informationen nicht zwischengespeichert wurden, müssen Sie eine Wiederherstellung mit der Sicherungs- und Wiederherstellungsfunktion zur Wiederherstellung des Clusters durchführen. Das liegt daran, dass alle Tags verloren gehen, wenn die Tags für den Richtlinienmodus aktualisiert wurden und eine Wiederherstellung für die Ressourcen durchgeführt wird.

Wiederherstellung des Imports von Managerobjekten in den Richtlinienmodus

Der Prozess mp_to_policy_importer speichert die ID der Ressourcen auf der lokalen Festplatte des Clients, wenn sie erfolgreich importiert wurden. Wenn beim Ausführen der Importfunktion ein Fehler auftritt, wird eine Wiederherstellung für alle importierten Ressourcen durchgeführt und die Ressourcen werden aus dem Dateisystem gelöscht, sofern die Wiederherstellung erfolgreich ist. Wenn jedoch bei der Wiederherstellung ein Fehler auftritt, können Sie in config.yaml den Parameter rollback_imported_resources auf True festlegen, um den Vorgang manuell zu wiederholen, und eine Wiederherstellung für die importierten Ressourcen durchführen, indem Sie mp_to_policy_importer erneut ausführen. Die Importfunktion erkennt anhand der Protokolle, ob alle Ressourcen erfolgreich zurückgesetzt wurden. Wenn die Wiederherstellung mithilfe des Skripts fehlschlägt, verwenden Sie die Sicherungs- und Wiederherstellungsfunktion, um den Cluster im ursprünglichen Zustand wiederherzustellen.

Benutzerdefinierte Ressourcen

Sie können benutzerdefinierte Ressourcen importieren, die standardmäßig nicht zusammen mit einem Cluster importiert werden.


VMware, Inc. 100

Die benutzerdefinierten Ressourcen werden nicht von NCP erstellt. Die Datei nsxt_mp_to_policy_converter.py enthält Methoden (Suchen Sie nach dem Wort „custom“ in den Methodendefinitionen), die außer Kraft gesetzt werden können, um das Verhalten zu implementieren, das während des Imports von Managerobjekten in den Richtlinienmodus erwartet wird. Standardmäßig führt NCP keine Aktionen für diese Ressourcen aus. Daher wird kein benutzerdefiniertes Verhalten implementiert. Wenn Sie eine benutzerdefinierte Ressourcen-ID angeben, wird eine einfache Anforderung zum Importieren erstellt (die Richtlinien-ID wird in diesem Fall von display_name abgeleitet und in Phase 2 und 3 werden keine Aktualisierungen durchgeführt). Sie können die IDs dieser Ressourcen in der Benutzerspezifikationsdatei angeben (siehe Beispiel unten), indem Sie den Bezeichner custom_resources verwenden. Die entsprechende Syntax lautet wie folgt:

k8s-clusters:

<k8s cluster name>:

<NSX Resource Shell Class Name>:

<NSX Resource - 1 Class Name>:

custom_resources:

<NSX Resource - 1A ID>:

metadata:

- "key": <metadata key recognized by Migration API>

"value": <metadata value associated with the key recognized by

Migration API>

linked_ids:

- "key": <linked_ids key recognized by Migration API>

"value": <linked_ids value associated with the key recognized by

Migration API>

<NSX Resource - 2 Class Name>: # these resources are imported after NSX Resource - 1A is

custom_resources:

<NSX Resource - 2A ID>:

metadata:


"value": <metadata value associated with the key

recognized by Migration API>

linked_ids:


"value": <linked_ids value associated with the key

recognized by Migration API> <NSX Resource - 1 Class Name>:

<NSX Resource - 1B ID>:

metadata:


"value": <metadata value associated with the key recognized by

Migration API>

linked_ids:


"value": <linked_ids value associated with the key recognized by

Migration API>


VMware, Inc. 101

Beispiel für das Angeben von benutzerdefinierten Ressourcen in user-spec.yaml

k8s-clusters:

k8scluster:

# top-tier-router-id is required for each cluster

top-tier-router-id: t1-router-id

top-tier-router-type: TIER1

# Provide custom resources as follow:

NamespaceResources:

Tier1Router:

custom_resources:

# Custom resources are specified only with MP ID

6d93a932-87ea-42de-a30c-b39f397322b0:

metadata:

# It should be a list

- key: 'metadata-key'

value: 'metadata-value'

linked_ids:


- key: 'linked_id-key'

value: 'linked_id-value'

NATRules:

custom_resources:


536870924:

metadata:




linked_ids:




Unter Reihenfolge der Ressourcenspezifikation erfahren Sie, wie benutzerdefinierte Ressourcen in user-spec.yaml angegeben werden sollten.

Einschränkungen und Problemumgehungen

Für den Importvorgang gelten bestimmte Einschränkungen. Für einige von ihnen sind Problemumgehungen vorhanden.

n (Nur NCP 3.0.1) IpPoolAllocations von externen IpPools (vom Benutzer erstellte IpPools) werden nicht gelöscht, wenn die zugeordneten Kubernetes-Ressourcen gelöscht werden, sobald NCP nach dem Import im Richtlinienmodus ausgeführt wird. Beispielsweise nach dem Löschen eines Namespace.

Problemumgehung: Keine


VMware, Inc. 102

n Die Funktion zum Importieren von Managerobjekten in den Richtlinienmodus kann keine vollständige Wiederherstellung ausführen, sobald die Abschnitte und Regeln der verteilten Firewall in Phase 2 importiert wurden.

Problemumgehung: In diesem Fall müssen Sie die Sicherungs- und Wiederherstellungsfunktion verwenden, um die ursprüngliche Konfiguration des Clusters im Manager wiederherzustellen.

n (Nur NCP 3.0.1) Der Import von Managerobjekten in den Richtlinienmodus schlägt fehl, wenn eine NAT-Regel mit mehreren Zielports vorhanden ist. Ein solcher Fall tritt ein, wenn der Kubernetes-Parameter ingress_mode auf nat festgelegt ist und ein Pod mit der Anmerkung ncp/ingress-controller vorhanden ist.

Problemumgehung: Während NCP nicht ausgeführt wird und bevor der Import initiiert wird, bearbeiten Sie die NAT-Regel und entfernen Sie die Zielports "80" und "443".

n (Nur NCP 3.0.1) Automatisch skalierte Load Balancer-Tier-1s können von NCP im Richtlinienmodus nach dem Import nicht gelöscht werden, wenn dies benötigt wird.

Problemumgehung: Löschen Sie den Tier-1 manuell über die Benutzeroberfläche, falls erforderlich.

n Cluster mit einer Lastausgleichsdienst-CRD können nicht importiert werden. Die Lastausgleichsdienst-CRD weist unterschiedliche Spezifikationen im Manager- und im Richtlinienmodus auf und kann nicht transformiert werden. Aus diesem Grund darf keine LB-CRD in Kubernetes vorhanden sein, wenn der Import initiiert wird.

Problemumgehung: Keine

Reihenfolge der Ressourcenspezifikation

Im Folgenden finden Sie eine Liste der Ressourcennamen für die Angabe von gemeinsam genutzten und benutzerdefinierten Ressourcen in user-spec.yaml.

SharedResources

- IpBlock

- IpPool

- IpPoolAllocation (specified as ip-allocations; see the sample user-spec.yaml for an example)

- Tier0Router

- Tier0RouterPorts (cannot be specified in user-spec.yaml)

- Tier0RouterConfig (cannot be specified in user-spec.yaml)

- Tier1Router

- Tier1RouterPortsAndStaticRoutes

- SpoofguradProfile

- NodeLogicalSwitch

- NsGroup

- IpSet

- FirewallSectionsAndRules

- Certificate

ClusterResources

- LogicalPort


VMware, Inc. 103

- Tier1Router


NamespaceResources

- IpBlockSubnet

- IpPoolAllocation

- Tier1Router

- Tier1RouterPorts

- NATRules

- SpoofguradProfile

- NodeLogicalSwitch

- NsGroup

PodResources

- LogicalPort

- NATRules

NetworkPolicyResources

- IpSet

- FirewallSectionsAndRules

SecretResources

- Certificate

LBClusterWideResources

- IpPool

- IpPoolAllocation

- NodeLogicalSwitch

- Tier1Router


- Certificate

- ServerPool

- CookiePersistenceProfile

- SourceIPPersistenceProfile

- ApplicationProfile

- VirtualServer

L4ServiceResources

- SourceIPPersistenceProfile

- VirtualServer

- LBService

Beispiel für config.yaml

Sie können das folgende Beispiel für config.yaml als Referenz verwenden.

# NSX Manager IP address

mgr_ip: null

# NSX Manager username, ignored if nsx_api_cert_file is set

username: "username"

# NSX Manager password, ignored if nsx_api_cert_file is set


VMware, Inc. 104

password: "password"

# Principal Identity used to import the NSX resource

principal_identity: "admin"

# Path to NSX client certificate file. If specified, the username and

# password options will be ignored. Must be specified along with

# nsx_api_private_key_file option

# nsx_api_cert_file: /root/nsx-ujo/sample_scripts/com.vmware.nsx.ncp/nsx.crt

# Path to NSX client private key file. If specified, the username and

# password options will be ignored. Must be specified along with

# nsx_api_cert_file option

# nsx_api_private_key_file: /root/nsx-ujo/sample_scripts/com.vmware.nsx.ncp/nsx.key

# Specify one or a list of CA bundle files to use in verifying the NSX

# Manager server certificate. This option is ignored if "allow_insecure"

# is set to True. If "allow_insecure" is set to False and ca_file

# is unset, the system root CAs will be used to verify the server

# certificate

# ca_file: None

# Import only the shared resources

# To import a cluster, this flag must be set to False

import_shared_resources_only: True

# If true, all the imported MP to Policy resources will be rollbacked

# Default=False

rollback_imported_resources: False

# Name of the Kubernetes clusters to be imported, optional.

# Can be specified to import only specific K8s clusters from the

# ones specified under user-spec.yaml

# If not specified, all the clusters will be imported

k8s_cluster_names:

- k8scluster

# Name of the directory that records the IDs of resources

# that are successfully imported

# Default=successfull_records

# records_dir_name: successfull_records

# Path where the records of successfully imported resources are

# saved. You can use this in conjunction with records_dir_name

# By default, we use the current working directory

# records_dir_base_path: None

# YAML config file that stores the information of resources

# to be imported

user_spec_file: "/root/nsx-ujo/sample_scripts/mp_to_policy_import/user-spec.yaml"

# Disable urllib's insecure request warning

# Default=False

no_warning: False


VMware, Inc. 105

# If true, the NSX Manager server certificate is not verified. If false the

# CA bundle specified via "ca_file" will be used or if unset the default

# system root CAs will be used

# Default=False

allow_insecure: False

# Enable the debug logs

# Default=False

enable_debug_logs: False

# Do not print the logs on the console.

# Can be used with logging enabled to a file.

# Default=False

# disable_console_logs: False

# Output the logs to this file.

# Default=/var/log/nsx-ujo/mp_to_policy_import.log

# log_file: /var/log/nsx-ujo/mp_to_policy_import.log

Beispiel für user-spec.yaml

Sie können das folgende Beispiel für user-spec.yaml als Referenz verwenden.

Für NCP 3.0.1:

SharedResources:

# IMPORTANT: If there are multiple resources with the same

# display_name, please make the display_names unique before

# initiating the import

IpPool:

resources:

# Specify the resources to import here with their UUID or

# display_name

k8s-snat-pool:

# Duplicate MP to Policy imports allowed for ip-allocations

# ip-allocations:

# - key: "172.24.4.4"

# value: "ip-alloc-1"

k8s-lb-pool:

IpBlock:

resources:

k8s-container-block:

IpSet:

resources:

vs-ipset-1:

Tier0Router:

resources:

node-t0:

Tier1Router:

resources:

# NOTE: If a Tier1 router is a top-tier router, it should not be imported

# as a shared resource

node-lr:

is-any-cluster-top-tier: False # required attribute


VMware, Inc. 106

Tier1RouterPortsAndStaticRoutes:

resources:

# NOTE: If a Tier1 router is a top-tier router for any cluster,

# it should not be imported as a shared resource

node-lr:


# static_routes_import_info:

# - key: "a4b04674-feb9-4418-8d5f-ac8bca4665eb"

# value: st-r-1

# router_ports_import_info:

# - key: "s2f24456-feb9-4418-8d5f-ar8aqa4665vf"

# value: rp-1

NsGroup:

# resources:

# test-ns-group:

# domain: my-domain

SpoofguradProfile:

resources:

nsx-default-spoof-guard-vif-profile:

NodeLogicalSwitch:

resources:

node-ls:

FirewallSectionsAndRules:

resources:

# Make sure to write the DFW Section and Rules in the order

# in which they should be imported. Otherwise there might be a

# moment in which the section that is present at lower priority

# is imported before section that is present above it making the

# traffic flow inconsistent. The best way to do it is to mention

# the Sections and Rules with increasing |priority| number. Note

# that lower priority numbers are present at the top in the Section

# and Rules order in NSX

fw-section-1:

section_info:

# category is a Security Policy attribute

category: "Application"

# You can specify either priority or bool is_top_section.

# If is_top_section is True, priority is auto-assigned to 5

# If is_top_section is False, priority is auto-assigned to 95

# If is_top_section and priority are specified, priority is used

# If both are not specified, error is thrown

is_top_section: True

# priority: 1

# domain is a Security Policy attribute

domain: "my-domain"

rules_info:

- name: "rule-name" # name or id must be specified

priority: 1 # optional. If not specified, FW Rule priority will be

# used as sequence number of Policy Rule

- id: 'rule-id' # name or id must be specified

Certificate:

resources:

my-cert:

k8s-clusters:

k8scluster:


VMware, Inc. 107

# top-tier-router-id (MP) is required for each cluster

top-tier-router-id: null

# top-tier-router-type is required for each cluster

# choices: TIER0 or TIER1


# lb-service-mp-id is the same as lb_service in ncp.ini config file

lb-service-mp-id: null # optional

# NamespaceResources:

# Tier1Router:

# custom_resources:

# 6d93a932-87ea-42de-a30c-b39f397322b0:

k8scluster-2:





NamespaceResources:

Tier1Router:

custom_resources:


6d93a932-87ea-42de-a30c-b39f397322b0:

metadata:




linked_ids:




Für NCP 3.0.2:

SharedResources:

# IMPORTANT: If there are multiple resources with the same

# display_name, please make the display_names unique before

# initiating the import

IpPool:

resources:

# Specify the resources to import here with their UUID or

# display_name

k8s-snat-pool:

# Duplicate MP to Policy imports allowed for ip-allocations

# ip-allocations:

# - key: "172.24.4.4"

# value: "ip-alloc-1"

k8s-lb-pool:

IpBlock:

resources:

k8s-container-block:

IpSet:

resources:

vs-ipset-1:

Tier0Router:

resources:

node-t0:


VMware, Inc. 108

Tier1Router:

resources:

# NOTE: If a Tier1 router is a top-tier router, it should not be imported

# as a shared resource

node-lr:


Tier1RouterPortsAndStaticRoutes:

resources:

# NOTE: If a Tier1 router is a top-tier router for any cluster,

# it should not be imported as a shared resource

node-lr:


# static_routes_import_info:

# - key: "a4b04674-feb9-4418-8d5f-ac8bca4665eb"

# value: st-r-1

# router_ports_import_info:

# - key: "s2f24456-feb9-4418-8d5f-ar8aqa4665vf"

# value: rp-1

NsGroup:

# resources:

# test-ns-group:

# domain: my-domain

SpoofguradProfile:

resources:

nsx-default-spoof-guard-vif-profile:

NodeLogicalSwitch:

resources:

node-ls:

FirewallSectionsAndRules:

resources:

# Make sure to write the DFW Section and Rules in the order

# in which they should be imported. Otherwise there might be a

# moment in which the section that is present at lower priority

# is imported before section that is present above it making the

# traffic flow inconsistent. The best way to do it is to mention

# the Sections and Rules with increasing |priority| number. Note

# that lower priority numbers are present at the top in the Section

# and Rules order in NSX

fw-section-1:

section_info:

# category is a Security Policy attribute

category: "Application"

# You can specify either priority or bool is_top_section.

# If is_top_section is True, priority is auto-assigned to 5

# If is_top_section is False, priority is auto-assigned to 95

# If is_top_section and priority are specified, priority is used

# If both are not specified, error is thrown

is_top_section: True

# priority: 1

# domain is a Security Policy attribute

domain: "my-domain"

rules_info:

- name: "rule-name" # name or id must be specified

priority: 1 # optional. If not specified, FW Rule priority will be

# used as sequence number of Policy Rule


VMware, Inc. 109

- id: 'rule-id' # name or id must be specified

Certificate:

resources:

my-cert:

k8s-clusters:

k8scluster:



# top-tier-router-type is required for each cluster

# choices: TIER0 or TIER1




external-ip-pools-lb-mp-id: [] # required. leave empty, [], if not used

external-ip-pools-mp-id: [] # required. leave empty, [], if not used

http-and-https-ingress-ip: null

# NamespaceResources:

# Tier1Router:

# custom_resources:

# 6d93a932-87ea-42de-a30c-b39f397322b0:

k8scluster-2:






external-ip-pools-lb-mp-id: [] # required. leave empty, [], if not used

external-ip-pools-mp-id: [] # required. leave empty, [], if not used

http-and-https-ingress-ip: null


NamespaceResources:

Tier1Router:

custom_resources:


6d93a932-87ea-42de-a30c-b39f397322b0:

metadata:




linked_ids:





VMware, Inc. 110

Verwalten von NSX Container Plug-in 8Sie können NSX Container Plug-in über die NSX Manager-GUI oder über die Befehlszeilenschnittstelle (Command Line Interface, CLI) verwalten.

Hinweis Wenn eine Container-Host-VM auf ESXi 6.5 ausgeführt wird und die VM über vMotion auf einen anderen ESXi 6.5-Host migriert wird, geht die Verbindung von Containern, die auf dem Container-Host ausgeführt werden, mit Containern, die auf anderen Container-Hosts ausgeführt werden, verloren. Sie können das Problem lösen, indem Sie die vNIC des Container-Hosts trennen und erneut verbinden. Dieses Problem tritt bei ESXi 6.5 Update 1 oder höher nicht auf.

Hyperbus reserviert die VLAN-ID 4094 auf dem Hypervisor für die PVLAN-Konfiguration, und die ID kann nicht geändert werden. Um VLAN-Konflikte zu vermeiden, konfigurieren Sie logische VLAN-Switches oder VTEP-vmknics mit derselben VLAN-ID.


n Anzeigen von in der Kubernetes-Ressource NSXError gespeicherten Fehlerinformationen

n Bereinigen der NSX-T-Umgebung

n Ändern des Cluster-Namens eines laufenden Clusters

n CLI-Befehle

n Fehlercodes

Anzeigen von in der Kubernetes-Ressource NSXError gespeicherten Fehlerinformationen

Für jedes Kubernetes-Ressourcenobjekt, das NSX-Backend-Fehler aufweist, wird ein NSXError-Objekt mit Fehlerinformationen erstellt. Es gibt auch ein Fehlerobjekt für alle den gesamten Cluster betreffenden Fehler.

VMware, Inc. 111

Diese Funktion ist standardmäßig nicht aktiviert. Um sie zu aktivieren, müssen Sie beim Installieren von NCP in ncp.ini enable_nsx_err_crd auf True festlegen.

Hinweis NSXError-Objekte dürfen nicht erstellt, aktualisiert oder gelöscht werden.

Wenn Sie NCP im Richtlinienmodus starten (mit der Option policy_nsxapi=true in der NCP-YAML-Datei), wird die NSXError-Ressource nicht unterstützt.

Befehle zum Anzeigen von NSXError-Objekten:

n kubectl get nsxerrors

Listet alle NSXError-Objekte auf.

n kubectl get nsxerrors -l error-object-type=<type of resource>

Listet alle mit einem bestimmten Typ von Kubernetes-Objekten verbundene NSXError-Objekte auf, beispielsweise Objekte des Typs services.

n kubectl get nsxerrors <nsxerror name> -o yaml

Zeigt die Details eines NSXError-Objekts an.

n kubectl get svc <service name> -o yaml | grep nsxerror

Findet den mit einem bestimmten Dienst verknüpften NSXError.

Wenn Sie die Details eines NSXError-Objekts anzeigen, enthält der Abschnitt mit der Spezifikation die folgenden wichtigen Informationen. Beispiel:

error-object-id: default.svc-1

error-object-name: svc-1

error-object-ns: default

error-object-type: services

message:

- '[2019-01-21 20:25:36]23705: Number of pool members requested exceed LoadBalancerlimit'

In diesem Beispiel lautet der Namespace default. Der Name des Diensts lautet svc-1. Der Typ der Kubernetes-Ressource lautet services.

In dieser Version werden die folgenden Fehler vom NSXError-Objekt unterstützt.

n Aufgrund eines NSX Edge-Grenzwerts konnte die automatische Skalierung keine zusätzlichen Load Balancer zuteilen.

n Die Anzahl der virtuellen Load Balancer-Server überschreitet den Grenzwert (automatische Skalierung ist nicht aktiviert).

n Die Anzahl der Load Balancer-Serverpools überschreitet den Grenzwert.

n Die Anzahl der Load Balancer-Serverpoolmitglieder überschreitet den Load Balancer- oder NSX Edge-Grenzwert.

n Beim Verarbeiten eines Diensts des Typs LoadBalancer sind die Floating-IP-Adressen ausgeschöpft.


VMware, Inc. 112

Bereinigen der NSX-T-Umgebung

Falls erforderlich, können Sie ein Skript ausführen, um alle NSX-T, die von NCP erstellt wurden, zu entfernen.

Die Installationsdateien enthalten die folgenden Bereinigungsskripts:

n nsx_policy_cleanup.py – Verwenden Sie dieses Skript, wenn NSX-T-Ressourcen im Richtlinienmodus erstellt werden.

n nsx_cleanup.py – Verwenden Sie dieses Skript, wenn NSX-T-Ressourcen mit dem Managermodus erstellt werden.

Bevor Sie das Skript ausführen, müssen Sie NCP beenden.

Richtlinienmodus

Usage: nsx_policy_cleanup.py [options]

Options:

-h, --help show this help message and exit

--mgr-ip=MGR_IP NSX Manager IP address

-u USERNAME, --username=USERNAME

NSX Manager username, ignored if nsx-cert is set

-p PASSWORD, --password=PASSWORD

NSX Manager password, ignored if nsx-cert is set

-n NSX_CERT, --nsx-cert=NSX_CERT

NSX certificate path

-k KEY, --key=KEY NSX client private key path

--vc-endpoint=VC_ENDPOINT

IpAddress or Hostname of VC, ignored if environment

variable VC_ENDPOINT is set

--vc-username=VC_USERNAME

Username for the VC ServiceAccount, ignored if

environment variable VC_USERNAME is set

--vc-password=VC_PASSWORD

Password for the VC ServiceAccount, ignored if

environment variable VC_PASSWORD is set

--vc-https-port=VC_HTTPS_PORT

HTTPS port of VC, ignored if environment variable

VC_HTTPS_PORT is set. If not present, 443 default

value will be used

--vc-sso-domain=VC_SSO_DOMAIN

SSO Domain of VC, ignored if environment variable

VC_SSO_DOMAIN is set. If not present, local default

value will be used

--vc-ca-cert=VC_CA_CERT

Specify a CA bundle to verify the VC server

certificate. It will be ignored if environment

VC_CA_CERT is set

--vc-insecure Not verify VC server certificate

-c CLUSTER, --cluster=CLUSTER

Cluster to be removed

-r, --remove CAVEAT: Removes NSX resources. If not set will do dry-


VMware, Inc. 113

run.

--top-tier-router-id=TOP_TIER_ROUTER_ID

Specify the top tier router id. Must be specified if

top tier router does not have the cluster tag

--all-res Also clean up HA switching profile, ipblock, external

ippool. These resources could be created by PAS NSX-T

Tile

--no-warning Disable urllib's insecure request warning

--status Check the deletion status, the exit code can be

success(0), in progress(EXIT_CODE_IN_PROGRESS or

failure(other non-zerovalues)

--thumbprint=THUMBPRINT

Specify one or a list of thumbprint strings to use in

verifying the NSX Manager server certificate

Beispiel:

python nsx_policy_cleanup.py --mgr-ip={nsx_mngr_ip} -u admin -p {password} -c {k8s_cluster_name} --no-

warning -r

In einigen Fällen muss der top-tier-router-id-Parameter angegeben werden.

Managermodus

Usage: nsx_cleanup.py [options]

Options:

-h, --help show this help message and exit

--mgr-ip=MGR_IP NSX Manager IP address

-u USERNAME, --username=USERNAME

NSX Manager username, ignored if nsx-cert is set

-p PASSWORD, --password=PASSWORD

NSX Manager password, ignored if nsx-cert is set

-n NSX_CERT, --nsx-cert=NSX_CERT

NSX certificate path

-k KEY, --key=KEY NSX client private key path

-c CLUSTER, --cluster=CLUSTER

Cluster to be removed

-r, --remove CAVEAT: Removes NSX resources. If not set will do dry-

run.

--top-tier-router-uuid=TOP_TIER_ROUTER_UUID

Specify the top tier router uuid. Must be specified if

top tier router does not have the cluster tag or for a

single-tier1 topology

--all-res Also clean up HA switching profile, ipblock, external

ippool. These resources could be created by PAS NSX-T

Tile

--no-warning Disable urllib's insecure request warning

Beispiel:

python nsx_cleanup.py --mgr-ip={nsx_mngr_ip} -u admin -p {password} -c {k8s_cluster_name} --top-tier-

router-uuid={top_tier_router_uuid} --no-warning -r


VMware, Inc. 114

Ändern des Cluster-Namens eines laufenden Clusters

Das Ändern des Namens eines laufenden Clusters wird nicht empfohlen. Wenn Sie dies tun müssen, gehen Sie folgendermaßen vor.

1 Beenden Sie NCP.

2 Laden Sie das Bereinigungsskript herunter, um NSX-T-Ressourcen zu löschen.

Laden Sie für Ressourcen, die mit dem Managermodus erstellt wurden, nsx_cleanup.py herunter. Für Ressourcen, die mit dem Richtlinienmodus erstellt wurden, laden Sie nsx_policy_cleanup.py herunter.

3 Führen Sie das Bereinigungsskript aus.

4 Starten Sie NCP mit dem neuen Cluster-Namen.

5 Erstellen Sie die Pods neu.

CLI-Befehle

Um CLI-Befehle auszuführen, melden Sie sich beim NSX Container Plug-in-Container an, öffnen Sie ein Terminal, und führen Sie den Befehl nsxcli aus.

Sie können die CLI-Eingabeaufforderung auch aufrufen, indem Sie den folgenden Befehl für einen Knoten ausführen:

kubectl exec -it <pod name> nsxcli

Tabelle 8-1. CLI-Befehle für den NCP-Container

Typ Befehl Hinweis

Status get ncp-master status Für Kubernetes und PCF.

Status get ncp-nsx status Für Kubernetes und PCF.

Status get ncp-watcher <Watcher-Name> Für Kubernetes und PCF.

Status get ncp-watchers Für Kubernetes und PCF.

Status get ncp-k8s-api-server status Für Kubernetes.

Status check projects Für Kubernetes.

Status check project <project-name> Für Kubernetes.

Status get ncp-bbs status Nur für PCF.

Status get ncp-capi status Nur für PCF.

Status get ncp-policy-server status Nur für PCF.

Cache get project-caches Für Kubernetes.

Cache get project-cache <Projektname> Für Kubernetes.

Cache get namespace-caches Für Kubernetes.

Cache get namespace-cache <Namensraum-Name> Für Kubernetes.


VMware, Inc. 115

Tabelle 8-1. CLI-Befehle für den NCP-Container (Fortsetzung)

Typ Befehl Hinweis

Cache get pod-caches Für Kubernetes.

Cache get pod-cache <Pod-Name> Für Kubernetes.

Cache get ingress-caches Für Kubernetes.

Cache get ingress-cache <ingress-name> Für Kubernetes.

Cache get ingress-controllers Für Kubernetes.

Cache get ingress-controller <ingress-controller-name> Für Kubernetes.

Cache get network-policy-caches Für Kubernetes.

Cache get network-policy-cache <pod-name> Für Kubernetes.

Cache get asg-caches Nur für PCF.

Cache get asg-cache <asg-ID> Nur für PCF.

Cache get org-caches Nur für PCF.

Cache get org-cache <org-ID> Nur für PCF.

Cache get space-caches Nur für PCF.

Cache get space-cache <space-ID> Nur für PCF.

Cache get app-caches Nur für PCF.

Cache get app-cache <app-ID> Nur für PCF.

Cache get instance-caches <app-ID> Nur für PCF.

Cache get instance-cache <app-ID> <instance-ID> Nur für PCF.

Cache get policy-caches Nur für PCF.

Support get ncp-log file <Dateiname> Für Kubernetes und PCF.

Support get ncp-log-level Für Kubernetes und PCF.

Support set ncp-log-level <log-level> Für Kubernetes und PCF.

Support get support-bundle file <Dateiname> Für Kubernetes.

Support get node-agent-log file <Dateiname> Für Kubernetes.

Support get node-agent-log file <Dateiname> <Knotenname> Für Kubernetes.

Tabelle 8-2. CLI-Befehle für den NSX-Knoten-Agent-Container

Typ Befehl

Status get node-agent-hyperbus status

Cache get container-cache <Containername>

Cache get container-caches


VMware, Inc. 116

Tabelle 8-3. CLI-Befehle für den NSX-Kube-Proxy-Container

Typ Befehl

Status get ncp-k8s-api-server status

Status get kube-proxy-watcher <Watcher-Name>

Status get kube-proxy-watchers

Status dump ovs-flows

Statusbefehle für den NCP-Container

n Status des NCP-Masters anzeigen

get ncp-master status

Beispiel:

kubenode> get ncp-master status

This instance is not the NCP master

Current NCP Master id is a4h83eh1-b8dd-4e74-c71c-cbb7cc9c4c1c

Last master update at Wed Oct 25 22:46:40 2017

n Verbindungsstatus zwischen NCP und NSX Manager anzeigen

get ncp-nsx status

Beispiel:

kubenode> get ncp-nsx status

NSX Manager status: Healthy

n Watcher-Status für Ingress, Namensraum, Pod und Dienst anzeigen

get ncp-watchers

get ncp-watcher <watcher-name>

Beispiel:

kubenode> get ncp-watchers

pod:

Average event processing time: 1145 msec (in past 3600-sec window)

Current watcher started time: Mar 02 2017 10:51:37 PST

Number of events processed: 1 (in past 3600-sec window)

Total events processed by current watcher: 1

Total events processed since watcher thread created: 1

Total watcher recycle count: 0

Watcher thread created time: Mar 02 2017 10:51:37 PST

Watcher thread status: Up

namespace:




VMware, Inc. 117







ingress:









service:









kubenode> get ncp-watcher pod









n Verbindungsstatus zwischen NCP und Kubernetes-API-Server anzeigen

get ncp-k8s-api-server status

Beispiel:

kubenode> get ncp-k8s-api-server status

Kubernetes ApiServer status: Healthy

n Alle Projekte oder ein bestimmtes Projekt überprüfen

check projects

check project <project-name>


VMware, Inc. 118

Beispiel:

kubenode> check projects

default:

Tier-1 link port for router 1b90a61f-0f2c-4768-9eb6-ea8954b4f327 is missing

Switch 40a6829d-c3aa-4e17-ae8a-7f7910fdf2c6 is missing

ns1:

Router 8accc9cd-9883-45f6-81b3-0d1fb2583180 is missing

kubenode> check project default

Tier-1 link port for router 1b90a61f-0f2c-4768-9eb6-ea8954b4f327 is missing

Switch 40a6829d-c3aa-4e17-ae8a-7f7910fdf2c6 is missing

n Verbindungsstatus zwischen NCP und PCF-BBS überprüfen

get ncp-bbs status

Beispiel:

node> get ncp-bbs status

BBS Server status: Healthy

n Verbindungsstatus zwischen NCP und PCF-CAPI überprüfen

get ncp-capi status

Beispiel:

node> get ncp-capi status

CAPI Server status: Healthy

n Verbindungsstatus zwischen NCP und PCF-Richtlinienserver überprüfen

get ncp-policy-server status

Beispiel:

node> get ncp-bbs status

Policy Server status: Healthy

Cachebefehle für den NCP-Container

n Internen Cache für Projekte oder Namensräume abrufen

get project-cache <project-name>

get project-caches

get namespace-cache <namespace-name>

get namespace-caches


VMware, Inc. 119

Beispiel:

kubenode> get project-caches

default:

logical-router: 8accc9cd-9883-45f6-81b3-0d1fb2583180

logical-switch:

id: 9d7da647-27b6-47cf-9cdb-6e4f4d5a356d

ip_pool_id: 519ff57f-061f-4009-8d92-3e6526e7c17e

subnet: 10.0.0.0/24

subnet_id: f75fd64c-c7b0-4b42-9681-fc656ae5e435

kube-system:

logical-router: 5032b299-acad-448e-a521-19d272a08c46

logical-switch:

id: 85233651-602d-445d-ab10-1c84096cc22a

ip_pool_id: ab1c5b09-7004-4206-ac56-85d9d94bffa2

subnet: 10.0.1.0/24

subnet_id: 73e450af-b4b8-4a61-a6e3-c7ddd15ce751

testns:

ext_pool_id: 346a0f36-7b5a-4ecc-ad32-338dcb92316f

labels:

ns: myns

project: myproject

logical-router: 4dc8f8a9-69b4-4ff7-8fb7-d2625dc77efa

logical-switch:

id: 6111a99a-6e06-4faa-a131-649f10f7c815

ip_pool_id: 51ca058d-c3dc-41fd-8f2d-e69006ab1b3d

subnet: 50.0.2.0/24

subnet_id: 34f79811-bd29-4048-a67d-67ceac97eb98

project_nsgroup: 9606afee-6348-4780-9dbe-91abfd23e475

snat_ip: 4.4.0.3

kubenode> get project-cache default


logical-switch:



subnet: 10.0.0.0/24


kubenode> get namespace-caches

default:


logical-switch:



subnet: 10.0.0.0/24


kube-system:

logical-router: 5032b299-acad-448e-a521-19d272a08c46

logical-switch:


VMware, Inc. 120

id: 85233651-602d-445d-ab10-1c84096cc22a

ip_pool_id: ab1c5b09-7004-4206-ac56-85d9d94bffa2

subnet: 10.0.1.0/24

subnet_id: 73e450af-b4b8-4a61-a6e3-c7ddd15ce751

testns:

ext_pool_id: 346a0f36-7b5a-4ecc-ad32-338dcb92316f

labels:

ns: myns

project: myproject

logical-router: 4dc8f8a9-69b4-4ff7-8fb7-d2625dc77efa

logical-switch:

id: 6111a99a-6e06-4faa-a131-649f10f7c815

ip_pool_id: 51ca058d-c3dc-41fd-8f2d-e69006ab1b3d

subnet: 50.0.2.0/24

subnet_id: 34f79811-bd29-4048-a67d-67ceac97eb98

project_nsgroup: 9606afee-6348-4780-9dbe-91abfd23e475

snat_ip: 4.4.0.3

kubenode> get namespace-cache default


logical-switch:



subnet: 10.0.0.0/24


n Internen Cache für Pods abrufen

get pod-cache <pod-name>

get pod-caches

Beispiel:

kubenode> get pod-caches

nsx.default.nginx-rc-uq2lv:

cif_id: 2af9f734-37b1-4072-ba88-abbf935bf3d4

gateway_ip: 10.0.0.1

host_vif: d6210773-5c07-4817-98db-451bd1f01937

id: 1c8b5c52-3795-11e8-ab42-005056b198fb

ingress_controller: False

ip: 10.0.0.2/24

labels:

app: nginx

mac: 02:50:56:00:08:00

port_id: d52c833a-f531-4bdf-bfa2-e8a084a8d41b

vlan: 1

nsx.testns.web-pod-1:

cif_id: ce134f21-6be5-43fe-afbf-aaca8c06b5cf


host_vif: d6210773-5c07-4817-98db-451bd1f01937

id: 3180b521-270e-11e8-ab42-005056b198fb



VMware, Inc. 121

ip: 50.0.2.3/24

labels:

app: nginx-new

role: db

tier: cache

mac: 02:50:56:00:20:02

port_id: 81bc2b8e-d902-4cad-9fc1-aabdc32ecaf8

vlan: 3

kubenode> get pod-cache nsx.default.nginx-rc-uq2lv

cif_id: 2af9f734-37b1-4072-ba88-abbf935bf3d4


host_vif: d6210773-5c07-4817-98db-451bd1f01937

id: 1c8b5c52-3795-11e8-ab42-005056b198fb


ip: 10.0.0.2/24

labels:

app: nginx

mac: 02:50:56:00:08:00

port_id: d52c833a-f531-4bdf-bfa2-e8a084a8d41b

vlan: 1

n Alle Ingress-Caches oder einen bestimmten Ingress-Cache abrufen

get ingress caches

get ingress-cache <ingress-name>

Beispiel:

kubenode> get ingress-caches

nsx.default.cafe-ingress:

ext_pool_id: cc02db70-539a-4934-a938-5b851b3e485b

lb_virtual_server:

id: 895c7f43-c56e-4b67-bb4c-09d68459d416

lb_service_id: 659eefc6-33d1-4672-a419-344b877f528e

name: dgo2-http

type: http

lb_virtual_server_ip: 5.5.0.2

name: cafe-ingress

rules:

host: cafe.example.com

http:

paths:

path: /coffee

backend:


servicePort: 80

lb_rule:

id: 4bc16bdd-abd9-47fb-a09e-21e58b2131c3

name: dgo2-default-cafe-ingress/coffee

kubenode> get ingress-cache nsx.default.cafe-ingress

ext_pool_id: cc02db70-539a-4934-a938-5b851b3e485b


VMware, Inc. 122

lb_virtual_server:

id: 895c7f43-c56e-4b67-bb4c-09d68459d416

lb_service_id: 659eefc6-33d1-4672-a419-344b877f528e

name: dgo2-http

type: http

lb_virtual_server_ip: 5.5.0.2

name: cafe-ingress

rules:

host: cafe.example.com

http:

paths:

path: /coffee

backend:


servicePort: 80

lb_rule:

id: 4bc16bdd-abd9-47fb-a09e-21e58b2131c3

name: dgo2-default-cafe-ingress/coffee

n Alle Ingress-Caches oder einen bestimmten Ingress-Cache abrufen, einschließlich deaktivierter Controller

get ingress controllers

get ingress-controller <ingress-controller-name>

Beispiel:

kubenode> get ingress-controllers

native-load-balancer:

ingress_virtual_server:

http:

default_backend_tags:

id: 895c7f43-c56e-4b67-bb4c-09d68459d416

pool_id: None

https_terminated:


id: 293282eb-f1a0-471c-9e48-ba28d9d89161

pool_id: None

lb_ip_pool_id: cc02db70-539a-4934-a938-5b851b3e485b

loadbalancer_service:

first_avail_index: 0

lb_services:

id: 659eefc6-33d1-4672-a419-344b877f528e

name: dgo2-bfmxi

t1_link_port_ip: 100.64.128.5

t1_router_id: cb50deb2-4460-45f2-879a-1b94592ae886

virtual_servers:

293282eb-f1a0-471c-9e48-ba28d9d89161

895c7f43-c56e-4b67-bb4c-09d68459d416

ssl:

ssl_client_profile_id: aff205bb-4db8-5a72-8d67-218cdc54d27b

vip: 5.5.0.2


VMware, Inc. 123

nsx.default.nginx-ingress-rc-host-ed3og

ip: 10.192.162.201

mode: hostnetwork

pool_id: 5813c609-5d3a-4438-b9c3-ea3cd6de52c3

kubenode> get ingress-controller native-load-balancer

ingress_virtual_server:

http:


id: 895c7f43-c56e-4b67-bb4c-09d68459d416

pool_id: None

https_terminated:


id: 293282eb-f1a0-471c-9e48-ba28d9d89161

pool_id: None

lb_ip_pool_id: cc02db70-539a-4934-a938-5b851b3e485b

loadbalancer_service:

first_avail_index: 0

lb_services:

id: 659eefc6-33d1-4672-a419-344b877f528e

name: dgo2-bfmxi

t1_link_port_ip: 100.64.128.5

t1_router_id: cb50deb2-4460-45f2-879a-1b94592ae886

virtual_servers:

293282eb-f1a0-471c-9e48-ba28d9d89161

895c7f43-c56e-4b67-bb4c-09d68459d416

ssl:

ssl_client_profile_id: aff205bb-4db8-5a72-8d67-218cdc54d27b

vip: 5.5.0.2

n Netzwerkrichtlinien-Caches oder einen bestimmten Netzwerkrichtlinien-Cache abrufen

get network-policy caches

get network-policy-cache <network-policy-name>

Beispiel:

kubenode> get network-policy-caches

nsx.testns.allow-tcp-80:

dest_labels: None

dest_pods:

50.0.2.3

match_expressions:

key: tier

operator: In

values:

cache

name: allow-tcp-80

np_dest_ip_set_ids:

22f82d76-004f-4d12-9504-ce1cb9c8aa00

np_except_ip_set_ids:

np_ip_set_ids:

14f7f825-f1a0-408f-bbd9-bb2f75d44666

np_isol_section_id: c8d93597-9066-42e3-991c-c550c46b2270


VMware, Inc. 124

np_section_id: 04693136-7925-44f2-8616-d809d02cd2a9

ns_name: testns

src_egress_rules: None

src_egress_rules_hash: 97d170e1550eee4afc0af065b78cda302a97674c

src_pods:

50.0.2.0/24

src_rules:

from:

namespaceSelector:

matchExpressions:

key: tier

operator: DoesNotExist

matchLabels:

ns: myns

ports:

port: 80

protocol: TCP

src_rules_hash: e4ea7b8d91c1e722670a59f971f8fcc1a5ac51f1

kubenode> get network-policy-cache nsx.testns.allow-tcp-80

dest_labels: None

dest_pods:

50.0.2.3

match_expressions:

key: tier

operator: In

values:

cache

name: allow-tcp-80

np_dest_ip_set_ids:

22f82d76-004f-4d12-9504-ce1cb9c8aa00

np_except_ip_set_ids:

np_ip_set_ids:

14f7f825-f1a0-408f-bbd9-bb2f75d44666

np_isol_section_id: c8d93597-9066-42e3-991c-c550c46b2270

np_section_id: 04693136-7925-44f2-8616-d809d02cd2a9

ns_name: testns

src_egress_rules: None

src_egress_rules_hash: 97d170e1550eee4afc0af065b78cda302a97674c

src_pods:

50.0.2.0/24

src_rules:

from:

namespaceSelector:

matchExpressions:

key: tier

operator: DoesNotExist

matchLabels:

ns: myns

ports:

port: 80

protocol: TCP

src_rules_hash: e4ea7b8d91c1e722670a59f971f8fcc1a5ac51f1


VMware, Inc. 125

n Alle ASG-Caches oder einen bestimmten ASG-Cache abrufen

get asg-caches

get asg-cache <asg-ID>

Beispiel:

node> get asg-caches

edc04715-d04c-4e63-abbc-db601a668db6:

fws_id: 3c66f40a-5378-46d7-a7e2-bee4ba72a4cc

name: org-85_tcp_80_asg

rules:

destinations:

66.10.10.0/24

ports:

80

protocol: tcp

rule_id: 4359

running_default: False

running_spaces:

75bc164d-1214-46f9-80bb-456a8fbccbfd

staging_default: False

staging_spaces:

node> get asg-cache edc04715-d04c-4e63-abbc-db601a668db6

fws_id: 3c66f40a-5378-46d7-a7e2-bee4ba72a4cc

name: org-85_tcp_80_asg

rules:

destinations:

66.10.10.0/24

ports:

80

protocol: tcp

rule_id: 4359

running_default: False

running_spaces:

75bc164d-1214-46f9-80bb-456a8fbccbfd

staging_default: False

staging_spaces:

n Alle Organisations-Caches oder einen bestimmten Organisations-Cache abrufen

get org-caches

get org-cache <org-ID>

Beispiel:

node> get org-caches

ebb8b4f9-a40f-4122-bf21-65c40f575aca:

ext_pool_id: 9208a8b8-57d7-4582-9c1f-7a7cefa104f5

isolation:

isolation_section_id: d6e7ff95-4737-4e34-91d4-27601897353f

logical-router: 94a414a2-551e-4444-bae6-3d79901a165f


VMware, Inc. 126

logical-switch:

id: d74807e8-8f74-4575-b26b-87d4fdbafd3c

ip_pool_id: 1b60f16f-4a30-4a3d-93cc-bfb08a5e3e02

subnet: 50.0.48.0/24

subnet_id: a458d3aa-bea9-4684-9957-d0ce80d11788

name: org-50

snat_ip: 70.0.0.49

spaces:

e8ab7aa0-d4e3-4458-a896-f33177557851

node> get org-cache ebb8b4f9-a40f-4122-bf21-65c40f575aca

ext_pool_id: 9208a8b8-57d7-4582-9c1f-7a7cefa104f5

isolation:

isolation_section_id: d6e7ff95-4737-4e34-91d4-27601897353f

logical-router: 94a414a2-551e-4444-bae6-3d79901a165f

logical-switch:

id: d74807e8-8f74-4575-b26b-87d4fdbafd3c

ip_pool_id: 1b60f16f-4a30-4a3d-93cc-bfb08a5e3e02

subnet: 50.0.48.0/24

subnet_id: a458d3aa-bea9-4684-9957-d0ce80d11788

name: org-50

snat_ip: 70.0.0.49

spaces:

e8ab7aa0-d4e3-4458-a896-f33177557851

n Alle Speicher-Caches oder einen bestimmten Speicher-Cache abrufen

get space-caches

get space-cache <space-ID>

Beispiel:

node> get space-caches

global_security_group:

name: global_security_group

running_nsgroup: 226d4292-47fb-4c2e-a118-449818d8fa98

staging_nsgroup: 7ebbf7f5-38c9-43a3-9292-682056722836

7870d134-7997-4373-b665-b6a910413c47:

name: test-space1

org_id: a8423bc0-4b2b-49fb-bbff-a4badf21eb09

running_nsgroup: 4a3d9bcc-be36-47ae-bff8-96448fecf307

running_security_groups:

aa0c7c3f-a478-4d45-8afa-df5d5d7dc512

staging_security_groups:


node> get space-cache 7870d134-7997-4373-b665-b6a910413c47

name: test-space1


running_nsgroup: 4a3d9bcc-be36-47ae-bff8-96448fecf307


VMware, Inc. 127

running_security_groups:


staging_security_groups:


n Alle App-Caches oder einen bestimmten App-Cache abrufen

get app-caches

get app-cache <app-ID>

Beispiel:

node> get app-caches

aff2b12b-b425-4d9f-b8e6-b6308644efa8:

instances:

b72199cc-e1ab-49bf-506d-478d:

app_id: aff2b12b-b425-4d9f-b8e6-b6308644efa8

cell_id: 0dda88bc-640b-44e7-8cea-20e83e873544

cif_id: 158a1d7e-6ccc-4027-a773-55bb2618f51b

gateway_ip: 192.168.5.1

host_vif: 53475dfd-03e4-4bc6-b8ba-3d803725cbab

id: b72199cc-e1ab-49bf-506d-478d

index: 0

ip: 192.168.5.4/24

last_updated_time: 1522965828.45

mac: 02:50:56:00:60:02

port_id: a7c6f6bb-c472-4239-a030-bce615d5063e

state: RUNNING

vlan: 3

name: hello2

rg_id: a8423bc0-4b2b-49fb-bbff-a4badf21eb09

space_id: 7870d134-7997-4373-b665-b6a910413c47

node> get app-cache aff2b12b-b425-4d9f-b8e6-b6308644efa8

instances:

b72199cc-e1ab-49bf-506d-478d:




gateway_ip: 192.168.5.1


id: b72199cc-e1ab-49bf-506d-478d

index: 0

ip: 192.168.5.4/24


mac: 02:50:56:00:60:02


state: RUNNING

vlan: 3

name: hello2


space_id: 7870d134-7997-4373-b665-b6a910413c47


VMware, Inc. 128

n Alle Instanz-Caches einer App oder einen bestimmten Instanz-Cache abrufen

get instance-caches <app-ID>

get instance-cache <app-ID> <instance-ID>

Beispiel:

node> get instance-caches aff2b12b-b425-4d9f-b8e6-b6308644efa8

b72199cc-e1ab-49bf-506d-478d:




gateway_ip: 192.168.5.1


id: b72199cc-e1ab-49bf-506d-478d

index: 0

ip: 192.168.5.4/24


mac: 02:50:56:00:60:02


state: RUNNING

vlan: 3

node> get instance-cache aff2b12b-b425-4d9f-b8e6-b6308644efa8 b72199cc-e1ab-49bf-506d-478d




gateway_ip: 192.168.5.1


id: b72199cc-e1ab-49bf-506d-478d

index: 0

ip: 192.168.5.4/24


mac: 02:50:56:00:60:02


state: RUNNING

vlan: 3

n Alle Richtlinien-Caches abrufen

get policy-caches

Beispiel:

node> get policy-caches

aff2b12b-b425-4d9f-b8e6-b6308644efa8:

fws_id: 3fe27725-f139-479a-b83b-8576c9aedbef

nsg_id: 30583a27-9b56-49c1-a534-4040f91cc333

rules:

8272:

dst_app_id: aff2b12b-b425-4d9f-b8e6-b6308644efa8

ports: 8382

protocol: tcp


VMware, Inc. 129

src_app_id: f582ec4d-3a13-440a-afbd-97b7bfae21d1

f582ec4d-3a13-440a-afbd-97b7bfae21d1:

nsg_id: d24b9f77-e2e0-4fba-b258-893223683aa6

rules:

8272:

dst_app_id: aff2b12b-b425-4d9f-b8e6-b6308644efa8

ports: 8382

protocol: tcp

src_app_id: f582ec4d-3a13-440a-afbd-97b7bfae21d1

Supportbefehle für den NCP-Container

n NCP-Support-Paket im Dateispeicher speichern

Das Support-Paket umfasst die Protokolldateien für alle Container in Pods mit der Bezeichnung tier:nsx-networking. Die Paketdatei liegt im TGZ-Format vor und befindet sich im CLI-Standard-Dateispeicherverzeichnis /var/vmware/nsx/file-store. Mithilfe des CLI-Befehls „file-store“ können Sie die Paketdatei in eine Remote-Site kopieren.

get support-bundle file <filename>

Beispiel:

kubenode>get support-bundle file foo

Bundle file foo created in tgz format

kubenode>copy file foo url scp://[email protected]:/tmp

n NCP-Protokolle im Dateispeicher speichern

Die Protokolldatei wird im TGZ-Format im CLI-Standard-Dateispeicherverzeichnis /var/vmware/nsx/file-store gespeichert. Mithilfe des CLI-Befehls „file-store“ können Sie die Paketdatei in eine Remote-Site kopieren.

get ncp-log file <filename>

Beispiel:

kubenode>get ncp-log file foo

Log file foo created in tgz format

n Knoten-Agent-Protokolle im Dateispeicher speichern

Speichern Sie die Knoten-Agent-Protokolle von einem oder allen Knoten. Die Protokolle werden im TGZ-Format im CLI-Standard-Dateispeicherverzeichnis /var/vmware/nsx/file-store gespeichert. Mithilfe des CLI-Befehls „file-store“ können Sie die Paketdatei in eine Remote-Site kopieren.

get node-agent-log file <filename>

get node-agent-log file <filename> <node-name>


VMware, Inc. 130

Beispiel:

kubenode>get node-agent-log file foo

Log file foo created in tgz format

n Protokollebene abrufen und einrichten

Zu den verfügbaren Protokollebenen gehören: NOTSET, DEBUG, INFO, WARNING, ERROR und CRITICAL.

get ncp-log-level

set ncp-log-level <log level>

Beispiel:

kubenode>get ncp-log-level

NCP log level is INFO

kubenode>set ncp-log-level DEBUG

NCP log level is changed to DEBUG

Status-Befehle für den NSX-Knoten-Agent-Container

n Zeigen Sie den Verbindungsstatus zwischen dem Knoten-Agent und HyperBus auf diesem Knoten an.

get node-agent-hyperbus status

Beispiel:

kubenode> get node-agent-hyperbus status

HyperBus status: Healthy

Cache-Befehle für den NSX-Knoten-Agent-Container

n Internen Cache für NSX-Knoten-Agent-Container abrufen

get container-cache <container-name>

get container-caches

Beispiel:

kubenode> get container-caches

cif104:

ip: 192.168.0.14/32

mac: 50:01:01:01:01:14

gateway_ip: 169.254.1.254/16

vlan_id: 104

kubenode> get container-cache cif104


VMware, Inc. 131

ip: 192.168.0.14/32

mac: 50:01:01:01:01:14

gateway_ip: 169.254.1.254/16

vlan_id: 104

Status-Befehle für den NSX-Kube-Proxy-Container

n Verbindungsstatus zwischen Kube-Proxy und Kubernetes-API-Server anzeigen

get ncp-k8s-api-server status

Beispiel:

kubenode> get kube-proxy-k8s-api-server status

Kubernetes ApiServer status: Healthy

n Kube-Proxy-Watcher-Status anzeigen

get kube-proxy-watcher <watcher-name>

get kube-proxy-watchers

Beispiel:

kubenode> get kube-proxy-watchers

endpoint:


Current watcher started time: May 01 2017 15:06:24 PDT





Watcher thread created time: May 01 2017 15:06:24 PDT


service:









kubenode> get kube-proxy-watcher endpoint






VMware, Inc. 132





n OVS-Flows für Speicherabbild an einem Knoten

dump ovs-flows

Beispiel:

kubenode> dump ovs-flows

NXST_FLOW reply (xid=0x4):

cookie=0x0, duration=8.876s, table=0, n_packets=0, n_bytes=0, idle_age=8, priority=100,ip

actions=ct(table=1)

cookie=0x0, duration=8.898s, table=0, n_packets=0, n_bytes=0, idle_age=8, priority=0

actions=NORMAL

cookie=0x0, duration=8.759s, table=1, n_packets=0, n_bytes=0, idle_age=8,

priority=100,tcp,nw_dst=10.96.0.1,tp_dst=443 actions=mod_tp_dst:443


priority=100,ip,nw_dst=10.96.0.10 actions=drop


priority=90,ip,in_port=1 actions=ct(table=2,nat)

cookie=0x0, duration=8.799s, table=1, n_packets=0, n_bytes=0, idle_age=8, priority=80,ip

actions=NORMAL

cookie=0x0, duration=8.856s, table=2, n_packets=0, n_bytes=0, idle_age=8, actions=NORMAL

Fehlercodes

In diesem Abschnitt werden die Fehlercodes der verschiedenen Komponenten aufgelistet.

NCP-Fehlercodes

Fehlercode Beschreibung

NCP00001 Ungültige Konfiguration

NCP00002 Initialisierung fehlgeschlagen

NCP00003 Ungültiger Zustand

NCP00004 Ungültiger Adapter

NCP00005 Zertifikat wurde nicht gefunden

NCP00006 Token wurde nicht gefunden

NCP00007 Ungültige Konfiguration für NSX

NCP00008 Ungültiges NSX-Tag

NCP00009 NSX-Verbindung fehlgeschlagen

NCP00010 Knoten-Tag nicht gefunden

NCP00011 Ungültiger logischer Switch-Port des Knotens

NCP00012 Aktualisieren der übergeordneten VIF fehlgeschlagen


VMware, Inc. 133


NCP00013 VLAN ausgeschöpft

NCP00014 VLAN-Version ist fehlgeschlagen

NCP00015 IP-Pool ist ausgeschöpft

NCP00016 IP-Version ist fehlgeschlagen

NCP00017 IP-Block ausgeschöpft

NCP00018 Erstellen des IP-Subnetzes ist fehlgeschlagen

NCP00019 Löschen des IP-Subnetzes ist fehlgeschlagen

NCP00020 Erstellen des IP-Pools ist fehlgeschlagen

NCP00021 Löschen des IP-Pools ist fehlgeschlagen

NCP00022 Erstellen des logischen Routers ist fehlgeschlagen

NCP00023 Aktualisieren des logischen Routers ist fehlgeschlagen

NCP00024 Löschen des logischen Routers ist fehlgeschlagen

NCP00025 Erstellen des logischen Switches ist fehlgeschlagen


NCP00026 Aktualisieren des logischen Switches ist fehlgeschlagen

NCP00027 Löschen des logischen Switches ist fehlgeschlagen

NCP00028 Erstellen des Ports für den logischen Router ist fehlgeschlagen

NCP00029 Löschen des Ports für den logischen Router ist fehlgeschlagen

NCP00030 Erstellen des Ports für den logischen Switch ist fehlgeschlagen

NCP00031 Aktualisieren des Ports für den logischen Switch ist fehlgeschlagen

NCP00032 Löschen des Ports für den logischen Switch ist fehlgeschlagen

NCP00033 Netzwerkrichtlinie wurde nicht gefunden

NCP00034 Erstellen der Firewall ist fehlgeschlagen

NCP00035 Lesen der Firewall ist fehlgeschlagen

NCP00036 Aktualisieren der Firewall ist fehlgeschlagen

NCP00037 Löschen der Firewall ist fehlgeschlagen

NCP00038 Mehrere Firewalls gefunden

NCP00039 Erstellen der NSGroup ist fehlgeschlagen

NCP00040 Löschen der NSGroup ist fehlgeschlagen

NCP00041 Erstellen von IP Set ist fehlgeschlagen

NCP00042 Aktualisieren von IP Set ist fehlgeschlagen

NCP00043 Löschen von IP Set ist fehlgeschlagen

NCP00044 Erstellen der SNAT-Regel ist fehlgeschlagen

NCP00045 Löschen der SNAT-Regel ist fehlgeschlagen


VMware, Inc. 134


NCP00046 Adapter-API-Verbindung ist fehlgeschlagen

NCP00047 Adapter-Watcher-Ausnahme

NCP00048 Löschen des Load Balancer-Diensts ist fehlgeschlagen

NCP00049 Erstellen des virtuellen Servers für den Load Balancer ist fehlgeschlagen

NCP00050 Aktualisieren des virtuellen Servers für den Load Balancer ist fehlgeschlagen


NCP00051 Löschen des virtuellen Servers für den Load Balancer ist fehlgeschlagen

NCP00052 Erstellen des Load Balancer-Pools ist fehlgeschlagen

NCP00053 Aktualisieren des Load Balancer-Pools ist fehlgeschlagen

NCP00054 Löschen des Load Balancer-Pools ist fehlgeschlagen

NCP00055 Erstellen der Load Balancer-Regel ist fehlgeschlagen

NCP00056 Aktualisieren des Load Balancer-Pools ist fehlgeschlagen

NCP00057 Löschen der Load Balancer-Regel ist fehlgeschlagen

NCP00058 IP-Freigabe für Load Balancer-Pool ist fehlgeschlagen

NCP00059 Zuordnung von virtuellem Server und Dienstzuordnung für Load Balancer nicht gefunden

NCP00060 Aktualisieren der NSGroup ist fehlgeschlagen

NCP00061 Abrufen der Firewallregeln ist fehlgeschlagen

NCP00062 NSGroup – keine Kriterien

NCP00063 Knoten-VM nicht gefunden

NCP00064 Knoten-VIF nicht gefunden

NCP00065 Zertifikatimport ist fehlgeschlagen

NCP00066 Rückgängigmachen des Zertifikats ist fehlgeschlagen

NCP00067 Aktualisieren der SSL-Bindung ist fehlgeschlagen

NCP00068 SSL-Profil nicht gefunden

NCP00069 IP-Pool nicht gefunden

NCP00070 T0-Edge-Cluster nicht gefunden

NCP00071 Aktualisieren des IP-Pools ist fehlgeschlagen

NCP00072 Dispatcher ist fehlgeschlagen

NCP00073 Löschen der NAT-Regel ist fehlgeschlagen

NCP00074 Abrufen des Ports für den logischen Router ist fehlgeschlagen

NCP00075 NSX-Konfigurationsvalidierung ist fehlgeschlagen


NCP00076 Aktualisieren der SNAT-Regel ist fehlgeschlagen

NCP00077 SNAT-Regel überlagert


VMware, Inc. 135


NCP00078 Hinzufügen der Load Balancer-Endpoints ist fehlgeschlagen

NCP00079 Aktualisieren der Load Balancer-Endpoints ist fehlgeschlagen

NCP00080 Erstellen des Load Balancer-Regelpools ist fehlgeschlagen

NCP00081 Virtueller Server für Load Balancer nicht gefunden

NCP00082 Lesen von IP Set ist fehlgeschlagen

NCP00083 Abrufen von SNAT-Pool ist fehlgeschlagen

NCP00084 Erstellen des Load Balancer-Diensts ist fehlgeschlagen

NCP00085 Aktualisieren des Load Balancer-Diensts ist fehlgeschlagen

NCP00086 Aktualisieren des Ports für den logischen Router ist fehlgeschlagen

NCP00087 Load Balancer-Initialisierung ist fehlgeschlagen

NCP00088 IP-Pool nicht eindeutig

NCP00089 Layer 7 des Load Balancers – Cache-Synchronisierungsfehler

NCP00090 Load Balancer-Pool ist nicht vorhanden

NCP00091 Fehler beim Initialisieren des Load Balancer-Regelcaches

NCP00092 SNAT-Prozess ist fehlgeschlagen

NCP00093 Fehler bei Load Balancer-Standardzertifikat

NCP00094 Löschen des Load Balancer-Endpoints ist fehlgeschlagen

NCP00095 Projekt nicht gefunden

NCP00096 Pool-Zugriff verweigert

NCP00097 Fehler beim Abrufen eines Load Balancer-Diensts

NCP00098 Fehler beim Erstellen eines Load Balancer-Diensts

NCP00099 Fehler bei Synchronisierung des Load Balancer-Pool-Caches

Fehlercodes für NSX-Knoten-Agent


NCP01001 OVS-Uplink nicht gefunden

NCP01002 Host-MAC nicht gefunden

NCP01003 OVS-Porterstellung ist fehlgeschlagen

NCP01004 Keine Pod-Konfiguration

NCP01005 Pod-Konfiguration ist fehlgeschlagen

NCP01006 Aufheben der Pod-Konfiguration ist fehlgeschlagen

NCP01007 CNI-Socket nicht gefunden

NCP01008 CNI-Verbindung ist fehlgeschlagen

NCP01009 CNI-Version stimmt nicht überein

NCP01010 CNI-Nachrichtenempfang ist fehlgeschlagen


VMware, Inc. 136


NCP01011 CNI-Nachrichtenübertragung ist fehlgeschlagen

NCP01012 Hyperbus-Verbindung ist fehlgeschlagen

NCP01013 Hyperbus-Version stimmt nicht überein

NCP01014 Fehler beim Empfang der Hyperbus-Nachricht

NCP01015 Hyperbus-Nachrichtenübertragung ist fehlgeschlagen

NCP01016 GARP-Senden ist fehlgeschlagen

NCP01017 Schnittstellenkonfiguration ist fehlgeschlagen

Fehlercodes für nsx-kube-proxy


NCP02001 Ungültiger Gateway-Port des Proxys

NCP02002 Proxy-Befehl ist fehlgeschlagen

NCP02003 Proxy-Validierung ist fehlgeschlagen

CLI-Fehlercodes


NCP03001 CLI-Start ist fehlgeschlagen

NCP03002 Erstellen des CLI-Sockets ist fehlgeschlagen

NCP03003 CLI-Socket-Ausnahme

NCP03004 Ungültige Anforderung von CLI-Client

NCP03005 CLI-Server-Übertragung ist fehlgeschlagen

NCP03006 CLI-Server-Empfang ist fehlgeschlagen

NCP03007 CLI-Befehlsausführung ist fehlgeschlagen

Fehlercodes für Kubernetes


NCP05001 Kubernetes-Verbindung ist fehlgeschlagen

NCP05002 Ungültige Konfiguration für Kubernetes

NCP05003 Kubernetes-Anforderung ist fehlgeschlagen

NCP05004 Kubernetes-Schlüssel nicht gefunden

NCP05005 Kubernetes-Typ nicht gefunden

NCP05006 Ausnahme bei Kubernetes-Wächter

NCP05007 Kubernetes-Ressource weist ungültige Länge auf

NCP05008 Kubernetes-Ressource weist ungültigen Typ auf


VMware, Inc. 137


NCP05009 Kubernetes-Ressourcen-Handle ist fehlgeschlagen

NCP05010 Kubernetes-Dienst-Handle ist fehlgeschlagen

NCP05011 Kubernetes-Endpoint-Handle ist fehlgeschlagen

NCP05012 Kubernetes-Ingress-Handle ist fehlgeschlagen

NCP05013 Kubernetes-Netzwerkrichtlinien-Handle ist fehlgeschlagen

NCP05014 Kubernetes-Knoten-Handle ist fehlgeschlagen

NCP05015 Kubernetes-Namespace-Handle ist fehlgeschlagen

NCP05016 Kubernetes-Pod-Handle ist fehlgeschlagen

NCP05017 Kubernetes-Secret-Handle ist fehlgeschlagen

NCP05018 Kubernetes-Standard-Backend ist fehlgeschlagen

NCP05019 Nicht unterstützter Übereinstimmungsausdruck für Kubernetes

NCP05020 Aktualisieren des Kubernetes-Status ist fehlgeschlagen

NCP05021 Aktualisieren des Kubernetes-Kommentars ist fehlgeschlagen

NCP05022 Kubernetes-Namespace-Cache nicht gefunden

NCP05023 Kubernetes-Secret nicht gefunden

NCP05024 Kubernetes-Standard-Backend wird verwendet

NCP05025 Kubernetes-LoadBalancer-Dienst-Handle ist fehlgeschlagen

Fehlercodes für Pivotal Cloud Foundry


NCP06001 PCF BBS-Verbindung ist fehlgeschlagen

NCP06002 PCF CAPI-Verbindung ist fehlgeschlagen

NCP06006 PCF-Cache nicht gefunden

NCP06007 Unbekannte Domäne für PCF

NCP06020 PCF-Richtlinienserver-Verbindung fehlgeschlagen

NCP06021 PCF-Richtlinienverarbeitung ist fehlgeschlagen

NCP06030 PCF-Ereignisverarbeitung ist fehlgeschlagen

NCP06031 Unerwarteter Ereignistyp für PCF

NCP06032 Unerwartete Ereignisinstanz für PCF

NCP06033 Löschen von PCF-Aufgabe ist fehlgeschlagen

NCP06034 PCF-Dateizugriff ist fehlgeschlagen


VMware, Inc. 138

nsx container plug-in 3.0, 3.0.1 vmware nsx-t data center 3€¦ · nsx container plug-in für...

Documents