NSX Container Plug-In für OpenShift - Installations- und Administratorhandbuch - NSX Container Plug-In 3.2 VMware NSX-T Data Center 3.2 - VMware ...
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch NSX Container Plug-In 3.2 VMware NSX-T Data Center 3.2
NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
Die aktuellste technische Dokumentation finden Sie auf der VMware-Website unter:
https://docs.vmware.com/de/
VMware, Inc. VMware Global, Inc.
3401 Hillview Ave. Zweigniederlassung Deutschland
Palo Alto, CA 94304 Willy-Brandt-Platz 2
www.vmware.com 81829 München
Germany
Tel.: +49 (0) 89 3706 17 000
Fax: +49 (0) 89 3706 17 333
www.vmware.com/de
©
Copyright 2017-2021 VMware, Inc. Alle Rechte vorbehalten. Urheberrechts- und Markenhinweise.
VMware, Inc. 2Inhalt
NSX-T Container Plug-In für OpenShift – Installations- und Administratorhandbuch
4
1 Übersicht über das NSX Container-Plug-In 5
Kompatibilitätsanforderungen 6
Überblick über die Installation 6
2 Einrichten von NSX-T-Ressourcen 7
Konfigurieren von NSX-T-Ressourcen 7
3 Vorbereiten von NCP für OpenShift 4 11
4 Installieren von OpenShift 4 mit von Benutzern bereitgestellter Infrastruktur 17
5 Installieren von OpenShift 4 mit vom Installationsprogramm bereitgestellter
Infrastruktur 19
6 Konfigurieren von Load Balancing 22
7 Upgrade von NCP 30
8 Verwalten von NCP 32
Bereinigen der NSX-T-Umgebung 32
Ändern des Cluster-Namens eines laufenden Clusters 35
CLI-Befehle 35
Fehlercodes 46
VMware, Inc. 3NSX-T Container Plug-In für OpenShift – Installations- und Administratorhandbuch Dieses Handbuch beschreibt die Installation und Verwaltung von NSX Container Plug-in (NCP) für die Bereitstellung der Integration zwischen NSX-T Data Center und OpenShift. 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 und OpenShift 4 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. 4
Übersicht über das NSX
Container-Plug-In 1
Das NSX Container-Plug-In (NCP) stellt eine Integration zwischen NSX-T Data Center und der
Container-Orchestrierung wie Kubernetes sowie die Integration zwischen NSX-T Data Center und
Container-basierten PaaS-Softwareprodukten (Plattform als Dienst) wie OpenShift bereit.
Dieses Handbuch beschreibt das Einrichten von NCP mit OpenShift 4. Informationen zum
Einrichten von NCP mit OpenShift 3 finden Sie in der NCP 2.5-Version dieses Leitfadens.
Die Hauptkomponente von NCP wird in einem Container ausgeführt und kommuniziert mit NSX
Manager und mit der OpenShift-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-T-Richtlinien-API.
Das NSX CNI-Plugin wird auf jedem OpenShift-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-Topologie für einen OpenShift-Cluster und erstellt
ein separates 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 separate SNAT-IP für jeden OpenShift-Namespace zu.
Hinweis Bei der Konfiguration von NAT darf die Gesamtzahl der übersetzten IPs 1000 nicht
überschreiten.
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
Bezeichnungsselektoren für Netzwerkrichtlinien.
VMware, Inc. 5NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
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.
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 die Bezeichnungen eines Pods und lässt zu, dass der Administrator die NSX-T Data
Center-Sicherheitsgruppen und -richtlinien basierend auf den Tags festlegt.
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.2.0.1: https://docs.vmware.com/de/VMware-NSX-T-Data-
Center/3.2/rn/NSX-Container-Plugin-3201-Release-Notes.html
Überblick über die Installation
Das Installieren und Konfigurieren von NCP umfasst die folgenden Schritte. Zur erfolgreichen
Durchführung der Schritte müssen Sie mit NSX-T Data Center sowie der Installation und
Verwaltung von OpenShift 4 vertraut sein.
Beachten Sie, dass alle NSX-T-Objekte mithilfe der Richtlinien-Benutzeroberfläche erstellt werden
müssen.
1 Installieren Sie NSX-T Data Center.
2 Erstellen Sie eine Overlay-Transportzone.
3 Erstellen Sie ein Overlay-Segment und ein Tier-1-Gateway und verbinden Sie die OpenShift-
Knoten mit dem Segment.
4 Installieren Sie OpenShift und NCP.
VMware, Inc. 6Einrichten von NSX-T-Ressourcen
2
Vor 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.1/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.1/administration/GUID-
BB26CDC8-2A90-4C7E-9331-643D13FEEC4A.html.
Für OpenShift 4 müssen Sie den Richtlinienmodus oder die Richtlinien-API verwenden, um NSX-T
Ressourcen zu konfigurieren.
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
Konfigurieren von NSX-T-Ressourcen
In diesem Abschnitt wird die Konfiguration von Ressourcen im NSX Manager-Richtlinienmodus
beschrieben.
In der NCP-Konfigurationsdatei ncp.ini können Sie NSX-T-Ressourcen mit den jeweiligen UUIDs
oder Namen angeben.
Gateways und Segment
1 Erstellen Sie ein Segment für die Kubernetes-Knoten, z. B. ocp4-segment.
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
VMware, Inc. 7NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
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 ocp4-segment. 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
das Segment angehängt ist, der automatisch erstellt wird. Sie finden sie unter Netzwerk >
Segmente mit demselben Namen wie das Segment, also ocp4-segment.
7 Wenn Sie DHCP verwenden, können Sie die statische Bindung von DHCP auf dem Segment
für die Knoten bereitstellen.
NCP muss die VIF-ID der vNIC kennen. Sie können ocp4-segment-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:
n Tag: , Geltungsbereich: ncp/cluster
n Tag: , Geltungsbereich: ncp/node_name
Hinweis: Es ist nicht notwendig, die obigen Tags manuell hinzuzufügen. Sie werden automatisch
vom NCP-Netzwerkbetreiber hinzugefügt.
IP-Blöcke für Kubernetes-Pods
IP-Blocks werden automatisch von NCP erstellt. NSX-Netzwerkbetreiber gibt den Wert des cidr-
Parameters im Abschnitt networking.clusterNetwork für install-config.yaml an. Beispiel:
networking:
networkType: ncp
clusterNetwork:
- cidr: 10.4.0.0/16
hostPrefix: 23
machineCIDR: 10.114.16.0/24
serviceNetwork:
- 172.30.0.0/16
Der Openshift 4-Adapter erstellt einen neuen IP-Block für jedes in der Datei install-
config.yaml konfigurierte CIDR. Sie müssen darauf achten, ob es einen bestehenden IP-Block
mit demselben CIDR gibt. Es wird nicht empfohlen, überlappende IP-Blöcke zu verwenden, da
NCP die Routenankündigung für verbundene Subnetze zwischen Tier-0 und Tier-1 ermöglicht.
VMware, Inc. 8NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch 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 (Teil des NCP-Netzwerkbetreibers) 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. 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 nsx-ncp-operator-config- configmap im nsx-system-operator-Element nach der Bereitstellung des Clusters ändern. Gemeinsam genutzte Tier-1-Topologie Das folgende Diagramm veranschaulicht eine gemeinsame Tier-1-Topologie. VMware, Inc. 9
NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
Physischer Physischer
Router 1 Router 2
EBGP/Static
Aktiv/Aktive Tier-0
Aktiv/Standby-Tier-0
SNAT-IP pro Projekt
ist hier konfiguriert
NSX Load Balancer für
Dienst des Typs LoadBalancer
Tier-1 pro OCP-Cluster
Logisches Segment und Ebene 1
Subnetz pro OpenShift-Projekt
10.24.0.0/24 10.24.2.0/24
Verteilte Firewall und
IDS pro POD
OCP Control Plane OCP-Worker-Knoten
vSphere, NSX-T, Speicher
Dies ist die einzige Topologie für OpenShift 4. Führen Sie zum Einrichten dieser Topologie die
folgenden Konfigurationen aus:
n Legen Sie die Option top_tier_router auf die ID des Tier-1-Gateways fest. Verbinden Sie
das Tier-1-Gateway mit einem Tier-0-Gateway für externe Verbindungen.
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.
VMware, Inc. 10Vorbereiten von NCP für
OpenShift 4 3
Vor der Installation von OpenShift 4 müssen Sie einige NCP-Konfigurationsdateien aktualisieren.
Die YAML-Dateien sind in der NCP-Download-Datei von download.vmware.com enthalten.
Sie können https://github.com/vmware/nsx-container-plugin-operator/releases aufrufen, die
entsprechende Operatorversion (z. B. v3.1.1) suchen und openshift4.tar.gz herunterladen.
Die folgenden Dateien befinden sich im Ordner nsx-container-plugin-operator/deploy:
n configmap.yaml – Diese Datei mit den NSX-T-Informationen aktualisieren.
n operator.yaml – Geben Sie den Speicherort des NCP in dieser Datei an.
n namespace.yaml – Die Namespace-Spezifikation für den Operator. Bearbeiten Sie diese
Datei nicht.
n role_binding.yaml – Die Rollenbindungsspezifikation für den Operator. Bearbeiten Sie
diese Datei nicht.
n role.yaml –Die Rollenspezifikation für den Operator. Bearbeiten Sie diese Datei nicht.
n service_account.yaml – Die Spezifikation des Dienstkontos für den Operator. Bearbeiten
Sie diese Datei nicht.
n lb-secret.yaml – Geheimnis für das standardmäßige NSX-T-Load Balancer-Zertifikat.
n nsx-secret.yaml – Geheimnis für zertifikatsbasierte Authentifizierung bei NSX-T. Dies wird
statt nsx_api_user und nsx_api_password in der configmap.yaml verwendet.
n operator.nsx.vmware.com_ncpinstalls_crd.yaml – Betreibereigene
Kundenressourcendefinition
n operator.nsx.vmware.com_v1_ncpinstall_cr.yaml – Betreibereigene Kundenressource
Das folgende connfigplan.yaml-Beispiel zeigt eine Basiskonfiguration. Weitere Optionen
finden Sie unter connfigplan.yaml im Ordner Bereitstellen. Sie müssen die Werte für die
folgenden Parameter entsprechend Ihrer Umgebung angeben:
n Cluster
n nsx_api_managers
n nsx_api_user
VMware, Inc. 11NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
n nsx_api_password
n external_ip_pools
n tier0_gateway
n overlay_tz
n edge_cluster
n apiserver_host_ip
n apiserver_host_port
kind: ConfigMap
metadata:
name: nsx-ncp-operator-config
namespace: nsx-system-operator
data:
ncp.ini: |
[vc]
[coe]
# Container orchestrator adaptor to plug in.
adaptor = openshift4
# Specify cluster name.
cluster = ocp
[DEFAULT]
[nsx_v3]
policy_nsxapi = True
# 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 =
# 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 =
nsx_api_managers = 10.114.209.10,10.114.209.11,10.114.209.12
nsx_api_user = admin
nsx_api_password = VMware1!
# Do not use in production
insecure = True
# Choices: ALL DENY
log_firewall_traffic = DENY
external_ip_pools = 10.114.17.0/25
VMware, Inc. 12NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
#top_tier_router =
tier0_gateway = t0a
single_tier_topology = True
overlay_tz = 3efa070d-3870-4eb1-91b9-a44416637922
edge_cluster = 3088dc2b-d097-406e-b9de-7a161e8d0e47
[ha]
[k8s]
# Kubernetes API server IP address.
apiserver_host_ip = api-int.ocp.yasen.local
# Kubernetes API server port.
apiserver_host_port = 6443
client_token_file = /var/run/secrets/kubernetes.io/serviceaccount/token
# Choices: allow_cluster allow_namespace
baseline_policy_type = allow_cluster
enable_multus = False
process_oc_network = False
[nsx_kube_proxy]
[nsx_node_agent]
ovs_bridge = br-int
# The OVS uplink OpenFlow port
ovs_uplink_port = ens192
[operator]
# The default certificate for HTTPS load balancing.
# Must be specified along with lb_priv_key option.
# Operator will create lb-secret for NCP based on these two options.
#lb_default_cert =
# The private key for default certificate for HTTPS load balancing.
# Must be specified along with lb_default_cert option.
#lb_priv_key =
In der operator.yaml müssen Sie den Speicherort des NCP-Images im Abschnitt env angeben.
kind: Deployment
metadata:
name: nsx-ncp-operator
namespace: nsx-system-operator
spec:
replicas: 1
selector:
matchLabels:
name: nsx-ncp-operator
template:
metadata:
VMware, Inc. 13NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
labels:
name: nsx-ncp-operator
spec:
hostNetwork: true
serviceAccountName: nsx-ncp-operator
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/master
- effect: NoSchedule
key: node.kubernetes.io/not-ready
containers:
- name: nsx-ncp-operator
# Replace this with the built image name
image: vmware/nsx-container-plugin-operator:latest
command: ["/bin/bash", "-c", "nsx-ncp-operator --zap-time-encoding=iso8601"]
imagePullPolicy: Always
env:
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: OPERATOR_NAME
value: "nsx-ncp-operator"
- name: NCP_IMAGE
value: "{NCP Image}"
Geben Sie für das Operator-Image die NCP-Version an, die installiert werden muss. Für NCP 3.1.1
lautet das Operator-Image beispielsweise vmware/nsx-container-plugin-operator:v3.1.1.
Beachten Sie, dass das direkte Ziehen von dockerhub in einer Produktionsumgebung aufgrund
seiner Ratenbegrenzungsrichtlinie nicht empfohlen wird. Sobald das Image aus Dockerhub
gezogen wurde, kann es in eine lokale Registry gepusht werden, möglicherweise in dieselbe,
in der auch NCP-Images verfügbar sind.
Alternativ können Sie die Operator-Imagedatei verwenden, die in der NCP-Downloaddatei von
download.vmware.com enthalten ist, und sie in eine lokale Registrierung importieren. Dieses
Image entspricht dem Image, das auf dem VMware-Dockerhub veröffentlicht ist.
Um den MTU-Wert für CNI festzulegen, bearbeiten Sie den mtu-Parameter im Abschnitt
[nsx-node-agent] der Operator ConfigMap. Der Operator löst eine Neuerstellung der
nsx-ncp-boostrap-Pods aus, um sicherzustellen, dass CNI-Konfigurationsdateien auf allen
Knoten ordnungsgemäß aktualisiert werden. Sie müssen auch die Knoten-MTU entsprechend
aktualisieren. Eine Nichtübereinstimmung zwischen Knoten- und Pod-MTU kann Probleme bei der
Kommunikation zwischen Knoten und Pod verursachen. Das hat beispielsweise Auswirkungen auf
TCP-Livetests und Bereitschaftstests.
VMware, Inc. 14NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
Um MTU auf einer Schnittstelle auf einem Knoten zu aktualisieren, können Sie den Befehl ovs-
vsctl set Interface mtu_request= ausführen, wobei
interface-name entweder eine OVS-Schnittstelle oder eine physische Schnittstelle im „nsx-
ovs“-Container sein kann, der im „nsx-node-agent“-Pod ausgeführt wird. Beispiel: oc -n nsx-
system exec -it nsx-node-agent-dqqm9 -c nsx-ovs -- ovs-vsctl set Interface
ens192 mtu_request=9000.
Hinweis: Wenn Sie HA in der Operator ConfigMap aktivieren, wird ein einzelner NCP-Pod erstellt,
da der ncpReplicas-Parameter standardmäßig auf 1 gesetzt ist. Um 3 NCP-Pods zu erstellen,
können Sie ihn in 3 ändern. Nach der Installation des Clusters können Sie die Anzahl der NCP-
Replikate mit dem Befehl oc edit ncpinstalls ncp-install -n nsx-system ändern.
Konfigurieren der zertifikatsbasierten Authentifizierung für
NSX-T mit Primäridentität.
In einer Produktionsumgebung wird empfohlen, die Administratoranmeldedaten in der
configmap.yaml nicht mit den Parametern nsx_api_user und nsx_api_password anzuzeigen.
In den folgenden Schritten wird beschrieben, wie Sie eine Primäridentität erstellen und für NCP
zulassen, das Zertifikat zur Authentifizierung zu verwenden.
1 Generieren Sie ein Zertifikat und einen Schlüssel.
2 Navigieren Sie in NSX Manager zu System > Benutzer und Rollen und klicken Sie auf
Hinzufügen > Prinzipalidentität mit Rolle. Fügen Sie eine Primäridentität hinzu und fügen
Sie das in Schritt 1 erstellte Zertifikat ein.
3 Fügen Sie die base64-kodierte crt und die Schlüsselwerte in die nsx-secret.yaml ein.
4 Legen Sie den Speicherort des Zertifikats und der Schlüsseldateien in der configmap.yaml im
Abschnitt [nsx_v3] fest:
nsx_api_cert_file = /etc/nsx-ujo/nsx-cert/tls.crt
nsx_api_private_key_file = /etc/nsx-ujo/nsx-cert/tls.key
Hinweis: Das Ändern der Authentifizierungsmethode auf einem Cluster mit Bootstrap wird nicht
unterstützt.
(Optional) Konfigurieren des standardmäßigen NSX-T-Load
Balancer-Zertifikats
Ein NSX-T Load Balancer kann OpenShift HTTPS-Routenobjekte implementieren und den OCP
HAProxy entladen. Dazu ist ein Standardzertifikat erforderlich. Führen Sie die folgenden Schritte
aus, um das Standardzertifikat zu konfigurieren:
1 Fügen Sie die base64-kodierte crt und die Schlüsselwerte in die lb-secret.yaml ein.
VMware, Inc. 15NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
2 Legen Sie den Speicherort für das Zertifikat und den Schlüssel in der configmap.yaml im
Abschnitt [nsx_v3] fest:
lb_default_cert_path = /etc/nsx-ujo/lb-cert/tls.crt
lb_priv_key_path = /etc/nsx-ujo/lb-cert/tls.key
(Optional) Konfigurieren der zertifikatsbasierten
Authentifizierung für NSX Manager
Wenn Sie insecure = False in der ConfigMap festlegen, müssen Sie die
Zertifikatsfingerabdrücke aller drei Manager im NSX Manager-Cluster angeben. Beispiel für dieses
Verfahren:
Kopieren Sie die Zertifikate aller drei NSX Manager in eine Datei:
ssh -l admin 10.114.209.10 -f 'get certificate api' > nsx1.crt
ssh -l admin 10.114.209.11 -f 'get certificate api' > nsx2.crt
ssh -l admin 10.114.209.12 -f 'get certificate api' > nsx3.crt
NSX1=`openssl x509 -in nsx1.crt -fingerprint -noout|awk -F"=" '{print $2}'`
NSX2=`openssl x509 -in nsx2.crt -fingerprint -noout|awk -F"=" '{print $2}'`
NSX3=`openssl x509 -in nsx3.crt -fingerprint -noout|awk -F"=" '{print $2}'`
THUMB="$NSX1,$NSX2,$NSX3"
echo $THUMB
Bearbeiten Sie die ConfigMap und fügen Sie die Fingerabdrücken im Abschnitt [nsx_v3] hinzu:
oc edit cm nsx-ncp-operator-config -n nsx-system-operator
nsx_api_managers = 10.114.209.10,10.114.209.11,10.114.209.12
nsx_api_user = admin
nsx_api_password = VMwareVMware1!
insecure = False
thumbprint =
E0:A8:D6:06:88:B9:65:7D:FB:F8:14:CF:D5:E5:23:98:C9:43:10:71,A7:B0:26:B5:B2:F6:72:2B:39:86:19:8
4:E6:DD:AB:43:16:0E:CE:BD,52:9B:99:90:88:4C:9F:9B:83:5E:F7:AF:FC:60:06:50:BE:9E:32:08
VMware, Inc. 16Installieren von OpenShift 4 mit
von Benutzern bereitgestellter
Infrastruktur
4
Um einen OpenShift-Cluster mit einer von Benutzern bereitgestellten Infrastruktur zu installieren,
folgen Sie den Anweisungen in der Redhat OpenShift-Dokumentation.
Dies ist eine der beiden Methoden zum Installieren eines OpenShift-Clusters. Die andere Methode
besteht darin, den Cluster mit einer vom Installationsprogramm bereitgestellten Infrastruktur
zu installieren (siehe Kapitel 5 Installieren von OpenShift 4 mit vom Installationsprogramm
bereitgestellter Infrastruktur). Sie können nur eine der beiden Methoden verwenden.
Die Dokumentation finden Sie unter https://docs.openshift.com/container-platform/4.7/installing/
installing_vsphere/installing-vsphere.html.
Ein Beispiel für install-config.yaml:
apiVersion: v1
baseDomain: yasen.local
compute:
- hyperthreading: Enabled
name: worker
replicas: 0
controlPlane:
hyperthreading: Enabled
name: master
replicas: 3
metadata:
name: ocp
networking:
networkType: ncp
clusterNetwork:
- cidr: 10.4.0.0/16
hostPrefix: 23
machineCIDR: 10.114.16.0/24
serviceNetwork:
- 172.30.0.0/16
platform:
vsphere:
vcenter: vc.yasen.local
username: administrator@yasen.local
password: VMware1!
VMware, Inc. 17NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
datacenter: Datacenter1
defaultDatastore: NFS
pullSecret: ''
sshKey: 'ssh-rsa xxxx'
Stellen Sie sicher, dass networkType auf ncp festgelegt ist (Groß- und Kleinschreibung) und cidr
auf das gewünschte Subnetzfeld.
Im Anschluss an die Installationsanweisungen für OpenShift müssen Sie den Inhalt
von nsx-container-plugin-operator/deploy in den Ordner /
manifests kopieren und dann ignition-configs generieren.
Führen Sie den folgenden Befehl aus, um Manifeste zu generieren:
$ ./openshift-install create manifests --dir=
Führen Sie den folgenden Befehl aus, um die NCP Network Operator YAML-Dateien in den
manifest-Ordner zu kopieren:
$ cp nsx-container-plugin-operator/deploy/*.yaml /manifests
Führen Sie den folgenden Befehl aus, um ignition-configs zu generieren:
$ ./openshift-install create ignition-configs --dir=
Verwenden von DDNS mit OpenShift-Knoten
Sie können DDNS mit OpenShift-Knoten verwenden, auf denen CoreOS ausgeführt wird. Wenn
nsx-ovs-Container ausgeführt wird, stoppt er die aktive Verbindung auf dem Host, der DHCP
verwendet, und klont eine neue Verbindung von dieser, bei der „NSX“ dem vorhandenen
Verbindungstyp vorangestellt ist. Diese NSX-Verbindung verfügt über die IP-Konfiguration der
dynamischen IP-Informationen (Adresse, Gateway, DNS und Domäne) aus der ursprünglichen
Verbindung. Ein neuer DHCP-Client wird innerhalb des Containers gestartet, um den Lease
beizubehalten und zu erneuern. Wenn sich DNS oder der Domänenname während der
Ausführung von nsx-ovs ändert, wird er beendet und neu gestartet. Dies geschieht, damit die
IP-Informationen zuerst von NetworkManager und dann von nsx-ovs abgerufen werden. Die NSX-
Verbindungseigenschaften können nicht außer Kraft gesetzt werden, während sie aktiv ist.
VMware, Inc. 18Installieren von OpenShift 4
mit vom Installationsprogramm
bereitgestellter Infrastruktur
5
Um einen OpenShift-Cluster mit einer vom Installationsprogramm bereitgestellten Infrastruktur zu
installieren, befolgen Sie die folgenden Anweisungen.
Dies ist eine der beiden Methoden zum Installieren eines OpenShift-Clusters. Die andere Methode
besteht darin, den Cluster mit einer von Benutzern bereitgestellten Infrastruktur zu installieren
(siehe Kapitel 4 Installieren von OpenShift 4 mit von Benutzern bereitgestellter Infrastruktur). Sie
können nur eine der beiden Methoden verwenden.
Bereiten Sie install-config.yaml vor
1 Generieren Sie install-config.yaml mit dem folgenden Befehl:
openshift-install --dir=$MY_CLUSTER create install-config
2 Bearbeiten Sie $MY_CLUSTER/install-config.yaml um den Abschnitt networking zu
aktualisieren.
n networkType in ncp ändern.
n Legen Sie den cidr-Wert unter clusterNetwork fest.
Ein Beispiel für install-config.yaml:
apiVersion: v1
baseDomain: openshift.test
compute:
- architecture: amd64
hyperthreading: Enabled
name: worker
platform: {}
replicas: 3
controlPlane:
architecture: amd64
hyperthreading: Enabled
name: master
platform: {}
replicas: 3
metadata:
creationTimestamp: null
name: ipi
VMware, Inc. 19NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
networking:
networkType: ncp
clusterNetwork:
- cidr: 10.0.0.0/14
hostPrefix: 24
machineCIDR: 192.168.10.0/24
serviceNetwork:
- 172.8.0.0/16
platform:
vsphere:
apiVIP: 192.168.10.11
cluster: cluster
datacenter: dc
defaultDatastore: vsanDatastore
ingressVIP: 192.168.10.12
network: openshift-segment
password: pass
username: user
vCenter: my-vc.local
publish: External
pullSecret: 'xxx'
sshKey: 'ssh-rsa xxx'
Sie können Ihre DNS-Konfiguration vor der Installation von OpenShift validieren. Im Folgenden
sehen Sie ein Beispiel für eine DNS-Zonendatenbank:
$TTL 604800
$ORIGIN openshift.test.
@ IN SOA dns1.openshift.test. root.openshift.test. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
; main domain name servers
@ IN NS localhost.
@ IN A 127.0.0.1
@ IN AAAA ::1
IN NS dns1.openshift.test.
; recors for name servers above
dns1 IN A 10.92.204.129
; sub-domain definitions
$ORIGIN ipi.openshift.test.
api IN A 192.168.10.11
apps IN A 192.168.10.12
; sub-domain definitions
$ORIGIN apps.ipi.openshift.test.
* IN A 192.168.10.12
Vorbereiten der Manifestdateien
n Verschieben Sie die yaml-Dateien des Operator aus deploy/openshift4 in $MY_CLUSTER/
manifests.
VMware, Inc. 20NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
n Bearbeiten Sie die Operatorkonfigurationen in configmap.yaml.
n Fügen Sie das Operator-Image und das NCP-Image in operator.yaml hinzu.
Cluster erstellen
Führen Sie den folgenden Befehl aus:
openshift-install create cluster --dir=$MY_CLUSTER
Die Installationsprotokollmeldungen befinden sich in $MY_CLUSTER/.openshift_install.log.
Wenn die Installation fehlschlägt, überprüfen Sie das Protokoll auf Fehlermeldungen und nehmen
Sie entsprechend Änderungen an der Umgebung vor. Führen Sie die Sitzung mit folgendem
Befehl dann erneut aus:
openshift-install wait-for install-complete
VMware, Inc. 21Konfigurieren von Load Balancing
6
Der NSX-T Data Center-Load Balancer ist in OpenShift integriert und fungiert als OpenShift-
Router.
NCP überwacht OpenShift-Routen- und -Endpoint-Ereignisse und konfiguriert Load Balancing-
Regeln auf dem Load Balancer basierend auf der Routenspezifikation. Dies führt dazu, das
der NSX-T Data Center-Load Balancer eingehenden Schicht 7-Datenverkehr basierend auf den
Regeln zu den geeigneten Backend-Pods weiterleitet.
Das Konfigurieren des Load Balancing umfasst das Konfigurieren eines Kubernetes-
LoadBalancer-Diensts oder einer OpenShift-Route. Sie müssen auch den NCP
ReplicationController konfigurieren. Der LoadBalancer-Dienst wird für den Schicht 4-
Datenverkehr und die OpenShift-Route für den Schicht 7-Datenverkehr verwendet.
Wenn Sie einen Kubernetes-LoadBalancer-Dienst konfigurieren, wird diesem eine IP-Adresse
aus dem von Ihnen konfigurierten externen IP-Block zugeteilt. Der Load Balancer wird auf
dieser IP-Adresse und dem Dienst-Port bereitgestellt. Sie können den Namen oder die ID eines
IP-Pools mithilfe der loadBalancerIP-Spezifikation in der Definition des LoadBalancer-Diensts
angeben. Die IP-Adresse des LoadBalancer-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.
Der von loadBalancerIP angegebene-IP-Pool muss über das Tag scope: ncp/owner, tag:
cluster: verfügen.
Um den Load Balancer von NSX-T Data Center zu verwenden, müssen Sie Load Balancing 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
der von der Zertifizierungsstelle signierten Zertifikatdatei und der Datei mit dem privaten
Schlüssel fest. Ein Beispielskript 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. Anweisungen hierzu finden Sie unten.
VMware, Inc. 22NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
4 (Optional) Legen Sie mit den Parametern l4_persistence und l7_persistence eine
Persistenzeinstellung fest. 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 . 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
5 (Optional) Legen Sie service_size = SMALL, MEDIUM oder LARGE fest. Die
Standardeinstellung ist SMALL.
6 Wenn Sie OpenShift 3.11 ausführen, müssen Sie die folgende Konfiguration ausführen, damit
OpenShift dem LoadBalancer-Dienst keine IP zuweist.
n Legen Sie ingressIPNetworkCIDR unter networkConfig in der Datei /etc/origin/
master/master-config.yaml auf „0.0.0.0/32“ fest.
n Starten Sie den API-Server und die API-Controller mit den folgenden Befehlen neu:
master-restart api
master-restart controllers
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 festgelegt
ist. Wenn l4_persistence auf source_ip festgelegt ist, kann die sessionAffinity auf
der Dienstspezifikation verwendet werden, um die Persistenz-Zeitüberschreitung für den
Dienst anzupassen. Die standardmäßige Persistenz-Zeitüberschreitung von Layer 4 beträgt
10.800 Sekunden (wie in der Kubernetes-Dokumentation für Dienste (https://kubernetes.io/docs/
VMware, Inc. 23NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
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-svcNSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
Sie können Routen-Shards für folgende Zwecke erstellen:
n Konfigurieren Sie Ingress basierend auf Routenbezeichnungen oder Namespaces.
n Konfigurieren Sie verschiedene Routen für Anwendungen.
n Verteilen Sie die Arbeitslast auf mehrere Load Balancer-Dienste, um die Leistung zu
verbessern.
Diese Funktion unterstützt nur das Sharding von Load Balancer-Diensten der Schicht 7.
Schritte zum Konfigurieren von Router-Sharding:
1 Legen Sie die Option enable_lb_crd im Abschnitt [k8s] in configmap.yaml auf „True“ fest
und wenden Sie die YAML-Datei an. Erstellen Sie eine YAML-Datei, die eine LoadBalancer-
CRD (CustomResourceDefinition) definiert, und wenden Sie sie an. Beispiel:
apiVersion: vmware.com/v1alpha1
kind: LoadBalancer
metadata:
name: lbs-crd-1
spec:
httpConfig:
virtualIP: 192.168.4.4 # VIP for HTTP/HTTPS server. Default to
auto_allocate
port: 81 # HTTP port number. Default to 80
tls:
port: 9998 # HTTPS port number. default to 443
secretName: default_secret # Default certificate for HTTPS server. Default to
nil
secretNamespace: default # Need to be set with secretName
xForwardedFor: INSERT # Available values are INSERT, REPLACE. Default to
nil
affinity:
type: source_ip # Available values are sourceIP, cookie
timeout: 100 # Default to 10800
size: MEDIUM # Default to SMALL
2 Konfigurieren Sie einen Router mit einer Namespace-Bezeichnungsauswahl, indem Sie den
folgenden Befehl ausführen (vorausgesetzt, dass dc/svc des Routers „Router“ lautet):
oc set env dc/router NAMESPACE_LABELS="router=r1"
3 Der im vorherigen Schritt konfigurierte Router verarbeitet Routen aus den ausgewählten
Namespaces. Damit diese Auswahl mit einem Namespace übereinstimmt, kennzeichnen Sie
den Namespace entsprechend. Beispiel:
apiVersion: v1
kind: Route
metadata:
name: cafe-route
annotations:
nsx/loadbalancer: lbs-crd-1
spec:
VMware, Inc. 25NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
host: cafe.example.com
to:
kind: Service
name: tea-svc
weight: 1
Führen Sie den folgenden Befehl aus:
oc label namespace targetns "router=r1"
Ersetzen Sie „targetns“ durch den genauen Namespace, in dem sich die Zielrouten befinden.
Beispiel:
apiVersion: v1
kind: Namespace
metadata:
name: qe
annotations:
nsx/loadbalancer: lbs-crd-1
Hinweis: Wenn eine Route innerhalb eines Namespace eine andere Anmerkung aufweist, hat
die Routenanmerkung Vorrang.
Beispiel für einen Load Balancer auf Schicht 7:
Zur Bereitstellung von Load Balancing auf Schicht 7 konfiguriert die folgende YAML-Datei zwei
Replikations-Controller (tea-rc und coffee-rc), zwei Dienste (tea-svc und coffee-svc) sowie zwei
Routen (cafe-route-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
VMware, Inc. 26NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
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
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
VMware, Inc. 27NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
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
Zusätzliche Hinweise
n Es werden alle Beendigungsmodi unterstützt: edge, passthrough und reencrypt.
n Unterdomänen als Platzhalter werden unterstützt. Wenn zum Beispiel wildcardPolicy auf
Unterdomäne und der Hostname auf wildcard.example.com festgelegt ist, werden alle
Anforderungen an *.example.com verarbeitet.
n Wenn NCP aufgrund einer fehlerhaften Konfiguration einen Fehler während der Verarbeitung
eines Routen-Ereignisses auslöst, müssen Sie die YAML-Datei der Route korrigieren und die
Routen-Ressource 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 Data Center erstellt für jeden LoadBalancer-Dienst-Port einen virtuellen Server und
einen Pool des Load Balancers auf Schicht 4. TCP und UDP werden unterstützt.
n Der Load Balancer von NSX-T Data Center ist in verschiedenen Größen erhältlich. Weitere
Informationen zum Konfigurieren eines Load Balancers für NSX-T Data Center 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 Benutzeroberfläche oder API
geändert werden.
n Das automatische Skalieren des Load Balancers auf Schicht 4 wird unterstützt. 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
VMware, Inc. 28NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
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. Sie können sie deaktivieren, indem Sie in der
NCP-ConfigMap l4_lb_auto_scaling auf false festlegen.
n In einer Routenspezifikationen wird der Parameter destinationCACertificate nicht
unterstützt und von NCP ignoriert.
n Jede TLS-Route muss über ein anderes von einer Zertifizierungsstelle signiertes Zertifikat
verfügen.
Beispielskript zum Generieren eines von einer
Zertifizierungsstelle signierten Zertifikats
Das nachfolgende Skript generiert ein von einer Zertifizierungsstelle signiertes
Zertifikat und einen privaten in den Dateien .crt und .key
gespeicherten privaten Schlüssel. 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.
#!/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
VMware, Inc. 29Upgrade von NCP
7
NSX Container Plugin Operator ist verantwortlich für die Verwaltung des Lebenszyklus von NCP.
Das Upgrade von NCP erfolgt durch Aktualisieren des NCP-Operators und des NCP-
Images. Überprüfen Sie vor der Durchführung des Upgrades die Versionshinweise auf die
Produktkompatibilität.
Voraussetzungen
Laden Sie die neueste nsx-container-ZIP-Datei (nsx-container-x.x.x.y.zip) von https://
downloads.vmware.com herunter.
Die folgenden TAR-Dateien sind für das Upgrade erforderlich:
n nsx-container-x.x.x.y/Kubernetes/nsx-container-plugin-operator-x.x.x.y.tar
n nsx-container-x.x.x.y/Kubernetes/nsx-ncp-ubi-x.x.x.y.tar
Die beiden Images müssen in Ihre Containerregistrierung hochgeladen werden.
Verfahren
1 Bearbeiten Sie operator.yaml.
Ändern Sie das nsx-ncp-container-Image:
containers:
- name: nsx-ncp-operator
image:
Ändern Sie die NCP_IMAGE-URL:
- name: nsx-ncp-operator
image:
2 Aktualisieren Sie configmap.yaml mit den neuen erforderlichen Feldern für diese Version.
Die Informationen zu neuen erforderlichen Attributen finden Sie in den Versionshinweisen.
3 Wenden Sie role.yaml mit dem folgenden Befehl an.
oc apply -f role.yaml -n nsx-system-operator
VMware, Inc. 30NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
4 Wenden Sie operator.yaml (und configmap.yaml, falls geändert) im Namespace nsx-
system-operator mit dem folgenden Befehl an.
oc apply -f operator.yaml -n nsx-system-operator
Es ist nicht erforderlich, die ausgeführte Konfiguration zu bearbeiten.
VMware, Inc. 31Verwalten von NCP
8
Sie können NCP ü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.
Wenn der „nsx-ovs“-Container, der im „nsx-node-agent“-Pod ausgeführt wird, aus irgendeinem
Grund neu gestartet wird, sind Kubernetes-Dienste möglicherweise für 2 Minuten oder länger
nicht verfügbar. Dies ist das erwartete Verhalten.
Dieses Kapitel enthält die folgenden Themen:
n Bereinigen der NSX-T-Umgebung
n Ändern des Cluster-Namens eines laufenden Clusters
n CLI-Befehle
n Fehlercodes
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.
VMware, Inc. 32NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
Bevor Sie das Skript ausführen, führen Sie die folgenden Aufgaben aus:
n Beenden Sie NCP.
n Entfernen Sie alle Ressourcen, die Sie erstellt haben und die den von NCP erstellten Objekten
zugeordnet sind. Das Skript schlägt fehl, wenn Sie diese Objekte nicht löschen. Wenn z. B.
NCP ein Segment erstellt und Sie eine Regel für die verteilte Firewall (DFW) und eine Gruppe
erstellt haben, die dem Segment zugeordnet sind, müssen Sie die DFW-Regel und -Gruppe
löschen oder die Zuordnungen entfernen. Wenn Sie VMs an das Segment angehängt haben,
müssen Sie die VMs löschen oder vom Segment trennen.
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-
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
VMware, Inc. 33NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
--all-res Also clean up HA switching profile, ipblock, external
ippool. These resources could be created by TAS 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 TAS NSX-T
Tile
--no-warning Disable urllib's insecure request warning
Beispiel:
python nsx_cleanup.py --mgr-ip={nsx_mngr_ip} -u admin -p {password} -c {k8s_cluster_name} --
top-tier-router-uuid={top_tier_router_uuid} --no-warning -r
VMware, Inc. 34NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
Ä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 nsxcli
Tabelle 8-1. CLI-Befehle für den NCP-Container
Typ Befehl
Status get ncp-master status
Status get ncp-nsx status
Status get ncp-watcher
Status get ncp-watchers
Status get ncp-k8s-api-server status
Status check projects
Status check project
Cache get project-cache
Cache get project-caches
Cache get namespace-cache
Cache get namespace-caches
VMware, Inc. 35NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch Tabelle 8-1. CLI-Befehle für den NCP-Container (Fortsetzung) Typ Befehl Cache get pod-cache Cache get pod-caches Cache get ingress-caches Cache get ingress-cache Cache get ingress-controllers Cache get ingress-controller Cache get network-policy-caches Cache get network-policy-cache Support get ncp-log file Support get ncp-log-level Support set ncp-log-level Support get support-bundle file Support get node-agent-log file Support get node-agent-log file Tabelle 8-2. CLI-Befehle für den NSX-Knoten-Agent-Container Typ Befehl Status get node-agent-hyperbus status Cache get container-cache Cache get container-caches 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 Status get kube-proxy-watchers Status dump ovs-flows VMware, Inc. 36
NSX Container Plug-In für OpenShift – Installations- und Administratorhandbuch
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-watcher
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:
Average event processing time: 1145 msec (in past 3600-sec window)
Current watcher started time: Mar 02 2017 10:51:37 PST
Number of events processed: 1 (in past 3600-sec window)
Total events processed by current watcher: 1
Total events processed since watcher thread created: 1
Total watcher recycle count: 0
Watcher thread created time: Mar 02 2017 10:51:37 PST
Watcher thread status: Up
namespace:
VMware, Inc. 37Sie können auch lesen
