Die meisten Schritte zur Vorbereitung der Kubernetes-Knoten werden durch zwei Container (nsx-ovs- und nsx-ncp-Bootstrap) automatisiert, die jeweils in den nsx-node-agent- und nsx-ncp-Bootstrap-DaemonSets ausgeführt werden.

Stellen Sie vor der Installation von NCP sicher, dass Python auf den Kubernetes-Knoten installiert und über die Befehlszeilenschnittstelle zugänglich ist. Sie können Ihren Linux-Paketmanager verwenden, um es zu installieren. Beispielsweise können Sie auf Ubuntu den Befehl apt install python ausführen.

Bei Ubuntu wird beim Installieren des NSX-CNI-Plugins die AppArmor-Profildatei ncp-apparmor in /etc/apparmor.d kopiert und geladen. Vor der Installation muss der AppArmor-Dienst ausgeführt werden, und das Verzeichnis /etc/apparmor.d muss vorhanden sein. Andernfalls schlägt die Installation fehl. Sie können mit dem folgenden Befehl prüfen, ob das AppArmor-Modul aktiviert ist: 
    sudo cat /sys/module/apparmor/parameters/enabled
Sie können mit dem folgenden Befehl prüfen, ob der AppArmor-Dienst gestartet wurde: 
    sudo /etc/init.d/apparmor status

Die ncp-apparmor-Profildatei stellt ein AppArmor-Profil für den NSX-Knotenagent mit dem Namen node-agent-apparmor bereit, das sich vom docker-default-Profil wie folgt unterscheidet:

  • Die deny mount-Regel wird entfernt.
  • Die mount-Regel wird hinzugefügt.
  • Einige network-, capability-, file- und umount-Optionen werden hinzugefügt.

Sie können das node-agent-apparmor-Profil durch ein anderes Profil ersetzen. In diesem Fall müssen Sie den Profilnamen node-agent-apparmor in der NCP-YAML-Datei ändern.

Der NSX-NCP-Bootstrap-Container automatisiert die Installation und das Update von NSX-CNI auf dem Host. In früheren Versionen wurde NSX-CNI über ein deb/rpm-Paket installiert. In der Version werden die Dateien einfach auf den Host kopiert. Der Bootstrap-Container entfernt die zuvor installierten NSX-CNI-Komponenten aus der Datenbank des Paketmanagers. Die folgenden Verzeichnisse und Dateien werden gelöscht:
  • /etc/cni/net.d
  • /etc/apparmor.d/ncp-apparmor
  • /opt/cni/bin/nsx
Der Bootstrap-Container überprüft die Datei 10-nsx.conflist und sucht im Tag nsxBuildVersion nach der CNI-Versionsnummer. Wenn diese Version älter ist als die im Bootstrap-Container, werden die folgenden Dateien auf den Host kopiert:
  • /opt/cni/bin/nsx
  • /etc/cni/net.d/99-loopback.conf
  • /etc/cni/net.d/10-nsx.conflist
  • /etc/apparmor.d/ncp-apparmor

Wenn die Dateien /opt/cni/bin/loopback und /etc/cni/net.d/99-loopback.conf vorhanden sind, werden Sie nicht überschrieben. Wenn es sich bei dem Betriebssystemtyp um Ubuntu handelt, wird die Datei ncp-apparmor ebenfalls auf den Host kopiert.

Der Bootstrap-Container verschiebt die IP-Adresse und die Routen von br-int auf node-if. Außerdem wird OVS gestoppt, wenn es auf dem Host ausgeführt wird, da OVS innerhalb des nsx-ovs-Containers läuft. Der nsx-ovs-Container erstellt die br-int-Instanz, wenn Sie nicht vorhanden ist, fügen Sie die Netzwerkschnittstelle (node-if) hinzu, die mit dem logischen Switch des Knotens auf br-int angefügt ist, und stellen Sie sicher, dass der Linkstatus br-int und node-if aktiviert ist. Außerdem werden IP-Adresse und Routen von node-if auf br-int verschoben. Es kommt zu einer Ausfallzeit von einigen Sekunden, wenn der nsx-node-agent-Pod oder der nsx-ovs-Container neu gestartet wird.

Hinweis: Wenn das NSX-Node-Agent-DaemonSet entfernt wird, wird OVS nicht mehr auf dem Host (im Container oder in der PID des Hosts) gestartet.
Aktualisieren Sie die Netzwerkkonfiguration, damit IP-Adresse und Routen persistent werden. Bearbeiten Sie z. B. für Ubuntu /etc/network/interfaces (verwenden Sie ggf. tatsächliche Werte aus Ihrer Umgebung), damit IP-Adresse und Routen persistent werden: 
auto eth1
iface eth1 inet static
address 172.16.1.4/24
#persistent static routes
up route add -net 172.16.1.3/24 gw 172.16.1.1 dev eth1

Führen Sie dann den Befehl ifdown eth1; ifup eth1 aus.

Erstellen und bearbeiten Sie für RHEL /etc/sysconfig/network-scripts/ifcfg-<node-if> (verwenden Sie ggf. tatsächliche Werte aus Ihrer Umgebung), damit die IP-Adresse persistent wird: 
HWADDR=00:0C:29:B7:DC:6F
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
IPADDR=172.10.0.2
PREFIX=24
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV4_DNS_PRIORITY=100
IPV6INIT=no
NAME=eth1
UUID=39317e23-909b-45fc-9951-849ece53cb83
DEVICE=eth1
ONBOOT=yes

Führen Sie dann den Befehl systemctl restart network.service aus.

Informationen zum Konfigurieren von persistenten Routen für RHEL finden Sie unter https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-configuring_static_routes_in_ifcfg_files.

Hinweis: IP- und statische Routen müssen auf der Uplink-Schnittstelle beibehalten werden (angegeben durch ovs_uplink_port), um sicherzustellen, dass die Konnektivität mit dem Kubernetes-API-Server nach einem Neustart der VM nicht verloren geht.
Hinweis: Standardmäßig verfügt nsx-ovs über eine Volumebereitstellung mit dem Namen host-original-ovs-db und dem Pfad /etc/openvswitch. Dies ist der Standardpfad, den OVS zum Speichern der Datei conf.db verwendet. Wenn OVS für die Verwendung eines anderen Pfads konfiguriert wurde oder wenn es sich bei dem Pfad um einen Soft-Link handelt, müssen Sie die host-original-ovs-db-Bereitstellung mit dem richtigen Pfad aktualisieren.

Bei Bedarf können Sie die vom Bootstrap-Container vorgenommenen Änderungen rückgängig machen. Weitere Informationen finden Sie unter Kubernetes-Knoten bereinigen.