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 Load Balancer-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.

Hinweis: Standardmäßig werden die Pods von kube-scheduler nicht auf dem Master-Knoten geplant. In der NCP-YAML-Datei wird eine Toleranz hinzugefügt, damit NCP-Pod auf dem Master-Knoten ausgeführt werden kann.

Konfigurieren von SNAT

Standardmäßig konfiguriert NCP SNAT für jedes Projekt. SNAT wird für Namespaces mit der folgenden Anmerkung nicht konfiguriert:
ncp/no_snat: True
Wenn Sie SNAT für keinen Namespace im Cluster verwenden möchten, konfigurieren Sie die folgende Option in der ncp.ini:
[coe]
enable_snat = False

Hinweis: Das Aktualisieren einer vorhandenen Namespace-SNAT-Anmerkung wird nicht unterstützt. Wenn Sie eine solche Aktion durchführen, wird die Topologie für den Namespace in einem inkonsistenten Zustand angezeigt, da möglicherweise eine veraltete SNAT-Regel verbleibt. Um einen solchen inkonsistenten Zustand wiederherzustellen, müssen Sie den Namespace neu erstellen.

(Nur Richtlinienmodus) Wenn SNAT für einen Cluster konfiguriert ist, ist BGP auf dem Tier-0-Router aktiviert, und Connected Interfaces & Segments ist unter Advertised tier-1 subnets ausgewählt. Wenn Sie die Route Redistribution für den Tier-0-Router konfigurieren, können Sie die folgende Option verwenden, um die Route Redistribution zu steuern:
[nsx_v3]
configure_t0_redistribution = True 

Wenn configure_t0_redistribution auf True festgelegt ist, fügt NCP in der Neuverteilungsregel den Route-Map-Eintrag deny hinzu, um zu verhindern, dass der Tier-0-Router die internen Subnetze des Clusters an BGP-Nachbarn weitergibt. Dies wird hauptsächlich für Cluster vom Typ „vSphere with Kubernetes“ verwendet. Wenn Sie keine Route Map für die Neuverteilungsregel erstellen, erstellt NCP eine Route Map unter Verwendung seiner Prinzipalidentität und wendet sie in der Regel an. Wenn Sie diese Route Map bearbeiten möchten, müssen Sie sie durch eine neue Route Map ersetzen, die Einträge aus der von NCP erstellten Route Map kopieren und neue Einträge hinzufügen. Sie müssen alle potenziellen Konflikte zwischen den neuen Einträgen und den von NCP erstellten Einträgen verwalten. Wenn Sie die von NCP erstellte Route Map einfach aufheben, ohne eine neue Route Map für die Neuverteilungsregel zu erstellen, wendet NCP die zuvor erstellte Route Map erneut auf die Neuverteilungsregel an, sobald NCP neu startet.

Aktualisieren der nsx-node-agent-DaemonSet-Spezifikationen

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

Wenn Sie nicht das NSX OVS-Kernelmodul verwenden, müssen Sie den Volume-Parameter host-original-ovs-db mit dem richtigen Pfad aktualisieren, in dem die OpenvSwitch-Datenbank während der Zusammenstellung des OVS-Kernelmoduls konfiguriert ist. Wenn Sie beispielsweise --sysconfdir=/var/lib angeben, legen Sie host-original-ovs-db auf /var/lib/openvswitch fest.

Wenn Sie das NSX OVS-Kernelmodul verwenden, müssen Sie use_nsx_ovs_kernel_module = True festlegen und die Kommentare der Zeilen über die bereitzustellenden Volumes entfernen:

  # Uncomment these mounts if installing NSX-OVS kernel module
#   # mount host lib modules to install OVS kernel module if needed
#   - name: host-modules
#     mountPath: /lib/modules
#   # mount openvswitch database
#   - name: host-config-openvswitch
#     mountPath: /etc/openvswitch
#   - name: dir-tmp-usr-ovs-kmod-backup
#   # we move the usr kmod files to this dir temporarily before
#   # installing new OVS kmod and/or backing up existing OVS kmod backup
#     mountPath: /tmp/nsx_usr_ovs_kmod_backup

#   # mount linux headers for compiling OVS kmod
#   - name: host-usr-src
#     mountPath: /usr/src

...

# Uncomment these volumes if installing NSX-OVS kernel module
# - name: host-modules
#   hostPath:
#     path: /lib/modules
# - name: host-config-openvswitch
#   hostPath:
#     path: /etc/openvswitch
# - name: dir-tmp-usr-ovs-kmod-backup
#   hostPath:
#     path: /tmp/nsx_usr_ovs_kmod_backup

# - name: host-usr-src
#   hostPath:
#     path: /usr/src
Der NSX-Knotenagent ist ein DaemonSet, wobei von jedem Pod 3 Container ausgeführt werden.
  • 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.