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

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

Content feedback and comments