VMware NSX Container Plugin 4.2

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

Preparazione dei nodi Kubernetes

La maggior parte dei passaggi per preparare i nodi Kubernetes sono automatizzati da due container, nsx-ovs e nsx-ncp-bootstrap, eseguiti rispettivamente nei DaemonSet nsx-node-agent e nsx-ncp-bootstrap.
Prima di installare NCP, assicurarsi che nei nodi Kubernetes sia installato Python e che sia accessibile tramite l'interfaccia della riga di comando. Per installarlo, è possibile utilizzare il gestore dei pacchetti di Linux. In Ubuntu è ad esempio possibile eseguire il comando
apt install python
.
Per Ubuntu, quando si installa il plug-in CNI di
NSX
, il file del profilo AppArmor
ncp-apparmor
 viene copiato in
/etc/apparmor.d
 e viene caricato. Prima dell'installazione, è necessario assicurarsi che il servizio AppArmor sia in esecuzione e che la directory
/etc/apparmor.d
 esista. In caso contrario, l'installazione non riuscirà. È possibile verificare se il modulo AppArmor è abilitato con il comando seguente: 
    sudo cat /sys/module/apparmor/parameters/enabled
È possibile verificare se il servizio AppArmor è avviato con il comando seguente: 
    sudo /etc/init.d/apparmor status
Il file del profilo
ncp-apparmor
 fornisce un profilo AppArmor per l'agente del nodo di NSX denominato
node-agent-apparmor
, diverso dal profilo
docker-default
 nei modi seguenti:
  • Viene rimossa la regola
    deny mount
    .
  • Viene aggiunta la regola
    mount
    .
  • Vengono aggiunte alcune opzioni di
    network
    ,
    capability
    ,
    file
     e
    umount
    .
È possibile sostituire il profilo
node-agent-apparmor
 con un profilo diverso. In tal caso, è necessario modificare il nome del profilo
node-agent-apparmor
 nel file YAML di NCP.
Il container del bootstrap NCP di NSX automatizza l'installazione e l'aggiornamento del plug-in CNI di NSX nell'host. Nelle versioni precedenti, il plug-in CNI di NSX veniva installato tramite un pacchetto deb/rpm. In questa versione i file vengono semplicemente copiati nell'host. Il container del bootstrap rimuoverà i componenti del plug-in CNI di NSX precedentemente installati dal database del gestore pacchetti. Verranno eliminate le directory e i file seguenti:
  • /etc/cni/net.d
  • /etc/apparmor.d/ncp-apparmor
  • /opt/cni/bin/nsx
Il container del bootstrap controlla il file
10-nsx.conflist
 e cerca il numero di versione di CNI nel tag
nsxBuildVersion
. Se questa versione è precedente a quella nel container del bootstrap, nell'host vengono copiati i file seguenti:
  • /opt/cni/bin/nsx
  • /etc/cni/net.d/99-loopback.conf
  • /etc/cni/net.d/10-nsx.conflist
  • /etc/apparmor.d/ncp-apparmor
Se i file
/opt/cni/bin/loopback
 e
/etc/cni/net.d/99-loopback.conf
 esistono già, non vengono sovrascritti. Se il tipo di sistema operativo è Ubuntu, nell'host viene copiato anche il file
ncp-apparmor
.
Il container del bootstrap sposterà l'indirizzo IP e le route da
br-int
 a
node-if
. Arresterà inoltre OVS se è in esecuzione nell'host perché OVS verrà eseguito nel container nsx-ovs. Il container nsx-ovs creerà l'istanza di
br-int
 se non esiste, aggiungerà l'interfaccia di rete (
node-if
) collegata al commutatore logico del nodo per
br-int
 e verificherà che lo stato dei collegamenti
br-int
 e
node-if
 sia attivo. Sposterà l'indirizzo IP e le route da
node-if
 a
br-int
. Quando il pod nsx-node-agent o il container nsx-ovs viene riavviato, si verifica un tempo di inattività di alcuni secondi.
Se il DaemonSet nsx-node-agent viene rimosso, OVS non viene più eseguito nell'host (nel container o nel PID dell'host).
Aggiornare la configurazione di rete per rendere persistenti l'indirizzo IP e le route. Ad esempio, per Ubuntu modificare
/etc/network/interfaces
 (se appropriato, utilizzare i valori effettivi dell'ambiente in uso) per rendere persistenti l'indirizzo IP e le route:
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
Eseguire quindi il comando
ifdown eth1; ifup eth1
.
Per RHEL, creare e modificare
/etc/sysconfig/network-scripts/ifcfg-<node-if>
 (se appropriato, utilizzare i valori effettivi dell'ambiente in uso) per rendere persistente l'indirizzo IP:
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
Eseguire quindi il comando
systemctl restart network.service
.
Le route IP e statiche devono essere persistenti nell'interfaccia di uplink (specificata da
ovs_uplink_port
) per garantire che la connettività al server dell'API Kubernetes non venga persa dopo il riavvio della macchina virtuale.
Per impostazione predefinita, nsx-ovs include un montaggio di volume con nome
host-original-ovs-db
 e percorso
/etc/openvswitch
. Questo è il percorso predefinito utilizzato da OVS per archiviare il file
conf.db
. Se OVS è stato configurato per utilizzare un percorso diverso o se il percorso è un soft link, è necessario aggiornare il montaggio di
host-original-ovs-db
 con il percorso corretto.
Se necessario, è possibile annullare le modifiche apportate dal container del bootstrap. Per ulteriori informazioni, vedere Pulizia dei nodi Kubernetes.

Content feedback and comments