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-T-CNI-Plug-Ins 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.conf 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.conf
  • /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.

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.

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