NSX-T Container Plug-In für OpenShift – Installations- und ... fileNSX-T Container Plug-in (NCP) stellt eine Integration zwischen NSX-T und der Container-Orchestrierung wie z. B

NSX-T Container Plug-Infür OpenShift –Installations- undAdministratorhandbuchGeändert am 18. Juli 2018VMware NSX-T 2.2.1VMware NSX-T Data Center 2.2

NSX-T Container Plug-In für OpenShift – Installations- und Administratorhandbuch

VMware, Inc. 2

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

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

Die VMware-Website enthält auch die neuesten Produkt-Updates.

Falls Sie Anmerkungen zu dieser Dokumentation haben, senden Sie diese an:

[email protected]

Copyright © 2017, 2018 VMware, Inc. Alle Rechte vorbehalten. Urheberrechts- und Markenhinweise.

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

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

mailto:[email protected]

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

Inhalt

NSX-T Container Plug-In für OpenShift – Installations- und Administratorhandbuch 4

1 Übersicht über das NSX-T Container Plug-In 5

Kompatibilitätsanforderungen 6

Überblick über die Installation 6

2 Einrichten von NSX-T-Ressourcen 8

Konfigurieren von NSX-T-Ressourcen 8

Erstellen und Konfigurieren eines logischen Tier-0-Routers 11

3 Einrichten des NSX-T Container Plug-Ins und von OpenShift 13

Bereitstellen von OpenShift-VMs 13

Vorbereiten der Ansible-Hostdatei 13

Installieren von NCP und OpenShift mit einem einzelnen Playbook 16

Installieren von CNI-Plug-In, OVS und NCP-Docker-Image 16

Installieren von OpenShift Container Platform 19

Ausführen des NCP- und NSX-Knotenagenten 19

Hinweise zur Einrichtung 20

4 Lastausgleich 24

Konfigurieren des Lastausgleichs 24

5 Verwalten von NSX-T Container Plug-in 30

Verwalten von IP-Blöcken über die NSX Manager -GUI 30

Verwalten von IP-Block-Subnetzen über die GUI von NSX Manager 31

CIF-verknüpfte logische Ports 31

CLI-Befehle 32

Fehlercodes 43

VMware, Inc. 3

NSX-T Container Plug-In für OpenShift –Installations- und Administratorhandbuch

Dieses Handbuch beschreibt die Installation und Verwaltung von NSX-T Container Plug-in (NCP) für dieBereitstellung der Integration zwischen NSX-T und OpenShift.

ZielgruppeDieses Handbuch ist für die System-und Netzwerkadministratoren bestimmt. Es wird vorausgesetzt, dassSie mit der Installation und Verwaltung von NSX-T und OpenShift vertraut sind.

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

VMware, Inc. 4

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

Übersicht über das NSX-TContainer Plug-In 1NSX-T Container Plug-in (NCP) stellt eine Integration zwischen NSX-T und der Container-Orchestrierungwie z. B. Kubernetes sowie die Integration zwischen NSX-T und Container-basierten PaaS-Softwarepro-dukten (Plattform als Dienst), wie z. B. OpenShift, bereit. Dieses Handbuch beschreibt das Einrichten vonNCP mit OpenShift.

Die Hauptkomponente von NCP wird in einem Container ausgeführt und kommuniziert mit NSX Managerund mit der OpenShift-Steuerungsebene. NCP überwacht Änderungen an den Containern und anderenRessourcen und verwaltet Netzwerkressourcen wie logische Ports, Switches, Router und Sicherheits-gruppen für die Container per Aufruf der NSX API.

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

NCP bietet die folgenden Funktionen:

n Es erstellt automatisch eine logische NSX-T-Topologie für einen OpenShift-Cluster und erstellt ein se-parates logisches Netzwerk für jeden OpenShift-Namespace.

n Es verbindet OpenShift-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 se-parate SNAT-IP für jeden OpenShift-Namespace zu.

Hinweis Bei der Konfiguration von NAT darf die Gesamtzahl der übersetzten IPs 1000 nicht über-schreiten.

n Es implementiert OpenShift-Netzwerkrichtlinien mit verteilter NSX-T-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 Bezeichnungsselek-toren für Netzwerkrichtlinien.

n Es implementiert eine OpenShift-Route mit NSX-T-Load Balancer der Schicht 7.

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

VMware, Inc. 5

n Unterstützung für Routen mit alternativen Backends und Unterdomänen als Platzhalter.

n Es erstellt auf dem logischen NSX-T-Switch-Port Tags für den Namespace, den Pod-Namen und dieBezeichnungen 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 OpenShift-Cluster.

Dieses Kapitel enthält die folgenden Themen:

n Kompatibilitätsanforderungen

n Überblick über die Installation

KompatibilitätsanforderungenNSX-T Container Plug-in (NCP) weist die folgenden Kompatibilitätsanforderungen auf.

Softwareprodukt Version

NSX-T 2.1, 2.2

Hypervisor für Container-Host-VMs n Unterstützte vSphere-Versionn RHEL KVM 7.4, 7.5

Container-Host-Betriebssystem RHEL 7.4, 7.5

Platform as a Service OpenShift 3.7, 3.9

Guest vSwitch OVS 2.8.1 (im Lieferumfang von NSX-T 2.1 enthalten), 2.9.1 (im Liefer-umfang von NSX-T 2.2 enthalten)

Überblick über die InstallationDas Installieren und Konfigurieren von NCP umfasst die folgenden Schritte. Zur erfolgreichen Durchfüh-rung der Schritte müssen Sie mit NSX-T sowie der Installation und Verwaltung von OpenShift vertrautsein.

1 Installieren Sie NSX-T.

2 Erstellen Sie eine Overlay-Transportzone.

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

4 Erstellen Sie einen logischen Tier-0-Router.

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

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

7 Stellen Sie OpenShift-VMs bereit.

8 Bereiten Sie die Ansible-Hostdatei vor.

9 (Option 1) Installieren Sie NCP und OpenShift mit einem einzelnen Playbook.

(Option 2) Installieren Sie CNI-Plug-In, OVS (Open vSwitch) und NCP-Docker-Image. Installieren Sieanschließend OpenShift Container Platform.


VMware, Inc. 6

http://partnerweb.vmware.com/comp_guide/sim/interop_matrix.php

10 Führen Sie NCP und den NSX-Knotenagent aus.

Die Schritte 2 bis 6 sind nicht erforderlich, wenn Sie NCP mit den bereitgestellten Playbooks installieren.Siehe Installieren von NCP und OpenShift mit einem einzelnen Playbook und Installieren von CNI-Plug-In, OVS und NCP-Docker-Image.


VMware, Inc. 7

Einrichten von NSX-T-Ressourcen 2Zum Bereitstellen der Netzwerkfunktionen für OpenShift-Knoten müssen NSX-T-Ressourcen erstellt wer-den. Sie können diese Ressourcen manuell über die NSX Manager-GUI konfigurieren oder den Prozessmithilfe eines Ansible Playbooks automatisieren.

In diesem Abschnitt wird die manuelle Erstellung der NSX-T-Ressourcen beschrieben. Informationen zumAutomatisieren des Vorgangs finden Sie unter Installieren von CNI-Plug-In, OVS und NCP-Docker-Image.


n Konfigurieren von NSX-T-Ressourcen

n Erstellen und Konfigurieren eines logischen Tier-0-Routers

Konfigurieren von NSX-T-RessourcenZu den zu konfigurierenden NSX-T-Ressourcen gehören eine Overlay-Transport-Zone, ein logischerTier-0-Router, ein logischer Switch zum Verbinden der virtuellen Maschinen des Knotens, IP-Blöcke fürKubernetes-Knoten und ein IP-Pool für SNAT.

Sie konfigurieren NSX-T-Ressourcen unter Verwendung von UUIDs oder Namen in der Konfigurationsda-tei ncp.ini.

Overlay-TransportzoneMelden Sie sich bei NSX Manager an und navigieren Sie zu Fabric > Transportzonen. Suchen Sie nachder für Containernetzwerke verwendeten Overlay-Transportzone oder erstellen Sie eine neue.

Geben Sie eine Overlay-Transportzone für einen Cluster an, indem Sie die Option overlay_tz im Ab-schnitt [nsx_v3] der Datei ncp.ini festlegen.

Logisches Tier-0-RoutingMelden Sie sich bei NSX Manager an und navigieren Sie zu Routing > Router. Suchen Sie nach dem fürContainernetzwerke verwendeten Router oder erstellen Sie einen neuen.

Geben Sie einen logischen Tier-0-Router für einen Cluster an, indem Sie die Option tier0_router imAbschnitt [nsx_v3] der Datei ncp.ini festlegen.

Hinweis Der Router muss im Aktiv/Standby-Modus erstellt werden.

VMware, Inc. 8

Logischer SwitchDie vom Knoten für den Netzwerkdatenverkehr verwendeten vNICs müssen mit einem logischen Overlay-Switch verbunden sein. Die Verwaltungsschnittstelle des Knotens muss nicht zwingend mit NSX-T ver-bunden sein, obwohl dies die Einrichtung erleichtert. Sie können einen logischen Switch erstellen, indemSie sich bei NSX Manager anmelden und zu Switching > Switches navigieren. Erstellen Sie auf demSwitch logische Ports und hängen Sie die vNICs des Knotens daran an. Die logischen Ports müssen diefolgenden Tags aufweisen:

n Geltungsbereich: ncp/cluster, Tag: <cluster_name>

n Geltungsbereich: ncp/node_name, Tag: <node_name>

Der Wert für <cluster_name> muss mit dem Wert der Option cluster im Abschnitt [coe] von ncp.iniübereinstimmen.

IP-Blöcke für Kubernetes-PodsMelden Sie sich bei NSX Manager an und navigieren Sie zu DDI > IPAM, um einen oder mehrere IP-Blöcke zu erstellen. Geben Sie den IP-Block im CIDR-Format an.

Geben Sie IP-Blöcke für Kubernetes-Pods an, indem Sie die Option container_ip_blocks im Abschnitt[nsx_v3] der Datei ncp.ini festlegen.

Sie können IP-Blöcke auch speziell für Nicht-SNAT-Namespaces erstellen.

Geben Sie Nicht-SNAT-IP-Blöcke ein, indem Sie die Option no_snat_ip_blocks im Abschnitt [nsx_v3]der Datei 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.

Hinweis Wenn Sie einen IP-Block erstellen, darf das Präfix nicht größer als der Wert des Parameterssubnet_prefix in der NCP-Konfigurationsdatei ncp.ini sein.

IP-Pool für SNATDer IP-Pool wird für die Zuteilung von IP-Adressen verwendet, die der Übersetzung von Pod-IP-Adressenüber SNAT-Regeln dienen. Zudem werden sie zum Verfügbarmachen der Ingress-Controller überSNAT/DNAT-Regeln verwendet – genau wie Openstack Floating IP-Adressen. Diese IP-Adressen werdenauch als „externe IP-Adressen“ bezeichnet.

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

Melden Sie sich bei NSX Manager an und navigieren Sie zu Bestand > Gruppen > IP-POOL, um einenPool zu erstellen oder nach einem vorhandenen Pool zu suchen.


VMware, Inc. 9

Geben Sie IP-Pools für SNAT an, indem Sie die Option external_ip_pools im Abschnitt [nsx_v3] derDatei ncp.ini festlegen.

Sie können SNAT auch für einen bestimmten Dienst konfigurieren, indem Sie dem Dienst eine Anmer-kung hinzufügen. Beispiel:

apiVersion: v1

kind: Service

metadata:

name: svc-example

annotations:

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

selector:

app: example

...

NCP konfiguriert die SNAT-Regel für diesen Dienst. Bei der Quell-IP der Regel handelt es sich um dieGruppe der Backend-Pods. Bei der Ziel-IP handelt es sich um die SNAT-IP, die aus dem angegebenenexternen IP-Pool zugeteilt wurde. Beachten Sie Folgendes:

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

n In NSX-T 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.

Ab Release NCP 2.2.1 können Sie durch Hinzufügen des folgenden Tags zum IP-Pool festlegen, wel-chem Namespace IPs aus dem SNAT-IP-Pool zugewiesen werden können.

n Geltungsbereich: ncp/owner, Tag: ns:<namespace_UUID>

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

oc get ns -o yaml

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 basierend auf den alten Tags IPs zuge-wiesen wurden, werden diese IPs nicht wiederhergestellt, bis sich die SNAT-Konfigurationen derDienste ändern oder NCP neu gestartet wird.

n Wenn der IP-Pool keine Owner-Tags aufweist, können allen Diensten IPs aus dem Pool zugewiesenwerden.

(Optional) Markierte FirewallabschnitteDamit der Administrator Firewallregeln erstellen kann und diese die von NCP erstellten, auf Netzwer-krichtlinien basierenden Firewallabschnitte nicht beeinträchtigen, melden Sie sich bei NSX Manager an,navigieren Sie zu Firewall > Allgemein und erstellen Sie zwei Firewallabschnitte.


VMware, Inc. 10

Geben Sie Firewall-Markierungsabschnitte an, indem Sie die Optionen bottom_firewall_secti-on_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 Fi-rewallabschnitte erstellt sind, werden alle von NCP zur Isolierung erstellten Firewallabschnitte oberhalbdes unteren Firewallabschnitts und alle von NCP für Richtlinien erstellten Firewallabschnitte unterhalbdes oberen Firewallabschnitts erstellt. Wenn diese Markierungsabschnitte nicht erstellt werden, werdenalle Isolierungsregeln unten und alle Richtlinienabschnitte oben erstellt. Mehrere markierte Firewallab-schnitte mit demselben Wert pro Cluster werden nicht unterstützt und führen zu einem Fehler.

Erstellen und Konfigurieren eines logischen Tier-0-RoutersDer logische Tier-0-Router verbindet die Kubernetes-Knoten mit externen Netzwerken.

Verfahren

1 Melden Sie sich über einen Browser bei NSX Manager unter https://nsx-manager-ip-address an.

2 Navigieren Sie zu Routing > Router, und klicken Sie auf Hinzufügen > Tier-0-Router.

3 Geben Sie einen Namen und optional eine Beschreibung ein.

4 Wählen Sie im Dropdown-Menü einen vorhandenen Edge-Cluster für eine Unterstützung dieses logi-schen Tier-0-Routers aus.

5 Wählen Sie einen Modus für die Hochverfügbarkeit aus.

Wählen Sie den Aktiv/Standby-Modus aus.

6 Klicken Sie auf Speichern.

Der neue logische Router wird als Link angezeigt.

7 Klicken Sie auf den Link für den logischen Router.

8 Klicken Sie auf Routing > Route Redistribution.

9 Klicken Sie auf Hinzufügen, um ein neues Kriterium für die Neuverteilung hinzuzufügen.

Wählen Sie für Quellen in einer gerouteten (Nicht-NAT-) Topologie NSX statisch aus. Wählen Sie ineiner NAT-Topologie Tier-0 NAT aus.


11 Klicken Sie auf den neu erstellten Router.

12 Klicken Sie auf Konfiguration > Router-Ports.

13 Klicken Sie auf Hinzufügen, um einen Uplink-Port hinzuzufügen.

14 Wählen Sie einen Transportknoten aus.

15 Wählen Sie den zuvor erstellten logischen Switch aus.

16 Geben Sie eine IP-Adresse in Ihrem externen Netzwerk an.


VMware, Inc. 11


Der neue logische Router wird als Link angezeigt.


VMware, Inc. 12

Einrichten des NSX-T ContainerPlug-Ins und von OpenShift 3In diesem Kapitel wird das Installieren und Konfigurieren von NSX-T Container Plug-in (NCP) und Open-Shift beschrieben.


n Bereitstellen von OpenShift-VMs

n Vorbereiten der Ansible-Hostdatei

n Installieren von NCP und OpenShift mit einem einzelnen Playbook

n Installieren von CNI-Plug-In, OVS und NCP-Docker-Image

n Installieren von OpenShift Container Platform

n Ausführen des NCP- und NSX-Knotenagenten

n Hinweise zur Einrichtung

Bereitstellen von OpenShift-VMsVor der Installation von NSX-T Container Plug-in muss OpenShift installiert werden. Sie müssen mindes-tens einen Master bereitstellen.

Weitere Informationen finden Sie unter https://docs.openshift.com.

Nächste Schritte

Bereiten Sie die Ansible-Hostdatei vor. Siehe Vorbereiten der Ansible-Hostdatei.

Vorbereiten der Ansible-HostdateiDie Ansible-Datei hosts definiert die Knoten im OpenShift-Cluster.

Verfahren

1 Klonen Sie das NCP-GitHub-Repository unter https://github.com/vmware/nsx-integration-for-open-shift. Die Datei hosts befindet sich im Verzeichnis openshift-ansible-nsx. Sie müssen die Dateihosts im Verzeichnis openshift-ansible-nsx beibehalten. Einige Playbooks gehen davon aus,dass dies der Pfad für die hosts-Datei ist.

VMware, Inc. 13

https://docs.openshift.com

https://github.com/vmware/nsx-integration-for-openshift

https://github.com/vmware/nsx-integration-for-openshift

2 Geben Sie in den [master]- und [nodes]-Abschnitten die Hostnamen und IP-Adressen der virtuellenOpenShift-Maschinen an. Beispiel:

[masters]

admin.rhel.osmaster ansible_ssh_host=101.101.101.4

[single_master]

admin.rhel.osmaster ansible_ssh_host=101.101.101.4

[nodes]

admin.rhel.osmaster ansible_ssh_host=101.101.101.4 openshift_ip=101.101.101.4 openshift_schedu-

lable=true openshift_hostname=admin.rhel.osmaster

admin.rhel.osnode ansible_ssh_host=101.101.101.5 openshift_ip=101.101.101.5 openshift_hostna-

me=admin.rhel.osnode

[etcd]

[OSEv3:children]

masters

nodes

etcd

Beachten Sie, dass openshift_ip die interne Cluster-IP-Adresse identifiziert und festgelegt werdenmuss, wenn die zu verwendende Schnittstelle nicht die Standardkonfiguration ist. Die Variable sin-gle_master wird von ncp-bezogenen Rollen aus einem Master-Knoten für bestimmte Aufgaben nureinmal verwendet, z. B. für die Ressourcenkonfiguration der NSX-T-Managementebene.

3 Richten Sie den SSH-Zugriff so ein, dass der Zugriff auf alle Knoten ohne Kennwort von dem Knotenaus möglich ist, auf dem die Ansible-Rolle ausgeführt wird (in der Regel ist dies der Master-Knoten):

ssh-keygen

ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]

4 Aktualisieren Sie den Abschnitt [OSEv3:vars]. Details über sämtliche Parameter finden Sie in der Do-kumentation zu OpenShift Container Platform für die erweiterte Installation (suchen Sie nach „advan-ced installation“ in https://docs.openshift.com). Beispiel:

# Set the default route fqdn

openshift_master_default_subdomain=apps.corp.local

os_sdn_network_plugin_name=cni

openshift_use_openshift_sdn=false

openshift_node_sdn_mtu=1500

# If ansible_ssh_user is not root, ansible_become must be set to true

ansible_become=true

openshift_master_default_subdomain

This is the default subdomain used in the OpenShift routes for External LB

os_sdn_network_plugin_name

Set to 'cni' for the NSX Integration


VMware, Inc. 14


openshift_use_openshift_sdn

Set to false to disable the built-in OpenShift SDN solution

openshift_hosted_manage_router

Set to false to disable creation of router during installation. The router has to be manual-

ly started after NCP and nsx-node-agent are running.

openshift_hosted_manage_registry

Set to false to disable creation of registry during installation. The registry has to be

manually started after NCP and nsx-node-agent are running.

deployment_type

Set to openshift-enterprise

openshift_hosted_manage_registry

Set to false to disable auto creation of registry

openshift_hosted_manage_router

Set to false to disable auto creation of router

openshift_enable_service_catalog

Set to false to disable service_catalog

(For OpenShift 3.9 only) skip_sanity_checks

Set to true

(For OpenShift 3.9 only) openshift_web_console_install

Set to false

5 Überprüfen Sie, ob eine Verbindung zu allen Hosts besteht:

ansible OSEv3 -i /PATH/TO/HOSTS/hosts -m ping

Die Ergebnisse sollte wie folgt aussehen. Falls dies nicht der Fall ist, beheben Sie das Konnektivität-sproblem.

openshift-node1 | SUCCESS => {

"changed": false,

"ping": "pong"

}

openshift-master | SUCCESS => {

"changed": false,

"ping": "pong"

}

Nächste Schritte

Installieren Sie das CNI-Plugin und OVS. Siehe Installieren von CNI-Plug-In, OVS und NCP-Docker-Image.


VMware, Inc. 15

Installieren von NCP und OpenShift mit einem einzelnenPlaybookSie können NCP und OpenShift mit einem einzelnen Playbook installieren oder die Installation in separa-ten Schritten ausführen.

Das einzelne Ansible Playbook install.yaml führt die folgenden Aufgaben durch:

n NCP-Vorbereitung

n OpenShift-Installation

n NCP-Installation

Alternativ dazu können Sie NCP und OpenShift anhand der Anweisungen in den folgenden zwei Ab-schnitte installieren: Installieren von CNI-Plug-In, OVS und NCP-Docker-Image und Installieren vonOpenShift Container Platform.

Legen Sie vor dem Ausführen des install.yaml-Playbooks die erforderlichen und optionalen Parameterfür die Playbook-Rollen ncp_prep und ncp fest. Die Parameter sind in Installieren von CNI-Plug-In, OVSund NCP-Docker-Image beschrieben.

Der folgende Befehl führt das Playbook aus:

ansible-playbook -i /PATH/TO/HOSTS/hosts install.yaml

Installieren von CNI-Plug-In, OVS und NCP-Docker-ImageDas CNI(Container Network Interface)-Plug-In, Open vSwitch (OVS) und das NCP-Docker-Image müssenauf den OpenShift-Knoten installiert sein. Die Installation erfolgt durch die Ansible Playbook-Ausführung.

Hinweis Dieser Schritt ist nicht erforderlich, wenn Sie NCP und OpenShift mit einem einzelnen Play-book installieren. Siehe Installieren von NCP und OpenShift mit einem einzelnen Playbook.

Das Playbook enthält Anweisungen zum Konfigurieren von NSX-T-Ressourcen für die Knoten. Sie kön-nen die NSX-T-Ressourcen auch manuell konfigurieren, wie unter Kapitel 2Einrichten von NSX-T-Res-sourcen beschrieben. Der Parameter perform_nsx_config gibt an, ob die Ressourcen bei der Play-book-Ausführung konfigurieren werden oder nicht.


VMware, Inc. 16

Verfahren

1 Aktualisieren Sie die Parameterwerte in roles/ncp_prep/default/main.yaml und ro-les/nsx_config/default/main.yaml, einschließlich der URLs, unter denen das CNI-Plug-In RPM,OVS und das entsprechende Kernelmodul RPM heruntergeladen werden können. Darüber hinaus istuplink_port der Name der virtuellen Netzwerkkarte des Uplink-Ports auf dem VM-Knoten. Die ver-bleibenden Variablen beziehen sich auf die Konfiguration der NSX-T-Managementebene.

Parameter, die angegeben werden müssen:

n perform_nsx_config: gibt an, ob die Ressourcenkonfiguration durchgeführt wird. Legen Sie dieEinstellung auf „false“ fest, wenn die Konfiguration manuell vorgenommen und das Skriptnsx_config nicht ausgeführt wird.

n nsx_manager_ip: IP-Adresse des NSX Manager

n nsx_edge_cluster_name: Name des Edge-Clusters für die Verwendung durch den Tier-0-Router

n nsx_transport_zone_name: Name der Overlay-Transportzone

n os_node_name_list: kommagetrennte Liste der Knotennamen

Zum Beispiel node1,node2,node3

n subnet_cidr: CIDR-Adresse für IP-Administrator, die „br-int“ auf dem Knoten zugewiesen wird

n vc_host: IP-Adresse von vCenter Server

n vc_user: Benutzername des vCenter Server-Administrators

n vc_password: Kennwort des vCenter Server-Administrators

n vms: kommagetrennte Liste der VM-Namen. Die Reihenfolge muss mit os_node_name_listübereinstimmen.

Die folgenden Parameter weisen Standardwerte auf. Sie können diese je nach Bedarf ändern.

n nsx_t0_router_name: Name des logischen Tier-0-Routers für den Cluster. Standard: t0

n pod_ipblock_name: Name des IP-Blocks für Pods. Standard: podIPBlock

n pod_ipblock_cidr: CIDR-Adresse für diesen IP-Block. Standard: 172.20.0.0/16

n snat_ippool_name: Name des IP-Blocks für SNAT. Standard: externalIP.

n snat_ippool_cidr: CIDR-Adresse für diesen IP-Block. Standard: 172.30.0.0/16

n start_range: die für diesen IP-Pool angegebene IP-Startadresse von CIDR. Standard:172.30.0.1

n end_range: die für diesen IP-Pool angegebene IP-Endadresse von CIDR. Standard:172.30.255.254

n os_cluster_name: Name des OpenShift-Clusters. Standard: occl-one

n nsx_node_ls_name: Name des logischen Switches, der mit den Knoten verbunden ist. Standard:node_ls


VMware, Inc. 17

n nsx_node_lr_name: Name des logischen Routers für den Switch node_ls. Standard: node_lr

Das nsx-config-Playbook unterstützt nur die Erstellung jeweils eines IP-Pools und eines IP-Blocks.Wenn Sie weitere Pools und Blöcke benötigen, müssen Sie diese manuell erstellen.

2 Wechseln Sie zum Verzeichnis openshift-ansible-nsx, und führen Sie die Rolle ncp_prep aus.

ansible-playbook -i /PATH/TO/HOSTS/hosts ncp_prep.yaml

Das Playbook enthält Anweisungen zum Ausführen der folgenden Aktionen:

n Laden Sie die Installationsdatei für das CNI-Plug-In herunter.

Der Dateiname lautet nsx-cni-1.0.0.0.0.xxxxxxx-1.x86_64.rpm, wobei xxxxxxx die Build-Num-mer ist.

n Installieren Sie die Installationsdatei für das CNI-Plug-In.

Das Plugin wird unter /opt/cni/bin installiert. Die CNI-Konfigurationsdatei „10.net.conf“ wirdnach /etc/cni/net.d kopiert. RPM installiert auch die Konfigurationsdatei /etc/cni/net.d/99-loopback.conf für das Loopback-Plugin.

n Laden Sie die OVS-Installationsdateien herunter, und installieren Sie sie.

Die Dateien lauten openvswitch-2.7.0.xxxxxxx-1.x86_64.rpm und openvswitch-kmod-2.7.0.xxxxxxx-1.el7.x86_64.rpm, wobei xxxxxxx die Build-Nummer ist.

n Stellen Sie sicher, dass OVS ausgeführt wird.

# service openvswitch-switch status

n Erstellen Sie die br-int-Instanz, sofern dies noch nicht erfolgt ist.

# ovs-vsctl add-br br-int

n Fügen Sie die Netzwerkschnittstelle (node-if) hinzu, die mit dem logischen Switch des Knotens für br-int verbunden ist.

n Stellen Sie sicher, dass br-int und node-if link einen aktiven Status aufweisen.

# ip link set br-int up

# ip link set <node-if> up

n Aktualisieren Sie die Netzwerkkonfigurationsdatei, um sicherzustellen, dass die Netzwerkschnittstellenach einem Neustart aktiv ist.

n Laden Sie die TAR-Datei für NCP herunter und laden Sie das Docker-Image aus der TAR-Datei.

n Laden Sie die YAML-Datei ncp-rbac herunter und ändern Sie apiVersion in v1.

n Erstellen Sie eine logische Topologie und zugehörige Ressourcen in NSX-T und erstellen Sie Tagsauf diesen, damit sie von NCP erkannt werden.

n Aktualisieren Sie ncp.ini mit Informationen zur NSX-T-Ressource.


VMware, Inc. 18

Nächste Schritte

Installieren Sie OpenShift Container Platform. Siehe Installieren von OpenShift Container Platform.

Installieren von OpenShift Container PlatformOpenShift Container Platform (OCP) ist ein PaaS-Produkt (Platform as a Service), das Docker undKubernetes verbindet.

Hinweis Dieser Schritt ist nicht erforderlich, wenn Sie NCP und OpenShift mit einem einzelnen Play-book installieren. Siehe Installieren von NCP und OpenShift mit einem einzelnen Playbook.

Informationen zum Installieren von OCP finden Sie unter https://docs.openshift.com.

Nächste Schritte

Führen Sie NCP und den NSX-Knotenagent aus. Siehe Ausführen des NCP- und NSX-Knotenagenten.

Ausführen des NCP- und NSX-KnotenagentenRichten Sie den NCP- und NSX-Knotenagent ein, und führen Sie ihn aus.

Verfahren

1 Bearbeiten Sie roles/ncp/defaults/main.yaml, und geben Sie die IP-Adresse des OpenShift-API-Servers, die IP-Adresse von NSX Manager und die URLs zum Herunterladen der YAML-Datei fürNCP ReplicationController und für DaemonSet für „nsx-node-agent“ an.

2 Führen Sie im Verzeichnis „openshift-ansible-nsx“ ncp-Rolle aus:

ansible-playbook -i /PATH/TO/HOSTS/hosts ncp.yaml

Die ncp-Rolle führt die folgenden Schritte aus:

n Überprüfen Sie, ob das Projekt „nsx-system“ vorhanden ist, und erstellen Sie es, wenn dies nicht derFall ist.

oc new-project nsx-system

n Laden Sie die YAML-Datei ncp-rbac herunter und ändern Sie apiVersion in v1.

n Erstellen Sie das Dienstkonto für den NCP-Pod, erstellen Sie eine Clusterrolle, die die Ressourcenfestlegt, auf die NCP zugreifen kann, und binden Sie die Clusterrolle an das NCP-Dienstkonto.

n Erstellen Sie das Dienstkonto für den nsx-node-agent-Pod, erstellen Sie eine Clusterrolle, die dieRessourcen festlegt, auf die der Knotenagent zugreifen kann, und binden Sie die Clusterrolle an dasKnotenagent-Dienstkonto.

oc apply -f /tmp/ncp-rbac.yml


VMware, Inc. 19


n Rufen Sie das Token ab, das mit dem oben genannten Dienstkonto verknüpft ist, und speichern Siees unter /etc/nsx-ujo/<service_account>_token:

secret=`kubectl get serviceaccount ncp-svc-account -o yaml | grep -A1 secrets | tail -n1 | awk

{'print $3'}`

kubectl get secret $secret -o yaml | grep 'token:' | awk {'print $2'} | base64 -d > /etc/nsx-

ujo/ncp_token

secret=`kubectl get serviceaccount nsx-node-agent-svc-account -o yaml | grep -A1 secrets |

tail -n1 | awk {'print $3'}`

kubectl get secret $secret -o yaml | grep 'token:' | awk {'print $2'} | base64 -d > /etc/nsx-

ujo/node_agent_token

n Laden Sie die SecurityContextConstraint (SCC)-YAML-Datei für NCP herunter, und erstellen Sie dasSCC-Objekt basierend auf der YAML-Datei.

n Fügen Sie das erstellte SCC-Objekt den oben genannten Dienstkonten hinzu:

oadm policy add-scc-to-user ncp-scc -z ncp-svc-account

oadm policy add-scc-to-user ncp-scc -z nsx-node-agent-svc-account

n Laden Sie die YAML-Dateien für NCP ReplicationController (RC) und nsx-node-agent DaemonSet(DS) herunter und aktualisieren Sie die ConfigMap.

n Laden Sie das NCP-Image herunter (nsx-node-agent verwendet dasselbe Image), und laden Sie es.

n Konfigurieren Sie das Dienstkonto, und richten Sie das erforderliche SecurityContextConstraint-Ob-jekt für NCP und nsx_node_agent ein.

n Erstellen Sie den NCP ReplicationController und das nsx-node-agent DaemonSet.

Hinweis NCP öffnet dauerhafte HTTP-Verbindungen zum Kubernetes-API-Server, um Lebenszykluse-reignisse von Kubernetes-Ressourcen zu überwachen. Wenn ein API-Serverausfall oder ein Netzwerk-ausfall dazu führt, dass TCP-Verbindungen von NCP verfallen, müssen Sie NCP neu starten, sodass esdie Verbindungen zum API-Server wiederherstellen kann. Andernfalls verpasst NCP die neuen Ereignis-se.

Hinweise zur EinrichtungBeachten Sie vor dem Einrichten von OpenShift und NCP die folgenden Informationen.

n Ein Pod darf nicht mehr als 11 Bezeichnungen haben, und ein Namespace darf nicht mehr als 12 Be-zeichnungen aufweisen.


VMware, Inc. 20

n Hinzugefügte Bezeichnungen für die interne Verwendung von OpenShift, z. B. eine Bezeichnung mitPräfix „openshift.io“ im zugehörigen Schlüssel, werden von NCP ignoriert. Demzufolge werden demBenutzer die entsprechenden Tags, die auf den entsprechenden NSX-Ressourcen erstellt wurden,nicht angezeigt. Hier finden Sie eine Liste mit von OpenShift verwendeten Bezeichnungspräfixen.Vermeiden Sie die Verwendung eines Bezeichnungsschlüssels, der wie folgt beginnt:

openshift.io

pod-template

n Die Knoten benötigen Zugriff auf die Pods, beispielsweise für Kubelet-Integritätsprüfungen. StellenSie sicher, dass die Host-Verwaltungsschnittstelle auf das Pod-Netzwerk zugreifen kann.

n Die Linux-Funktionen NET_ADMIN und NET_RAW können von Angreifern ausgenutzt werden, umdas Pod-Netzwerk zu gefährden. Sie sollten diese beiden Funktionen der nicht vertrauenswürdigenContainer deaktivieren. Standardmäßig erhält NET_ADMIN bei SCC mit „restricted“ und „anyuid“ kei-nen Zugriff. Seien Sie vorsichtig bei einem SCC-Objekt, das NET_ADMIN explizit aktiviert oder diePod-Ausführung im privilegierten Modus ermöglicht. Erstellen Sie darüber hinaus für nicht vertrauens-würdige Container ein separates SCC-Objekt, z. B. basierend auf SCC mit „anyuid“, und entfernenSie dabei die Funktion NET_RAW. Dies kann durch Hinzufügen von NET_RAW zu der Liste „Requi-redDropCapabilities“ in der SCC-Definition erfolgen.

n Im Ansible Playbook für das Upgrade von OpenShift 3.6 auf 3.7 liegt ein Fehler vor. Die Einstellungopenshift_use_openshift_sdn=false in der Bestandsdatei wird ignoriert, und beim Upgrade wirdversucht, die standardmäßige OpenShift-SDN zu installieren. Um dieses Problem zu umgehen, ent-fernen Sie vor dem Upgrade das CNI-Plug-In und installieren Sie es erneut nach dem Upgrade.

n Erlauben Sie den Root-Zugriff in PODs/Containern (nur zu Testzwecken). Die unten aufgeführten Be-fehle benötigen Root-Zugriff in allen PODs des oc-Projekts, bei dem Sie aktuell angemeldet sind.

oc new-project test-project

oc project test-project

oadm policy add-scc-to-user anyuid -z default

n Konfigurieren Sie die OpenShift-Registrierung (fügen Sie sie hinzu).

oc login -u system:admin -n default

oadm registry --service-account=registry --config=/etc/origin/master/admin.kubeconfig

n Löschen der OpenShift-Registrierung

oc login -u system:admin -n default

oc delete svc/docker-registry dc/docker-registry


VMware, Inc. 21

n Es fehlt eine IPtables-Firewallregel zum Zulassen von DNS-Anforderungen von Docker-Standard-Bridge-Containern für den dnsmasq-Prozess auf dem Knoten. Sie muss manuell geöffnet werden.Bearbeiten Sie /etc/sysconfig/iptables, und fügen Sie am Ende der Datei vor COMMIT die fol-genden Regeln hinzu:

-A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT

-A OS_FIREWALL_ALLOW -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT

COMMIT

n Starten Sie iptables, docker und origin-node neu (Kube-Proxy und Kubelet werden neu gestartet).

systemctl restart iptables

systemctl restart docker

systemctl restart origin-node

n Die interne Docker-Registrierung von OpenShift muss Nicht-TLS verwenden können, damit Open-Shift funktioniert. In der Regel sollte dies automatisch vom OpenShift Ansible-Installationsprogrammhinzugefügt werden. Momentan scheint dies aber nicht zu funktionieren. Bearbeiten Sie „/etc/syscon-fig/docker“ und fügen Sie Folgendes hinzu:

INSECURE_REGISTRY='--insecure-registry 172.30.0.0/16'

n Starten Sie Docker neu.

systemctl restart docker

n Die NCP-Unterstützung für Netzwerkrichtlinien entspricht der von Kubernetes bereitgestellten Unter-stützung und richtet sich nach der von OpenShift verwendeten Kubernetes-Version.

n OpenShift 3.7, 3.9 – Die Regelklauseln in der Netzwerkrichtlinie können höchstens einen Selektoraus namespaceSelector, podSelector und ipBlock enthalten.

n OpenShift 3.7 – Unterstützung für Egress-Regeln und den CIDR-Selektor ipBlock steht nicht zurVerfügung. Sie stehen als Betafelder in OpenShift 3.9 zur Verfügung.

n Bestimmte Kubernetes-Versionen weisen ein auf subPath bezogenes Problem auf (siehe https://gi-thub.com/kubernetes/kubernetes/issues/61076). Wenn die OpenShift-Version keinen Fix für diesesProblem enthält, schlägt die Erstellung des NCP-Pods mit folgendem Fehler fehl: CreateContainer-ConfigError: subPath für volumeMount konnte nicht vorbereitet werden. Sie könnendieses Problem umgehen, indem Sie die Verwendung von subPath aus der NCP-YAML-Datei entfer-nen. Entfernen Sie insbesondere die Zeile mit subPath: ncp.ini und ersetzen Sie die Konfigurationfür volumes durch Folgendes:

volumes:

- name: config-volume

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

configMap:


VMware, Inc. 22

https://github.com/kubernetes/kubernetes/issues/61076

https://github.com/kubernetes/kubernetes/issues/61076

name: nsx-ncp-config

items:

- key: ncp.ini

path: ncp.ini

Ein Nebeneffekt dieser Änderung besteht darin, dass das gesamte /etc/nsx-ujo-Verzeichnis mit ei-nem Schreibschutz versehen wird. Dies führt dazu, dass eine Verbindung mit NSX-T über ein Zertifi-kat und einen privaten Schlüssel nicht funktioniert, da NCP kein temporäres Verzeichnis un-ter /etc/nsx-ujo erstellen kann, um Zertifikat und privaten Schlüssel in eine einzige Datei zu ver-schieben.


VMware, Inc. 23

Lastausgleich 4Der NSX-T-Load Balancer ist in OpenShift integriert und fungiert als OpenShift-Router.

NCP überwacht OpenShift-Routen- und -Endpoint-Ereignisse und konfiguriert Lastausgleichsregeln aufdem Load Balancer basierend auf der Routenspezifikation. Dies führt dazu, das der NSX-T-Load Balan-cer eingehenden Schicht 7-Datenverkehr basierend auf den Regeln zu den geeigneten Backend-Podsweiterleitet.

Konfigurieren des LastausgleichsDas Konfigurieren des Lastausgleichs umfasst das Konfigurieren eines Kubernetes-LoadBalancer-Diensts oder einer OpenShift-Route. Sie müssen auch den NCP ReplicationController konfigurieren. DerLoadBalancer-Dienst wird für den Schicht 4-Datenverkehr und die OpenShift-Route für den Schicht 7-Da-tenverkehr verwendet.

Wenn Sie einen Kubernetes-LoadBalancer-Dienst konfigurieren, wird diesem eine IP-Adresse aus demvon Ihnen konfigurierten externen IP-Block zugeteilt. Der Load Balancer wird auf dieser IP-Adresse unddem Dienst-Port bereitgestellt. Sie können den Namen oder die ID eines IP-Pools mithilfe der loadBa-lancerIP-Spezifikation in der Definition des LoadBalancer-Diensts angeben. Die IP-Adresse des Load-Balancer-Diensts wird aus diesem IP-Pool zugeteilt. Wenn die loadBalancerIP-Spezifikation leer ist,wird die IP-Adresse aus dem externen IP-Block zugeteilt, den Sie konfigurieren.

Um den Load Balancer von NSX-T zu verwenden, müssen Sie den Lastausgleich in NCP konfigurieren.Führen Sie in der Datei ncp_rc.yml die folgenden Schritte aus:

1 Legen Sie use_native_loadbalancer = True fest.

2 Legen Sie pool_algorithm auf WEIGHTED_ROUND_ROBIN fest.

3 Legen Sie „lb_default_cert_path“ und „lb_priv_key_path“ als vollständige Pfadnamen des von derZertifizierungsstelle signierten Zertifikats und der Datei mit dem privaten Schlüssel fest. Ein Beispiel-skript zum Generieren eines von einer Zertifizierungsstelle signierten Zertifikats finden Sie unten.Mounten Sie darüber hinaus das Standardzertifikat und den Standardschlüssel in den NCP-Pod. An-weisungen hierzu finden Sie unten.

4 (Optional) Legen Sie service_size = SMALL, MEDIUM oder LARGE fest. Die Standardeinstellung istSMALL.

VMware, Inc. 24

Beispiel für einen Load Balancer auf Schicht 7:Zur Bereitstellung des Lastausgleichs auf Schicht 7 konfiguriert die folgende YAML-Datei zwei Replikati-ons-Controller (tea-rc und coffee-rc), zwei Dienste (tea-svc und coffee-svc) sowie zwei Routen (cafe-rou-te-multi und cafe-route).

# RC

apiVersion: v1

kind: ReplicationController

metadata:

name: tea-rc

spec:

replicas: 2

template:

metadata:

labels:

app: tea

spec:

containers:

- name: tea

image: nginxdemos/hello

imagePullPolicy: IfNotPresent

ports:

- containerPort: 80

---

apiVersion: v1

kind: ReplicationController

metadata:

name: coffee-rc

spec:

replicas: 2

template:

metadata:

labels:

app: coffee

spec:

containers:

- name: coffee

image: nginxdemos/hello

imagePullPolicy: IfNotPresent

ports:

- containerPort: 80

---

# Services

apiVersion: v1

kind: Service

metadata:

name: tea-svc

labels:

app: tea

spec:

ports:

- port: 80


VMware, Inc. 25

targetPort: 80

protocol: TCP

name: http

selector:

app: tea

---

apiVersion: v1

kind: Service

metadata:

name: coffee-svc

labels:

app: coffee

spec:

ports:

- port: 80

targetPort: 80

protocol: TCP

name: http

selector:

app: coffee

---

# Routes

apiVersion: v1

kind: Route

metadata:

name: cafe-route-multi

spec:

host: www.cafe.com

path: /drinks

to:

kind: Service

name: tea-svc

weight: 1

alternateBackends:

- kind: Service

name: coffee-svc

weight: 2

---

apiVersion: v1

kind: Route

metadata:

name: cafe-route

spec:

host: www.cafe.com

path: /tea-svc

to:

kind: Service

name: tea-svc

weight: 1


VMware, Inc. 26

Zusätzliche Hinweisen In dieser Version wird Lastausgleich nur über die OpenShift-Routenressource unterstützt, jedoch

nicht die Dienstressource des Typs LoadBalancer.

n Nur die Edge-Beendigung wird für HTTPS-Datenverkehr unterstützt.

n Unterdomänen als Platzhalter werden unterstützt. Wenn zum Beispiel wildcardPolicy aufUnterdomäne und der Hostname auf wildcard.example.com festgelegt ist, werden alle Anforderun-gen an *.example.com verarbeitet.

n Wenn NCP aufgrund einer fehlerhaften Konfiguration einen Fehler während der Verarbeitung einesRouten-Ereignisses auslöst, müssen Sie die YAML-Datei der Route korrigieren und die Routen-Res-source löschen und neu erstellen.

n NCP erzwingt den Hostnamen-Besitz nicht nach Namespaces.

n Ein LoadBalancer-Dienst wird pro Kubernetes-Cluster unterstützt.

n NSX-T erstellt einen Load Balancer auf Schicht 4 für jeden LoadBalancer-Dienst-Port. TCP und UDPwerden unterstützt.

n Der Load Balancer von NSX-T ist in verschiedenen Größen erhältlich. Weitere Informationen zumKonfigurieren eines Load Balancers für NSX-T finden Sie im NSX-T-Administratorhandbuch.

Der kleine Load Balancer von NSX-T unterstützt Folgendes:

n 10 virtuelle NSX-T-Server

n 10 NSX-T-Pools

n 30 NSX-T-Poolmitglieder

n 8 Ports für LoadBalancer-Dienste.

n Insgesamt 10 von den LoadBalancer-Diensten und Routenressourcen definierte Ports.

n Insgesamt 30 von den LoadBalancer-Diensten und Routenressourcen referenzierte Endpoints.

Der mittlere Load Balancer von NSX-T unterstützt Folgendes:


n 100 NSX-T-Pools





Der große Load Balancer von NSX-T unterstützt Folgendes:


n 1000 NSX-T-Pools


VMware, Inc. 27





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

Beispielskript zum Generieren eines von einer Zertifizierungsstellesignierten ZertifikatsDas nachfolgende Skript generiert ein von einer Zertifizierungsstelle signiertes Zertifikat und einen priva-ten in den Dateien <Dateiname>.crt und <Dateiname>.key gespeicherten privaten Schlüssel. Der Befehlgenrsa generiert einen Zertifizierungsstellen-Schlüssel. Der Zertifizierungsstellen-Schlüssel muss ver-schlüsselt werden. Sie können eine Verschlüsselungsmethode mit einem Befehl wie zum Beispiel aes256angeben.

#!/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 ${filena-

me}.crt -sha256

Mounten Sie das Standardzertifikat und den Standardschlüssel inden NCP-PodWenn Sie das Zertifikat und den privaten Schlüssel erstellt haben, platzieren Sie sie im Verzeich-nis /etc/nsx-ujo auf dem VM-Host. Vorausgesetzt, dass die Zertifikats- und Schlüsseldateien die Na-men lb-default.crt und lb-default.key aufweisen, bearbeiten Sie ncp-rc.yaml , sodass diese Da-teien auf dem Host in den Pod gemountet werden. Beispiel:

spec:

...

containers:

- name: nsx-ncp

...

volumeMounts:

...

- name: lb-default-cert

# Mount path must match nsx_v3 option "lb_default_cert_path"

mountPath: /etc/nsx-ujo/lb-default.crt


VMware, Inc. 28

- name: lb-priv-key

# Mount path must match nsx_v3 option "lb_priv_key_path"

mountPath: /etc/nsx-ujo/lb-default.key

volumes:

...

- name: lb-default-cert

hostPath:

path: /etc/nsx-ujo/lb-default.crt

- name: lb-priv-key

hostPath:

path: /etc/nsx-ujo/lb-default.key


VMware, Inc. 29

Verwalten vonNSX-T Container Plug-in 5Sie können NSX-T 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 ei-nen 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-IDs 4093 und 4094 auf dem Hypervisor für die PVLAN-Konfiguration, unddie IDs können nicht geändert werden. Um VLAN-Konflikte zu vermeiden, konfigurieren Sie logischeVLAN-Switches oder VTEP-vmknics mit denselben VLAN-IDs.


n Verwalten von IP-Blöcken über die NSX Manager-GUI

n Verwalten von IP-Block-Subnetzen über die GUI von NSX Manager

n CIF-verknüpfte logische Ports

n CLI-Befehle

n Fehlercodes

Verwalten von IP-Blöcken über die NSX Manager -GUISie können die Tags für einen IP-Block über die NSX Manager-GUI hinzufügen, löschen, bearbeiten, ver-walten und die zugehörigen Details anzeigen.

Verfahren

1 Melden Sie sich über einen Browser bei NSX Manager unter https://<nsx-manager-IP-address-or-domain-name> an.

2 Wählen Sie DDI aus.

Es wird eine Liste der vorhandenen IP-Blöcke angezeigt.

VMware, Inc. 30

3 Führen Sie eine der folgenden Aktionen durch.

Option Aktion

Hinzufügen eines IP-Blocks Klicken Sie auf HINZUFÜGEN.

Löschen eines oder mehrerer IP-Blö-cke

Wählen Sie einen oder mehrere IP-Blöcke aus, und klicken Sie auf LÖSCHEN.

Bearbeiten eines IP-Blocks Wählen Sie einen IP-Block aus, und klicken Sie auf BEARBEITEN.

Anzeigen von Details zu einem IP-Block

Klicken Sie auf den Namen des IP-Blocks. Klicken Sie auf die RegisterkarteÜbersicht, um allgemeine Informationen anzuzeigen. Klicken Sie auf die Regis-terkarte Subnetze, um die Subnetze dieses IP-Blocks anzuzeigen.

Verwalten von Tags für einen IP-Block Wählen Sie einen IP-Block aus, und klicken Sie auf AKTIONEN > Tags verwal-ten.

IP-Blöcke mit zugeteilten Subnetzen können nicht gelöscht werden.

Verwalten von IP-Block-Subnetzen über die GUI von NSXManagerSie können Subnetze für einen IP-Block über die NSX Manager-GUI hinzufügen und löschen.

Verfahren

1 Melden Sie sich über einen Browser bei NSX Manager unter https://<nsx-manager-IP-address-or-domain-name> an.

2 Wählen Sie DDI aus.

Es wird eine Liste der vorhandenen IP-Blöcke angezeigt.

3 Klicken Sie auf den Namen eines IP-Blocks.

4 Klicken Sie auf die Registerkarte Subnetze.

5 Führen Sie eine der folgenden Aktionen durch.

Option Aktion

Hinzufügen eines IP-Block-Subnetzes Klicken Sie auf HINZUFÜGEN.

Löschen eines oder mehrerer IP-Block-Subnetze

Wählen Sie ein oder mehrere Subnetze aus, und klicken Sie auf LÖSCHEN.

CIF-verknüpfte logische PortsCIFs (Container Interfaces) sind Netzwerkschnittstellen für Container, die mit logischen Ports auf einemSwitch verbunden sind. Diese Ports werden als CIF-verknüpfte logische Ports bezeichnet.

Sie können CIF-verknüpfte logische Ports über die NSX Manager-GUI verwalten.


VMware, Inc. 31

Verwalten von CIF-verknüpften logischen PortsNavigieren Sie zu Switching > Ports, um alle logischen Ports anzuzeigen, einschließlich der CIF-ver-knüpften logischen Ports. Klicken Sie auf die Anhangsverknüpfung eines CIF-verknüpften logischenPorts, um die Anlageninformationen anzuzeigen. Klicken Sie auf den Link des logischen Ports, um einenFensterbereich mit vier Registerkarten zu öffnen: „Übersicht“, „Überwachen“, „Verwalten“ und „Zugehö-rig“. Wenn Sie auf Zugehörig > Logische Ports klicken, wird der zugehörige logische Port auf einemUplink-Switch angezeigt. Weitere Informationen zu Switch-Ports finden Sie im NSX-T-Administratorhand-buch.

NetzwerküberwachungstoolsDie folgenden Tools unterstützen CIF-verknüpfte logische Ports. Weitere Informationen zu diesen Toolsfinden Sie im NSX-T-Administratorhandbuch.

n Traceflow

n Portverbindung

n IPFIX

n Die Remote-Portspiegelung mit GRE-Kapselung eins logischen Switch-Ports, der mit einem Contai-ner verbunden ist, wird unterstützt. Weitere Informationen finden Sie unter „Grundlegendes zum Swit-ching-Profil für die Portspiegelung“ im NSX-T-Administratorhandbuch. Die Portspiegelung desCIF/VIF-Ports wird jedoch nicht unterstützt.

Die verteilte Netzwerkverschlüsselung wird in dieser Version nicht unterstützt.

CLI-BefehleUm CLI-Befehle auszuführen, melden Sie sich beim NSX-T Container Plug-in-Container an, öffnen Sieein 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 Kno-ten ausführen:

kubectl exec -it <pod name> nsxcli

Tabelle 5‑1. CLI-Befehle für den NCP-Container

Typ Befehl

Status get ncp-master status

Status get ncp-nsx status

Status get ncp-watcher <Watcher-Name>

Status get ncp-watchers

Status get ncp-k8s-api-server status

Status check projects


VMware, Inc. 32

Tabelle 5‑1. CLI-Befehle für den NCP-Container (Fortsetzung)

Typ Befehl

Status check project <project-name>

Cache get project-cache <Projektname>

Cache get project-caches

Cache get namespace-cache <Namensraum-Name>

Cache get namespace-caches

Cache get pod-cache <Pod-Name>

Cache get pod-caches

Cache get ingress-caches

Cache get ingress-cache <ingress-name>

Cache get ingress-controllers

Cache get ingress-controller <ingress-controller-name>

Cache get network-policy-caches

Cache get network-policy-cache <pod-name>

Support get ncp-log file <Dateiname>

Support get ncp-log-level

Support set ncp-log-level <log-level>

Support get support-bundle file <Dateiname>

Support get node-agent-log file <Dateiname>

Support get node-agent-log file <Dateiname> <Knotenname>

Tabelle 5‑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

Tabelle 5‑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


VMware, Inc. 33

Statusbefehle für den NCP-Containern 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 eingehenden Datenverkehr, Namensraum, Pod und Dienst anzeigen

get ncp-watcher <watcher-name>

get ncp-watchers

Beispiel 1:

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

Beispiel 2:

kubenode> get ncp-watchers

pod:









VMware, Inc. 34


namespace:









ingress:









service:









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>

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


VMware, Inc. 35

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

Cachebefehle für den NCP-Containern 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

Beispiel:

kubenode> get project-caches

default:

logical-router: 8accc9cd-9883-45f6-81b3-0d1fb2583180

logical-switch:

id: 9d7da647-27b6-47cf-9cdb-6e4f4d5a356d

ip_pool_id: 519ff57f-061f-4009-8d92-3e6526e7c17e

subnet: 10.0.0.0/24

subnet_id: f75fd64c-c7b0-4b42-9681-fc656ae5e435

kube-system:

logical-router: 5032b299-acad-448e-a521-19d272a08c46

logical-switch:

id: 85233651-602d-445d-ab10-1c84096cc22a

ip_pool_id: ab1c5b09-7004-4206-ac56-85d9d94bffa2

subnet: 10.0.1.0/24

subnet_id: 73e450af-b4b8-4a61-a6e3-c7ddd15ce751

testns:

ext_pool_id: 346a0f36-7b5a-4ecc-ad32-338dcb92316f

labels:

ns: myns

project: myproject

logical-router: 4dc8f8a9-69b4-4ff7-8fb7-d2625dc77efa

logical-switch:

id: 6111a99a-6e06-4faa-a131-649f10f7c815

ip_pool_id: 51ca058d-c3dc-41fd-8f2d-e69006ab1b3d

subnet: 50.0.2.0/24

subnet_id: 34f79811-bd29-4048-a67d-67ceac97eb98

project_nsgroup: 9606afee-6348-4780-9dbe-91abfd23e475

snat_ip: 4.4.0.3

kubenode> get project-cache default


logical-switch:



VMware, Inc. 36


subnet: 10.0.0.0/24


kubenode> get namespace-caches

default:


logical-switch:



subnet: 10.0.0.0/24


kube-system:

logical-router: 5032b299-acad-448e-a521-19d272a08c46

logical-switch:

id: 85233651-602d-445d-ab10-1c84096cc22a

ip_pool_id: ab1c5b09-7004-4206-ac56-85d9d94bffa2

subnet: 10.0.1.0/24

subnet_id: 73e450af-b4b8-4a61-a6e3-c7ddd15ce751

testns:

ext_pool_id: 346a0f36-7b5a-4ecc-ad32-338dcb92316f

labels:

ns: myns

project: myproject

logical-router: 4dc8f8a9-69b4-4ff7-8fb7-d2625dc77efa

logical-switch:

id: 6111a99a-6e06-4faa-a131-649f10f7c815

ip_pool_id: 51ca058d-c3dc-41fd-8f2d-e69006ab1b3d

subnet: 50.0.2.0/24

subnet_id: 34f79811-bd29-4048-a67d-67ceac97eb98

project_nsgroup: 9606afee-6348-4780-9dbe-91abfd23e475

snat_ip: 4.4.0.3

kubenode> get namespace-cache default


logical-switch:



subnet: 10.0.0.0/24


n Internen Cache für Pods abrufen

get pod-cache <pod-name>

get pod-caches

Beispiel:

kubenode> get pod-caches

nsx.default.nginx-rc-uq2lv:

cif_id: 2af9f734-37b1-4072-ba88-abbf935bf3d4

gateway_ip: 10.0.0.1


VMware, Inc. 37

host_vif: d6210773-5c07-4817-98db-451bd1f01937

id: 1c8b5c52-3795-11e8-ab42-005056b198fb

ingress_controller: False

ip: 10.0.0.2/24

labels:

app: nginx

mac: 02:50:56:00:08:00

port_id: d52c833a-f531-4bdf-bfa2-e8a084a8d41b

vlan: 1

nsx.testns.web-pod-1:

cif_id: ce134f21-6be5-43fe-afbf-aaca8c06b5cf


host_vif: d6210773-5c07-4817-98db-451bd1f01937

id: 3180b521-270e-11e8-ab42-005056b198fb


ip: 50.0.2.3/24

labels:

app: nginx-new

role: db

tier: cache

mac: 02:50:56:00:20:02

port_id: 81bc2b8e-d902-4cad-9fc1-aabdc32ecaf8

vlan: 3

kubenode> get pod-cache nsx.default.nginx-rc-uq2lv

cif_id: 2af9f734-37b1-4072-ba88-abbf935bf3d4


host_vif: d6210773-5c07-4817-98db-451bd1f01937

id: 1c8b5c52-3795-11e8-ab42-005056b198fb


ip: 10.0.0.2/24

labels:

app: nginx

mac: 02:50:56:00:08:00

port_id: d52c833a-f531-4bdf-bfa2-e8a084a8d41b

vlan: 1

n 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:


VMware, Inc. 38

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

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


VMware, Inc. 39

operator: DoesNotExist

matchLabels:

ns: myns

ports:

port: 80

protocol: TCP

src_rules_hash: e4ea7b8d91c1e722670a59f971f8fcc1a5ac51f1

Supportbefehle für den NCP-Containern NCP-Support-Paket im Dateispeicher speichern

Das Support-Paket umfasst die Protokolldateien für alle Container in Pods mit der Bezeichnungtier: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ön-nen 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/vmwa-re/nsx/file-store gespeichert. Mithilfe des CLI-Befehls „file-store“ können Sie die Paketdatei ineine 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 imTGZ-Format im CLI-Standard-Dateispeicherverzeichnis /var/vmware/nsx/file-store gespeichert.Mithilfe des CLI-Befehls „file-store“ können Sie die Paketdatei in eine Remote-Site kopieren.

get node-agent-log file <filename>

get node-agent-log file <filename> <node-name>


VMware, Inc. 40

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-Containern 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-Containern Internen Cache für NSX-Knoten-Agent-Container abrufen

get container-cache <container-name>

get container-caches

Beispiel 1:

kubenode> get container-cache cif104

ip: 192.168.0.14/32

mac: 50:01:01:01:01:14

gateway_ip: 169.254.1.254/16

vlan_id: 104


VMware, Inc. 41

Beispiel 2:

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

Status-Befehle für den NSX-Kube-Proxy-Containern 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 1:

kubenode> get kube-proxy-watcher endpoint


Current watcher started time: May 01 2017 15:06:24 PDT





Watcher thread created time: May 01 2017 15:06:24 PDT


Beispiel 2:

kubenode> get kube-proxy-watchers

endpoint:









service:


VMware, Inc. 42









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

tions=ct(table=1)

cookie=0x0, duration=8.898s, table=0, n_packets=0, n_bytes=0, idle_age=8, priority=0 ac-

tions=NORMAL

cookie=0x0, duration=8.759s, table=1, n_packets=0, n_bytes=0, idle_age=8, priori-

ty=100,tcp,nw_dst=10.96.0.1,tp_dst=443 actions=mod_tp_dst:443


ty=100,ip,nw_dst=10.96.0.10 actions=drop


ty=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 ac-

tions=NORMAL

cookie=0x0, duration=8.856s, table=2, n_packets=0, n_bytes=0, idle_age=8, actions=NORMAL

FehlercodesIn 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


VMware, Inc. 43


NCP00010 Knoten-Tag nicht gefunden

NCP00011 Ungültiger logischer Switch-Port des Knotens

NCP00012 Aktualisieren der übergeordneten VIF fehlgeschlagen

NCP00013 VLAN ausgeschöpft

NCP00014 VLAN-Version ist fehlgeschlagen

NCP00015 IP-Pool ist ausgeschöpft

NCP00016 IP-Version ist fehlgeschlagen

NCP00017 IP-Block ausgeschöpft

NCP00018 Erstellen des IP-Subnetzes ist fehlgeschlagen

NCP00019 Löschen des IP-Subnetzes ist fehlgeschlagen

NCP00020 Erstellen des IP-Pools ist fehlgeschlagen

NCP00021 Löschen des IP-Pools ist fehlgeschlagen

NCP00022 Erstellen des logischen Routers ist fehlgeschlagen

NCP00023 Aktualisieren des logischen Routers ist fehlgeschlagen

NCP00024 Löschen des logischen Routers ist fehlgeschlagen

NCP00025 Erstellen des logischen Switches ist fehlgeschlagen


NCP00026 Aktualisieren des logischen Switches ist fehlgeschlagen

NCP00027 Löschen des logischen Switches ist fehlgeschlagen

NCP00028 Erstellen des Ports für den logischen Router ist fehlgeschlagen

NCP00029 Löschen des Ports für den logischen Router ist fehlgeschlagen

NCP00030 Erstellen des Ports für den logischen Switch ist fehlgeschlagen

NCP00031 Aktualisieren des Ports für den logischen Switch ist fehlgeschlagen

NCP00032 Löschen des Ports für den logischen Switch ist fehlgeschlagen

NCP00033 Netzwerkrichtlinie wurde nicht gefunden

NCP00034 Erstellen der Firewall ist fehlgeschlagen

NCP00035 Lesen der Firewall ist fehlgeschlagen

NCP00036 Aktualisieren der Firewall ist fehlgeschlagen

NCP00037 Löschen der Firewall ist fehlgeschlagen

NCP00038 Mehrere Firewalls gefunden

NCP00039 Erstellen der NS-Gruppe ist fehlgeschlagen

NCP00040 Löschen der NS-Gruppe ist fehlgeschlagen

NCP00041 Erstellen von IP Set ist fehlgeschlagen

NCP00042 Aktualisieren von IP Set ist fehlgeschlagen


VMware, Inc. 44


NCP00043 Löschen von IP Set ist fehlgeschlagen

NCP00044 Erstellen der SNAT-Regel ist fehlgeschlagen

NCP00045 Löschen der SNAT-Regel ist fehlgeschlagen

NCP00046 Adapter-API-Verbindung ist fehlgeschlagen

NCP00047 Adapter-Watcher-Ausnahme

NCP00048 Löschen des Load Balancer-Diensts ist fehlgeschlagen

NCP00049 Erstellen des virtuellen Servers für den Load Balancer ist fehlgeschlagen

NCP00050 Aktualisieren des virtuellen Servers für den Load Balancer ist fehlgeschlagen


NCP00051 Löschen des virtuellen Servers für den Load Balancer ist fehlgeschlagen

NCP00052 Erstellen des Load Balancer-Pools ist fehlgeschlagen

NCP00053 Aktualisieren des Load Balancer-Pools ist fehlgeschlagen

NCP00054 Löschen des Load Balancer-Pools ist fehlgeschlagen

NCP00055 Erstellen der Load Balancer-Regel ist fehlgeschlagen

NCP00056 Aktualisieren des Load Balancer-Pools ist fehlgeschlagen

NCP00057 Löschen der Load Balancer-Regel ist fehlgeschlagen

NCP00058 IP-Freigabe für Load Balancer-Pool ist fehlgeschlagen

NCP00059 Zuordnung von virtuellem Server und Dienstzuordnung für Load Balancer nicht gefunden

NCP00060 Aktualisieren der NS-Gruppe ist fehlgeschlagen

NCP00061 Abrufen der Firewallregeln ist fehlgeschlagen

NCP00062 NS-Gruppe – 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


VMware, Inc. 45


NCP00076 Aktualisieren der SNAT-Regel ist fehlgeschlagen

NCP00077 SNAT-Regel überlagert

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 Fehler, da Load Balancer-Pool 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

Fehlercodes für NSX-Knoten-Agent


NCP01001 OVS-Uplink nicht gefunden

NCP01002 Host-MAC nicht gefunden

NCP01003 OVS-Porterstellung ist fehlgeschlagen

NCP01004 Keine Pod-Konfiguration

NCP01005 Pod-Konfiguration ist fehlgeschlagen

NCP01006 Aufheben der Pod-Konfiguration ist fehlgeschlagen

NCP01007 CNI-Socket nicht gefunden

NCP01008 CNI-Verbindung ist fehlgeschlagen

NCP01009 CNI-Version stimmt nicht überein

NCP01010 CNI-Nachrichtenempfang ist fehlgeschlagen

NCP01011 CNI-Nachrichtenübertragung ist fehlgeschlagen


VMware, Inc. 46


NCP01012 Hyperbus-Verbindung ist fehlgeschlagen

NCP01013 Hyperbus-Version stimmt nicht überein

NCP01014 Fehler beim Empfang der Hyperbus-Nachricht

NCP01015 Hyperbus-Nachrichtenübertragung ist fehlgeschlagen

NCP01016 GARP-Senden ist fehlgeschlagen

NCP01017 Schnittstellenkonfiguration ist fehlgeschlagen

Fehlercodes für nsx-kube-proxy


NCP02001 Ungültiger Gateway-Port des Proxys

NCP02002 Proxy-Befehl ist fehlgeschlagen

NCP02003 Proxy-Validierung ist fehlgeschlagen

CLI-Fehlercodes


NCP03001 CLI-Start ist fehlgeschlagen

NCP03002 Erstellen des CLI-Sockets ist fehlgeschlagen

NCP03003 CLI-Socket-Ausnahme

NCP03004 Ungültige Anforderung von CLI-Client

NCP03005 CLI-Server-Übertragung ist fehlgeschlagen

NCP03006 CLI-Server-Empfang ist fehlgeschlagen

NCP03007 CLI-Befehlsausführung ist fehlgeschlagen

Fehlercodes für Kubernetes


NCP05001 Kubernetes-Verbindung ist fehlgeschlagen

NCP05002 Ungültige Konfiguration für Kubernetes

NCP05003 Kubernetes-Anforderung ist fehlgeschlagen

NCP05004 Kubernetes-Schlüssel nicht gefunden

NCP05005 Kubernetes-Typ nicht gefunden

NCP05006 Ausnahme bei Kubernetes-Wächter

NCP05007 Kubernetes-Ressource weist ungültige Länge auf

NCP05008 Kubernetes-Ressource weist ungültigen Typ auf


VMware, Inc. 47


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

Fehlercodes für OpenShift


NCP07001 OC-Routen-Handle ist fehlgeschlagen

NCP07002 Aktualisieren des OC-Routenstatus ist fehlgeschlagen


VMware, Inc. 48

Documents

NSX-T Container Plug-In für OpenShift – Installations- und ... fileNSX-T Container Plug-in (NCP) stellt eine Integration zwischen NSX-T und der Container-Orchestrierung wie z. B