Bearbeiten der NCP-YAML-Datei

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

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

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

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

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 die Optionen nsx_api_cert_file und nsx_api_private_key_file für die Authentifizierung mit NSX-T an. Die Option nsx_api_cert_file ist der vollständige Pfad zu einer Clientzertifikatdatei im PEM-Format. Der Inhalt dieser Datei sollte wie folgt aussehen:
```
-----BEGIN CERTIFICATE-----
<certificate_data_base64_encoded>
-----END CERTIFICATE-----
```
Die Option nsx_api_private_key_file ist der vollständige Pfad zu einer privaten Clientschlüsseldatei im PEM-Format. Der Inhalt dieser Datei sollte wie folgt aussehen:
```
-----BEGIN PRIVATE KEY-----
<private_key_data_base64_encoded>
-----END PRIVATE KEY-----
```
Mithilfe der Clientzertifikatauthentifizierung kann NCP ihre Prinzipalidentität zum Erstellen von NSX-T-Objekten verwenden. Dies bedeutet, dass nur eine Identität mit demselben Identitätsnamen die Objekte ändern oder löschen kann. Dadurch wird verhindert, dass NSX-T-Objekte, die von NCP erstellt wurden, versehentlich geändert oder gelöscht werden. Beachten Sie, dass ein Administrator beliebige Objekte ändern oder löschen kann. Wenn das Objekt mit einer Prinzipalidentität erstellt wurde, wird dies in Form einer Warnung angegeben.
(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.

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

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 System > Fabric > Knoten öffnen, die Registerkarte Edge-Cluster auswählen und auf den Namen des Edge-Clusters klicken.

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

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

ncp/no_snat: True

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

[coe]
enable_snat = False

Hinweis: 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.

Aktualisieren der nsx-node-agent-DaemonSet-Spezifikationen

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

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. Beispielsweise: ovs_uplink_port=eth1

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

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

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.

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

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.