VMware NSX Container Plugin 4.1

4.2 4.1 4.0 3.2 3.1 3.0
简体中文 Deutsch Español Français Italiano 日本語 한국어 繁體中文 English

Vorbereiten von Kubernetes-Knoten

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

Content feedback and comments