La mayoría de los pasos para preparar los nodos de Kubernetes se automatizan con dos contenedores, nsx-ovs y nsx-ncp-bootstrap, que se ejecutan en los DaemonSets sx-node-agent y nsx-ncp-bootstrap, respectivamente.

Antes de instalar NCP, asegúrese de que los nodos de Kubernetes tengan instalado Python y se pueda acceder a ellos a través de la interfaz de línea de comandos. Puede utilizar el administrador del paquete de Linux para instalarlo. Por ejemplo, en Ubuntu, puede ejecutar el comando apt install python.

En Ubuntu, al instalar el complemento CNI de NSX-T, se copiará el archivo de perfil de AppArmor ncp-apparmor en /etc/apparmor.d y se cargará. Antes de la instalación, el servicio de AppArmor debe estar en ejecución y el directorio /etc/apparmor.d debe existir. De lo contrario, se producirá un error en la instalación. Puede comprobar si el módulo de AppArmor está habilitado con el siguiente comando: 
    sudo cat /sys/module/apparmor/parameters/enabled
Puede comprobar si el servicio de AppArmor se inició con el siguiente comando: 
    sudo /etc/init.d/apparmor status

El archivo de perfil ncp-apparmor proporciona un perfil de AppArmor para el agente de nodo NSX llamado node-agent-apparmor, que se diferencia del perfil docker-default en los siguientes aspectos:

  • Se elimina la regla deny mount.
  • Se agrega la regla mount.
  • Se agregan algunas opciones de network, capability, file y umount.

Puede reemplazar el perfil node-agent-apparmor con otro perfil. Si lo hace, debe cambiar el nombre del perfil node-agent-apparmor en el archivo YAML de NCP.

El contenedor de arranque de NCP de NSX automatiza la instalación y la actualización de NSX CNI en el host. En versiones anteriores, NSX CNI se instalaba a través de un paquete deb/rpm. En esta versión, los archivos simplemente se copian en el host. El contenedor de arranque quitará los componentes de NSX CNI instalados anteriormente de la base de datos del administrador de paquetes. Se eliminarán los siguientes directorios y archivos:
  • /etc/cni/net.d
  • /etc/apparmor.d/ncp-apparmor
  • /opt/cni/bin/nsx
El contenedor de arranque comprueba el archivo 10-nsx.conflist y busca el número de versión de CNI en la etiqueta nsxBuildVersion. Si esta versión es anterior a la del contenedor de arranque, se copiarán los siguientes archivos en el host:
  • /opt/cni/bin/nsx
  • /etc/cni/net.d/99-loopback.conf
  • /etc/cni/net.d/10-nsx.conflist
  • /etc/apparmor.d/ncp-apparmor

Si los archivos /opt/cni/bin/loopback y /etc/cni/net.d/99-loopback.conf existen, no se sobrescribirán. Si el tipo de sistema operativo es Ubuntu, el archivo ncp-apparmor también se copiará en el host.

El contenedor de arranque moverá la dirección IP y las rutas de br-int a node-if. También se detendrá OVS si se está ejecutando en el host, ya que OVS se ejecutará dentro del contenedor nsx-ovs. El contenedor nsx-ovs creará la instancia de br-int si no existe, agregará la interfaz de red (node-if) que está conectada a través del conmutador lógico del nodo a br-int y se asegurará de que los vínculos br-int y node-if estén activos. Moverá la dirección IP y las rutas de node-if a br-int. Se producirá un periodo de inactividad de unos segundos cuando se reinicie el contenedor nsx-node-agent o nsx-ovs.

Nota: Si se elimina el DaemonSet nsx-node-agent, OVS no podrá ejecutarse en el host (ni en el contenedor ni en el PID del host).
Actualice la configuración de red para que la dirección IP y las rutas sean persistentes. Por ejemplo, para Ubuntu, edite /etc/network/interfaces (utilice los valores reales del entorno donde corresponda) para que la dirección IP y las rutas sean persistentes: 
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

A continuación, ejecute el comando ifdown eth1; ifup eth1.

Para RHEL, cree y edite /etc/sysconfig/network-scripts/ifcfg-<node-if> (utilice los valores reales del entorno donde corresponda) para que la dirección IP sea persistente: 
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

A continuación, ejecute el comando systemctl restart network.service.

Para obtener más información sobre cómo configurar rutas persistentes para RHEL, consulte https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-configuring_static_routes_in_ifcfg_files.

Nota: Las rutas de direcciones IP y estáticas deben persistir en la interfaz de enlace ascendente (especificada por ovs_uplink_port) para garantizar que no se pierda la conectividad con el servidor de la API de Kubernetes después de reiniciar la máquina virtual.
Nota: De forma predeterminada, nsx-ovs tiene un montaje de volumen con el nombre host-original-ovs-db y la ruta /etc/openvswitch. Esta es la ruta predeterminada que utiliza OVS para almacenar el archivo conf.db. Si OVS se configuró para utilizar una ruta diferente o si la ruta es un vínculo flexible, deberá actualizar el montaje host-original-ovs-db con la ruta correcta.

Si es necesario, puede deshacer los cambios que realice el contenedor de arranque. Para obtener más información, consulte Limpiar los nodos de Kubernetes.