Préparer des nœuds Kubernetes

La plupart des étapes de préparation des nœuds Kubernetes sont automatisées par deux conteneurs, nsx-ovs et nsx-ncp-bootstrap, qui s'exécutent respectivement dans les DaemonSet nsx-node-agent et nsx-ncp-bootstrap.

Avant d'installer NCP, assurez-vous que Python est installé et accessible sur les nœuds Kubernetes à l'aide de l'interface de ligne de commande. Vous pouvez utiliser votre gestionnaire de modules Linux pour l'installer. Par exemple, sur Ubuntu, vous pouvez exécuter la commande apt install python.

Pour Ubuntu, l'installation du plug-in NSX CNI copie le fichier du profil AppArmor ncp-apparmor dans /etc/apparmor.d et le charge. Avant l'installation, le service AppArmor doit être en cours d'exécution et le répertoire /etc/apparmor.d doit exister. Sinon, l'installation va échouer. Vous pouvez vérifier si le module AppArmor est activé avec la commande suivante :

    sudo cat /sys/module/apparmor/parameters/enabled

Vous pouvez vérifier si le service AppArmor est démarré avec la commande suivante :

    sudo /etc/init.d/apparmor status

Le fichier de profil ncp-apparmor fournit un profil AppArmor pour l'agent de nœud NSX nommé node-agent-apparmor, qui diffère du profil docker-default de la manière suivante :

La règle deny mount est retirée.
La règle mount est ajoutée.
Certaines options network, capability, file et umount sont ajoutées.

Vous pouvez remplacer le profil node-agent-apparmor par un profil différent. Si vous le faites, vous devez modifier le nom de profil node-agent-apparmor dans le fichier YAML NCP.

Le conteneur de démarrage du NCP NSX automatise l'installation et la mise à jour de NSX CNI sur l'hôte. Dans les versions précédentes, NSX CNI était installé via un module deb/rpm. Dans la présente version, les fichiers sont simplement copiés sur l'hôte. Le conteneur de démarrage supprimera les composants NSX CNI précédemment installés de la base de données du gestionnaire de module. Les répertoires et fichiers suivants seront supprimés :

/etc/cni/net.d
/etc/apparmor.d/ncp-apparmor
/opt/cni/bin/nsx

Le conteneur de démarrage vérifie le fichier 10-nsx.conflist et recherche le numéro de version CNI dans la balise nsxBuildVersion. Si cette version est antérieure à celle du conteneur de démarrage, les fichiers suivants sont copiés sur l'hôte :

/opt/cni/bin/nsx
/etc/cni/net.d/99-loopback.conf
/etc/cni/net.d/10-nsx.conflist
/etc/apparmor.d/ncp-apparmor

Si les fichiers /opt/cni/bin/loopback et /etc/cni/net.d/99-loopback.conf existent, ils ne sont pas remplacés. Si le type de système d'exploitation est Ubuntu, le fichier ncp-apparmor est également copié sur l'hôte.

Le conteneur de démarrage déplacera l'adresse IP et les routes de br-int vers node-if. Il arrêtera également OVS s'il est en cours d'exécution sur l'hôte, car OVS s'exécutera dans le conteneur nsx-ovs. Le conteneur nsx-ovs créera l'instance br-int si elle n'existe pas, ajoutera l'interface réseau (node-if) attachée au commutateur logique du nœud à br-int et s'assurera que l'état du lien br-int et node-if est actif. Il déplacera l'adresse IP et les routes de node-if vers br-int. Une interruption de service de quelques secondes se produit lorsque l'espace nsx-node-agent ou le conteneur nsx-ovs est redémarré.

Note : Si le DaemonSet nsx-node-agent est supprimé, OVS n'est plus en cours d'exécution sur l'hôte (dans le conteneur ou dans le PID de l'hôte).

Mettez à jour la configuration réseau pour rendre l'adresse IP et les routes persistantes. Par exemple, pour Ubuntu, modifiez /etc/network/interfaces (utilisez les valeurs réelles de votre environnement si nécessaire) pour rendre l'adresse IP et les routes persistantes :

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

Exécutez ensuite la commande ifdown eth1; ifup eth1.

Pour RHEL, créez et modifiez /etc/sysconfig/network-scripts/ifcfg-<node-if> (utilisez les valeurs réelles de votre environnement si nécessaire) pour rendre l'adresse IP persistante :

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

Exécutez ensuite la commande systemctl restart network.service.

Pour plus d'informations sur la configuration de routes persistantes pour RHEL, reportez-vous à https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-configuring_static_routes_in_ifcfg_files.

Note : Les routes IP et statiques doivent être conservées sur l'interface de liaison montante (spécifiée par ovs_uplink_port) pour garantir que la connectivité au serveur d'API Kubernetes n'est pas perdue après un redémarrage de la VM.

Note : Par défaut, nsx-ovs dispose d'un montage de volume avec le nom host-original-ovs-db et le chemin /etc/openvswitch. Il s'agit du chemin par défaut qu'OVS utilise pour stocker le fichier conf.db. Si OVS a été configuré pour utiliser un chemin différent ou si le chemin d'accès est un lien logiciel, vous devez mettre à jour le montage host-original-ovs-db avec le bon chemin.

Si nécessaire, vous pouvez annuler les modifications effectuées par le conteneur de démarrage. Pour plus d'informations, reportez-vous à la section Nettoyer les nœuds Kubernetes.