Upload
others
View
44
Download
0
Embed Size (px)
Citation preview
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 2
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
Ü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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 7
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
Dieses Kapitel enthält die folgenden Themen:
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
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
Knotenname ncp/node_name
Clustername ncp/cluster
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
Beachten Sie Folgendes:
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.
n IP_POOL_EXHAUSTED: Der SNAT-IP-Pool ist ausgeschöpft.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
Beachten Sie Folgendes:
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 IP_POOL_EXHAUSTED: Der SNAT-IP-Pool ist ausgeschöpft.
n SNAT_PROCESS_FAILED: Unbekannter Fehler ist aufgetreten.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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 IP_POOL_EXHAUSTED: Der SNAT-IP-Pool ist ausgeschöpft.
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>
...
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
Dieses Kapitel enthält die folgenden Themen:
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 25
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
Knotenname ncp/node_name
Clustername ncp/cluster
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
# Choices: NOTSET DEBUG INFO WARNING ERROR CRITICAL
#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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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>
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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>
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
# the k8s API server. It must be specified together 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
# Choices: NOTSET DEBUG INFO WARNING ERROR CRITICAL
#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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
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>
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 43
# Full path of the client private key file to use for authenticating with
# the k8s API server. It must be specified together 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
# Choices: NOTSET DEBUG INFO WARNING ERROR CRITICAL
#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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
# Choices: NOTSET DEBUG INFO WARNING ERROR CRITICAL
#loglevel = <None>
# Log level for NSX API client operations
# Choices: NOTSET DEBUG INFO WARNING ERROR CRITICAL
#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 Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
# Choices: NOTSET DEBUG INFO WARNING ERROR CRITICAL
#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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 47
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 49
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:
...
- name: nsx-ujo-log-dir
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>
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
- name: nsx-ujo-log-dir
mountPath: /var/log/nsx-ujo
volumes:
...
- name: rsyslog-config-volume
configMap:
name: rsyslog-config
- name: nsx-ujo-log-dir
hostPath:
path: <host-filesystem-log-dir-path>
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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:
name: rsyslog-config
labels:
version: v1
data:
nsx-ncp.conf: |
module(load="imfile")
ruleset(name="remote") {
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 52
spec:
template:
metadata:
labels:
component: rsyslog
version: v1
spec:
hostNetwork: true
containers:
- name: rsyslog
image: example/rsyslog
imagePullPolicy: IfNotPresent
volumeMounts:
- name: rsyslog-config-volume
mountPath: /etc/rsyslog.d
- name: log-volume
mountPath: /var/log
- name: container-volume
mountPath: /var/lib/docker/containers
volumes:
- name: rsyslog-config-volume
configMap:
name: rsyslog-config
- 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 {
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
ca_file = /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
client_token_file = /var/run/secrets/kubernetes.io/serviceaccount/token
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:
name: rsyslog-config
labels:
version: v1
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 54
data:
ncp.conf: |
module(load="imfile")
ruleset(name="remote") {
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:
tier: nsx-networking
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"
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
imagePullPolicy: IfNotPresent
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
mountPath: /var/log/nsx-ujo
- name: rsyslog
image: jumanjiman/rsyslog
imagePullPolicy: IfNotPresent
volumeMounts:
- name: rsyslog-config-volume
mountPath: /etc/rsyslog.d
readOnly: true
- name: log-volume
mountPath: /var/log/nsx-ujo
volumes:
- name: config-volume
# ConfigMap nsx-ncp-config is expected to supply ncp.ini
configMap:
name: nsx-ncp-config-with-logging
- name: rsyslog-config-volume
configMap:
name: rsyslog-config
- 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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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: |
module(load="imfile")
ruleset(name="remote") {
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
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
name: nsx-node-agent
labels:
tier: nsx-networking
component: nsx-node-agent
version: v1
spec:
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 57
template:
metadata:
annotations:
container.apparmor.security.beta.kubernetes.io/nsx-node-agent: localhost/node-agent-
apparmor
labels:
tier: nsx-networking
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
# Docker image for NCP
image: nsx-ujo-docker-local.artifactory.eng.vmware.com/nsx-ncp:ob-6236425
imagePullPolicy: IfNotPresent
# override NCP image entrypoint
command: ["nsx_node_agent"]
livenessProbe:
exec:
command:
- /bin/sh
- -c
- ps aux | grep [n]sx_node_agent
initialDelaySeconds: 5
periodSeconds: 5
securityContext:
capabilities:
add:
- NET_ADMIN
- SYS_ADMIN
- SYS_PTRACE
- DAC_READ_SEARCH
volumeMounts:
# ncp.ini
- name: config-volume
mountPath: /etc/nsx-ujo
# 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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 58
mountPath: /var/log/nsx-ujo
- name: nsx-kube-proxy
# Docker image for NCP
image: nsx-ujo-docker-local.artifactory.eng.vmware.com/nsx-ncp:ob-6236425
imagePullPolicy: IfNotPresent
# override NCP image entrypoint
command: ["nsx_kube_proxy"]
livenessProbe:
exec:
command:
- /bin/sh
- -c
- ps aux | grep [n]sx_kube_proxy
initialDelaySeconds: 5
periodSeconds: 5
securityContext:
capabilities:
add:
- NET_ADMIN
- SYS_ADMIN
- SYS_PTRACE
- DAC_READ_SEARCH
volumeMounts:
# ncp.ini
- name: config-volume
mountPath: /etc/nsx-ujo
# mount openvswitch dir
- name: openvswitch
mountPath: /var/run/openvswitch
- name: log-volume
mountPath: /var/log/nsx-ujo
- name: rsyslog
image: jumanjiman/rsyslog
imagePullPolicy: IfNotPresent
volumeMounts:
- name: rsyslog-config-volume
mountPath: /etc/rsyslog.d
readOnly: true
- name: log-volume
mountPath: /var/log/nsx-ujo
volumes:
- name: config-volume
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:
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 59
path: /var/run/openvswitch
- name: rsyslog-config-volume
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 60
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 61
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:
- namespaceSelector:
matchLabels:
project: myproject1
- namespaceSelector:
matchLabels:
project: myproject2
- namespaceSelector:
matchLabels:
project: myproject3
- podSelector:
matchLabels:
role: db
- podSelector:
matchLabels:
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
Dieses Kapitel enthält die folgenden Themen:
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.
13 Klicken Sie in der oberen linken Ecke auf Installations-Dashboard, um zum Dashboard zurückzukehren.
14 Klicken Sie auf Speichern.
15 Klicken Sie in der oberen linken Ecke auf Installations-Dashboard, um zum Dashboard zurückzukehren.
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.
20 Klicken Sie auf Speichern.
21 Wählen Sie im Navigationsbereich NCP aus.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
32 Klicken Sie auf Speichern.
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 68
34 Klicken Sie in der oberen linken Ecke auf Installations-Dashboard, um zum Dashboard zurückzukehren.
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 69
Load Balancing 5Der Load Balancer von NSX-T Data Center ist in Kubernetes integriert.
Dieses Kapitel enthält die folgenden Themen:
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/
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 71
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:
apiVersion: extensions/v1beta1
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 72
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
No default value 3.0.0 and later
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
No default value 3.0.2 and later
ncp/jwt-token Additional location to search for JWT in the HTTP request.
_arg_<param_name>, _cookie_<cookie_name>
No default value 3.0.2 and later
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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:
- host: cafe.example.com
http:
paths:
- path: /tea/.*
backend:
serviceName: tea-svc
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:
- host: cafe.example.com
http:
paths:
- path: /tea
backend:
serviceName: tea-svc
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 77
servicePort: 80
- path: /coffee
backend:
serviceName: coffee-svc
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:
kubernetes.io/ingress.class: "nsx"
ncp/use-regex: "true"
#/tea/cup will be rewritten to /cup before sending request to endpoint
ingress.kubernetes.io/rewrite-target: /$1
spec:
rules:
- host: cafe.example.com
http:
paths:
- path: /tea/(.*)
backend:
serviceName: tea-svc
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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:
kubernetes.io/ingress.class: "nsx"
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:
- host: cafe.example.com
http:
paths:
- path: /tea
backend:
serviceName: tea-svc
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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,
apiVersion: vmware.com/v1alpha1
kind: VirtualNetwork
metadata:
name: vnet
---
apiVersion: vmware.com/v1alpha1
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 88
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 90
Upgrade von NCP 6Sie können NCP von Version 2.4.* oder 2.5.* auf 3.0.x aktualisieren.
Dieses Kapitel enthält die folgenden Themen:
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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).
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
Dieses Kapitel enthält die folgenden Themen:
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
Erwartete Fehler und Lösungen:
n Konnektivitätsproblem
Lösung: Versuchen Sie es nach der Behebung des Konnektivitätsproblems erneut.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
Erwartete Fehler und Lösungen:
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).
Erwartete Fehler und Lösungen:
n Konnektivitätsproblem
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 99
Lösung: Versuchen Sie es nach der Behebung des Konnektivitätsproblems erneut.
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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:
- "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 - 1 Class Name>:
<NSX Resource - 1B 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 Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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:
# It should be a list
- key: 'linked_id-key'
value: 'linked_id-value'
NATRules:
custom_resources:
# Custom resources are specified only with MP ID
536870924:
metadata:
# It should be a list
- key: 'metadata-key'
value: 'metadata-value'
linked_ids:
# It should be a list
- key: 'linked_id-key'
value: 'linked_id-value'
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 103
- Tier1Router
- Tier1RouterPortsAndStaticRoutes
NamespaceResources
- IpBlockSubnet
- IpPoolAllocation
- Tier1Router
- Tier1RouterPorts
- NATRules
- SpoofguradProfile
- NodeLogicalSwitch
- NsGroup
PodResources
- LogicalPort
- NATRules
NetworkPolicyResources
- IpSet
- FirewallSectionsAndRules
SecretResources
- Certificate
LBClusterWideResources
- IpPool
- IpPoolAllocation
- NodeLogicalSwitch
- Tier1Router
- Tier1RouterPortsAndStaticRoutes
- 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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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:
is-any-cluster-top-tier: False # required attribute
# 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:
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
top-tier-router-type: TIER0
# 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:
# top-tier-router-id (MP) is required for each cluster
top-tier-router-id: null
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:
# It should be a list
- key: 'linked_id-key'
value: 'linked_id-value'
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:
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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:
is-any-cluster-top-tier: False # required attribute
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:
is-any-cluster-top-tier: False # required attribute
# 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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 109
- id: 'rule-id' # name or id must be specified
Certificate:
resources:
my-cert:
k8s-clusters:
k8scluster:
# 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
top-tier-router-type: TIER0
# lb-service-mp-id is the same as lb_service in ncp.ini config file
lb-service-mp-id: null # optional
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:
# top-tier-router-id (MP) is required for each cluster
top-tier-router-id: null
top-tier-router-type: TIER1
# lb-service-mp-id is the same as lb_service in ncp.ini config file
lb-service-mp-id: null # optional
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
# 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:
# It should be a list
- key: 'linked_id-key'
value: 'linked_id-value'
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
Dieses Kapitel enthält die folgenden Themen:
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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-
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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.
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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:
Average event processing time: 68 msec (in past 3600-sec window)
Current watcher started time: Mar 02 2017 10:51:37 PST
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 117
Number of events processed: 2 (in past 3600-sec window)
Total events processed by current watcher: 2
Total events processed since watcher thread created: 2
Total watcher recycle count: 0
Watcher thread created time: Mar 02 2017 10:51:37 PST
Watcher thread status: Up
ingress:
Average event processing time: 0 msec (in past 3600-sec window)
Current watcher started time: Mar 02 2017 10:51:37 PST
Number of events processed: 0 (in past 3600-sec window)
Total events processed by current watcher: 0
Total events processed since watcher thread created: 0
Total watcher recycle count: 0
Watcher thread created time: Mar 02 2017 10:51:37 PST
Watcher thread status: Up
service:
Average event processing time: 3 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
kubenode> get ncp-watcher pod
Average event processing time: 1174 msec (in past 3600-sec window)
Current watcher started time: Mar 02 2017 10:47:35 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:47:35 PST
Watcher thread status: Up
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>
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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-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
kubenode> get namespace-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:
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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-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
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
gateway_ip: 50.0.2.1
host_vif: d6210773-5c07-4817-98db-451bd1f01937
id: 3180b521-270e-11e8-ab42-005056b198fb
ingress_controller: False
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
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
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:
serviceName: coffee-svc
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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:
serviceName: coffee-svc
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:
default_backend_tags:
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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:
default_backend_tags:
id: 895c7f43-c56e-4b67-bb4c-09d68459d416
pool_id: None
https_terminated:
default_backend_tags:
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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:
aa0c7c3f-a478-4d45-8afa-df5d5d7dc512
node> get space-cache 7870d134-7997-4373-b665-b6a910413c47
name: test-space1
org_id: a8423bc0-4b2b-49fb-bbff-a4badf21eb09
running_nsgroup: 4a3d9bcc-be36-47ae-bff8-96448fecf307
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 127
running_security_groups:
aa0c7c3f-a478-4d45-8afa-df5d5d7dc512
staging_security_groups:
aa0c7c3f-a478-4d45-8afa-df5d5d7dc512
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:
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
org_id: a8423bc0-4b2b-49fb-bbff-a4badf21eb09
space_id: 7870d134-7997-4373-b665-b6a910413c47
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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:
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
node> get instance-cache aff2b12b-b425-4d9f-b8e6-b6308644efa8 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
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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>
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
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:
Average event processing time: 15 msec (in past 3600-sec window)
Current watcher started time: May 01 2017 15:06:24 PDT
Number of events processed: 90 (in past 3600-sec window)
Total events processed by current watcher: 90
Total events processed since watcher thread created: 90
Total watcher recycle count: 0
Watcher thread created time: May 01 2017 15:06:24 PDT
Watcher thread status: Up
service:
Average event processing time: 8 msec (in past 3600-sec window)
Current watcher started time: May 01 2017 15:06:24 PDT
Number of events processed: 2 (in past 3600-sec window)
Total events processed by current watcher: 2
Total events processed since watcher thread created: 2
Total watcher recycle count: 0
Watcher thread created time: May 01 2017 15:06:24 PDT
Watcher thread status: Up
kubenode> get kube-proxy-watcher endpoint
Average event processing time: 15 msec (in past 3600-sec window)
Current watcher started time: May 01 2017 15:06:24 PDT
Number of events processed: 90 (in past 3600-sec window)
Total events processed by current watcher: 90
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 132
Total events processed since watcher thread created: 90
Total watcher recycle count: 0
Watcher thread created time: May 01 2017 15:06:24 PDT
Watcher thread status: Up
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
cookie=0x0, duration=8.719s, table=1, n_packets=0, n_bytes=0, idle_age=8,
priority=100,ip,nw_dst=10.96.0.10 actions=drop
cookie=0x0, duration=8.819s, table=1, n_packets=0, n_bytes=0, idle_age=8,
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 133
Fehlercode Beschreibung
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
Fehlercode Beschreibung
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 134
Fehlercode Beschreibung
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
Fehlercode Beschreibung
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
Fehlercode Beschreibung
NCP00076 Aktualisieren der SNAT-Regel ist fehlgeschlagen
NCP00077 SNAT-Regel überlagert
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 135
Fehlercode Beschreibung
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
Fehlercode Beschreibung
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 136
Fehlercode Beschreibung
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
Fehlercode Beschreibung
NCP02001 Ungültiger Gateway-Port des Proxys
NCP02002 Proxy-Befehl ist fehlgeschlagen
NCP02003 Proxy-Validierung ist fehlgeschlagen
CLI-Fehlercodes
Fehlercode Beschreibung
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
Fehlercode Beschreibung
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 137
Fehlercode Beschreibung
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
Fehlercode Beschreibung
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
NSX Container Plug-In für Kubernetes und Cloud Foundry – Installations- und Administratorhandbuch
VMware, Inc. 138