Die NCP-YAML-Datei enthält Informationen zum Konfigurieren, Installieren und Ausführen aller NCP-Komponenten.
- RBAC-Definitionen.
- Verschiedene CRDs (CustomResourceDefinitions).
- ConfigMap mit ncp.ini, die für NCP dediziert ist. Einige empfohlene Konfigurationsoptionen sind bereits festgelegt.
- NCP-Bereitstellung.
- ConfigMap mit ncp.ini, die für nsx-node-agent dediziert ist. Einige empfohlene Konfigurationsoptionen sind bereits festgelegt.
- nsx-node-agent-DaemonSet, einschließlich nsx-node-agent, nsx-kube-proxy und nsx-ovs.
- nsx-ncp-bootstrap-DaemonSet
Die NSX-CNI- und OpenvSwitch-Kernel-Module werden automatisch von nsx-ncp-bootstrap-initContainers installiert. Die OpenvSwitch-Userspace-Daemons werden auf jedem Knoten im nsx-ovs-Container gestartet.
Aktualisieren der NCP-Bereitstellungsspezifikationen
- Protokollebene und -verzeichnis.
- Kubernetes-API-Server-IP, Zertifikatspfad und Client-Token-Pfad. Standardmäßig wird die API-Server-ClusterIP aus der Umgebungsvariablen verwendet, und Zertifikat sowie Token werden automatisch von ServiceAccount gemountet. In der Regel ist keine Änderung erforderlich.
- Kubernetes-Clustername.
- NSX Manager-IP und Anmeldedaten.
- NSX-Ressourcenoptionen wie overlay_tz, top_tier_router, container_ip_blocks, external_ip_blocks usw.
Standardmäßig werden Kubernetes-Dienst-VIP/-Port und ServiceAccount-Token sowie ca_file für den Kubernetes-API-Zugriff verwendet. Hier ist keine Änderung erforderlich, Sie müssen jedoch einige NSX API-Optionen der ncp.ini eingeben.
- Spezifizieren Sie die Option nsx_api_managers. Es kann sich um eine kommagetrennte Liste mit NSX Manager-IP-Adressen oder URL-Spezifikationen handeln, die mit RFC3896 kompatibel sind. Beispiel:
nsx_api_managers = 192.168.1.181, 192.168.1.182, 192.168.1.183
- Geben Sie die Optionen nsx_api_user und nsx_api_password jeweils mit dem Benutzernamen und dem Kennwort an, wenn Sie NCP für die Verbindung mit NSX-T mithilfe der Standardauthentifizierung konfigurieren. Diese Authentifizierungsmethode wird nicht empfohlen, da Sie weniger sicher ist. Diese Optionen werden ignoriert, wenn NCP für die Authentifizierung mithilfe von Clientzertifikaten konfiguriert ist. Diese Optionen werden in der NCP-YAML-Datei nicht angezeigt. Sie müssen Sie manuell hinzufügen.
- Geben Sie für die Optionen nsx_api_cert_file und nsx_api_private_key_file zur Authentifizierung NSX-T an. Die Option nsx_api_cert_file ist der vollständige Pfad zu einer Clientzertifikatsdatei im PEM-Format. Der Inhalt dieser Datei sollte wie folgt aussehen:
-----BEGIN CERTIFICATE----- <certificate_data_base64_encoded> -----END CERTIFICATE-----
Die Option nsx_api_private_key_file ist der vollständige Pfad zu einer privaten Clientschlüsseldatei im PEM-Format. Der Inhalt dieser Datei sollte wie folgt aussehen:-----BEGIN PRIVATE KEY----- <private_key_data_base64_encoded> -----END PRIVATE KEY-----
Mithilfe der Clientzertifikatauthentifizierung kann NCP ihre Prinzipalidentität zum Erstellen von NSX-T-Objekten verwenden. Dies bedeutet, dass nur eine Identität mit demselben Identitätsnamen die Objekte ändern oder löschen kann. Dadurch wird verhindert, dass NSX-T-Objekte, die von NCP erstellt wurden, versehentlich geändert oder gelöscht werden. Beachten Sie, dass ein Administrator beliebige Objekte ändern oder löschen kann. Wenn das Objekt mit einer Prinzipalidentität erstellt wurde, wird dies in Form einer Warnung angegeben.
- (Optional) Spezifizieren Sie die Option ca_file. Der Wert sollte einer CA-Paketdatei entsprechen, die beim Überprüfen des NSX Manager-Serverzertifikats verwendet wird. Wenn Sie keine Festlegung treffen, werden die System-Root-CAs verwendet. Wenn Sie eine IP-Adresse für nsx_api_managers angeben, geben Sie eine Zertifizierungsstellendatei an. Wenn Sie drei IP-Adressen für nsx_api_managers angeben, können Sie eine oder drei Zertifizierungsstellendatei(en) angeben. Wenn Sie eine Zertifizierungsstellendatei angeben, wird sie für alle drei Manager verwendet. Wenn Sie drei Zertifizierungsstellendateien angeben, wird jede davon für die entsprechende IP-Adresse in nsx_api_managers verwendet. Beispiel:
nsx_api_managers = 192.168.1.181,192.168.1.182,192.168.1.183 ca_file = ca_file_for_all_mgrs or nsx_api_managers = 192.168.1.181,192.168.1.182,192.168.1.183 ca_file = ca_file_for_mgr1,ca_file_for_mgr2,ca_file_for_mgr3
- (Optional) Spezifizieren Sie die Option insecure. Wenn diese Option auf True festgelegt ist, wird das NSX Manager-Serverzertifikat nicht verifiziert. Die Standardeinstellung lautet False.
- Fügen Sie der NCP-Pod-Spezifikation geheime Volumes hinzu oder kommentieren Sie geheime Beispiel-Volumes aus.
- Fügen Sie der NCP-Container-Spezifikation Datenträger-Mounts hinzu oder kommentieren Sie die Beispiel-Volume-Mounts aus.
- Aktualisieren Sie die ncp.ini in der ConfigMap, um den Pfad der Zertifikatsdatei festzulegen, der auf die Datei im gemounteten Volume verweist.
Wenn Sie nicht über eine gemeinsam genutzte Tier-1-Topologie verfügen, müssen Sie die Option edge_cluster auf die Edge-Cluster-ID festlegen, damit NCP ein Tier-1-Gateway oder -Router für den Lastausgleichdienst erstellt. Sie können die Edge-Cluster-ID finden, indem Sie öffnen, die Registerkarte Edge-Cluster auswählen und auf den Namen des Edge-Clusters klicken.
HA (Hochverfügbarkeit) ist automatisch aktiviert. In einer Produktionsumgebung wird empfohlen, HA nicht zu deaktivieren.
Hinweis: Standardmäßig werden die Pods von kube-scheduler nicht auf dem Master-Knoten geplant. In der NCP-YAML-Datei wird eine Toleranz hinzugefügt, damit NCP-Pod auf dem Master-Knoten ausgeführt werden kann.
Konfigurieren von SNAT
ncp/no_snat: True
[coe] enable_snat = False
Hinweis: Das Aktualisieren einer vorhandenen Namespace-SNAT-Anmerkung wird nicht unterstützt. Wenn Sie eine solche Aktion durchführen, wird die Topologie für den Namespace in einem inkonsistenten Zustand angezeigt, da möglicherweise eine veraltete SNAT-Regel verbleibt. Um einen solchen inkonsistenten Zustand wiederherzustellen, müssen Sie den Namespace neu erstellen.
[nsx_v3] configure_t0_redistribution = True
Wenn configure_t0_redistribution auf True festgelegt ist, fügt NCP in der Neuverteilungsregel den Route-Map-Eintrag deny hinzu, um zu verhindern, dass der Tier-0-Router die internen Subnetze des Clusters an BGP-Nachbarn weitergibt. Dies wird hauptsächlich für Cluster vom Typ „vSphere with Kubernetes“ verwendet. Wenn Sie keine Route Map für die Neuverteilungsregel erstellen, erstellt NCP eine Route Map unter Verwendung seiner Prinzipalidentität und wendet sie in der Regel an. Wenn Sie diese Route Map bearbeiten möchten, müssen Sie sie durch eine neue Route Map ersetzen, die Einträge aus der von NCP erstellten Route Map kopieren und neue Einträge hinzufügen. Sie müssen alle potenziellen Konflikte zwischen den neuen Einträgen und den von NCP erstellten Einträgen verwalten. Wenn Sie die von NCP erstellte Route Map einfach aufheben, ohne eine neue Route Map für die Neuverteilungsregel zu erstellen, wendet NCP die zuvor erstellte Route Map erneut auf die Neuverteilungsregel an, sobald NCP neu startet.
Konfigurieren des Firewallabgleichs für NAT-Regeln
[nsx_v3] # This parameter indicate how firewall is applied to a traffic packet. # Firewall can be bypassed, or be applied to external/internal address of # NAT rule # Choices: MATCH_EXTERNAL_ADDRESS MATCH_INTERNAL_ADDRESS BYPASS #natfirewallmatch = MATCH_INTERNAL_ADDRESS
Aktualisieren der nsx-node-agent-DaemonSet-Spezifikationen
- Protokollebene und -verzeichnis.
- Kubernetes-API-Server-IP, Zertifikatspfad und Client-Token-Pfad. Standardmäßig wird die API-Server-ClusterIP aus der Umgebungsvariablen verwendet, und Zertifikat sowie Token werden automatisch von ServiceAccount gemountet. In der Regel ist keine Änderung erforderlich.
- OpenvSwitch-Uplink-Port. Beispiel: ovs_uplink_port=eth1
- Der MTU-Wert für CNI.
Um den MTU-Wert für CNI festzulegen, bearbeiten Sie den mtu-Parameter in der nsx-node-agent ConfigMap und starten Sie die nsx-ncp-bootstrap-Pods neu. Dadurch wird die Pod-MTU auf jedem Knoten aktualisiert. 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.
Das nsx-ncp-bootstrap-DaemonSet installiert CNI- und OVS-Kernel-Module auf dem Knoten. Anschließend werden OVS-Daemons auf dem Knoten heruntergefahren, sodass der nsx-ovs-Container später OVS-Daemons in einem Docker-Container ausführen kann. Wenn CNI nicht installiert ist, befinden sich alle Kubernetes-Knoten im Status „Nicht bereit“. Das Bootstrap-DaemonSet weist eine Toleranz auf, damit es auf Knoten mit dem Status „Nicht bereit“ ausgeführt werden kann. Nachdem das CNI-Plug-In installiert wurde, sollten die Knoten „Bereit“ sein.
Wenn Sie nicht das NSX OVS-Kernelmodul verwenden, müssen Sie den Volume-Parameter host-original-ovs-db mit dem richtigen Pfad aktualisieren, in dem die OpenvSwitch-Datenbank während der Zusammenstellung des OVS-Kernelmoduls konfiguriert ist. Wenn Sie beispielsweise --sysconfdir=/var/lib angeben, legen Sie host-original-ovs-db auf /var/lib/openvswitch fest. Achten Sie darauf, dass Sie den Pfad der tatsächlichen OVS-Datenbank verwenden und nicht einen symbolischen Link, der auf diese Datenbank zeigt.
Wenn Sie das NSX OVS-Kernelmodul verwenden, müssen Sie use_nsx_ovs_kernel_module = True festlegen und die Kommentare der Zeilen über die bereitzustellenden Volumes entfernen:
# Uncomment these mounts if installing NSX-OVS kernel module # # mount host lib modules to install OVS kernel module if needed # - name: host-modules # mountPath: /lib/modules # # mount openvswitch database # - name: host-config-openvswitch # mountPath: /etc/openvswitch # - name: dir-tmp-usr-ovs-kmod-backup # # we move the usr kmod files to this dir temporarily before # # installing new OVS kmod and/or backing up existing OVS kmod backup # mountPath: /tmp/nsx_usr_ovs_kmod_backup # # mount linux headers for compiling OVS kmod # - name: host-usr-src # mountPath: /usr/src ... # Uncomment these volumes if installing NSX-OVS kernel module # - name: host-modules # hostPath: # path: /lib/modules # - name: host-config-openvswitch # hostPath: # path: /etc/openvswitch # - name: dir-tmp-usr-ovs-kmod-backup # hostPath: # path: /tmp/nsx_usr_ovs_kmod_backup # - name: host-usr-src # hostPath: # path: /usr/src
Wenn Sie hostPort für einen Pod angeben möchten, legen Sie enable_hostport_snat auf True im Abschnitt [k8s] in der nsx-node-agent-config-ConfigMap fest. In derselben ConfigMap muss use_ncp_portmap auf False (Standardwert) festgelegt werden, wenn Sie ein CNI-Plug-In installieren. Wenn Sie kein CNI-Plug-In installieren und portmap aus dem NCP-Image verwenden möchten, legen Sie use_ncp_portmap auf True fest.
ingress: - from: - namespaceSelector: matchLabels: project: test - podSelector: matchLabels: app: tea - ipBlock: cidr: 172.10.0.3/32 - ipBlock: cidr: 172.10.0.2/32 ...
- nsx-node-agent verwaltet Container-Netzwerkschnittstellen. Er interagiert mit dem CNI-Plugin und dem Kubernetes-API-Server.
- nsx-kube-proxy implementiert die Kubernetes-Dienstabstraktion, indem Cluster-IPs in Pod-IPs übersetzt werden. Dadurch wird die gleiche Funktionalität wie der Upstream-kube-proxy implementiert, dieser ist jedoch nicht gegenseitig exklusiv.
- nsx-ovs führt die OpenvSwitch-Userspace-Daemons aus. Darüber hinaus wird die OVS-Bridge automatisch erstellt und IP-Adresse sowie Routen werden von node-if auf br-int zurückverschoben. Sie müssen ovs_uplink_port=ethX in der ncp.ini hinzufügen, damit sie ethX als OVS Bridge-Uplink verwenden kann.
Wenn die Worker-Knoten Ubuntu verwenden, geht ncp-ubuntu.yaml davon aus, dass das AppArmor-Kernel-Modul aktiviert ist, andernfalls lehnt Kubelet die Ausführung des nsx-node-agent-DaemonSets ab, da es mit der Option AppArmor konfiguriert ist. Für Ubuntu und SUSE ist es standardmäßig aktiviert. Um zu überprüfen, ob das Modul aktiviert ist, überprüfen Sie die Datei /sys/module/apparmor/parameters/enabled.
- Entfernen Sie die Option AppArmor :
annotations: # The following line needs to be removed container.apparmor.security.beta.kubernetes.io/nsx-node-agent: localhost/node-agent-apparmor
- Aktivieren des privilegierten Modus sowohl für die nsx-node-agent- als auch die nsx-kube-proxy-Container
securityContext: # The following line needs to be appended privileged: true
Hinweis: Wenn Kubelet innerhalb eines Containers ausgeführt wird, der das Hyperkube-Image verwendet, meldet Kubelet AppArmor unabhängig vom Ist-Zustand immer als deaktiviert. Dieselben Änderungen wie oben müssen vorgenommen und auf die YAML-Datei angewendet werden.
Aktualisieren des Namespace-Namens
In der YAML-Datei werden alle Namespace-Objekte, z. B. ServiceAccount, ConfigMap und Deployment, unter dem nsx-system-Namespace erstellt. Wenn Sie einen anderen Namespace verwenden, ersetzen Sie alle Instanzen von nsx-system.
Sichern und Wiederherstellen aktivieren
NCP unterstützt die Sicherungs- und Wiederherstellungsfunktion in NSX-T. Die unterstützten Ressourcen sind Namespace, Pod und Dienst.
Hinweis: NCP muss im Richtlinienmodus konfiguriert werden.
[k8s] enable_restore = True
nsxcli > get ncp-restore status NCP restore status is INITIAL
Der Status kann INITIAL, RUNNING oder SUCCESS lauten. INITIAL bedeutet, dass die Sicherungs-/Wiederherstellungsfunktion bereit ist, aber keine Wiederherstellung ausgeführt wird. RUNNING bedeutet, dass der Wiederherstellungsvorgang in NCP ausgeführt wird. SUCCESS bedeutet, dass eine Wiederherstellung erfolgreich abgeschlossen wurde. Wenn während einer Wiederherstellung ein Fehler auftritt, startet NCP automatisch neu und versucht es erneut. Wenn der Status lange Zeit „RUNNING “ lautet, überprüfen Sie das NCP-Protokoll auf Fehlermeldungen.