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

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

Per informazioni sulla configurazione di route persistenti per RHEL, vedere https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-configuring_static_routes_in_ifcfg_files.

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

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