Configuration des ressources NSX-T en mode Gestionnaire

Il existe deux méthodes pour configurer certaines ressources de mise en réseau pour NCP. Cette section décrit la configuration des ressources en mode de gestionnaire.

Dans le fichier de configuration NCP ncp.ini, vous pouvez spécifier les ressources NSX-T à l'aide de leurs UUID ou de leur nom.

Routeurs logiques et commutateur logique

1. Créez un commutateur logique pour les nœuds Kubernetes, par exemple, LS1.
2. Créez un routeur logique de niveau 0, par exemple, T0LR1. Définissez l'option tier0_router dans la section [nsx_v3] de ncp.ini avec l'identifiant du routeur logique si vous ne disposez pas d'une topologie de niveau 1 partagée. Reportez-vous aux informations ci-dessous pour plus d'informations sur la configuration d'une topologie de niveau 1 partagée. Définissez le mode HA sur actif-en veille si vous prévoyez de configurer des règles NAT sur ce routeur logique. Sinon, définissez-le sur actif-actif. Activez la redistribution de routes. Configurez également ce routeur pour l'accès au réseau externe.
3. Créez un routeur logique de niveau 1, par exemple, T1LR1. Connectez ce routeur logique au routeur logique de niveau 0.
4. Configurez l'annonce du routeur pour T1LR1. Les routes NAT et connectés à NSX au minimum doivent être activées.
5. Connectez T1LR1 à LS1. Assurez-vous que l'adresse IP du port du routeur logique n'est pas en conflit avec les adresses IP des nœuds Kubernetes.
6. Pour chaque machine virtuelle de nœud, assurez-vous que le vNIC de trafic de conteneur est attaché au commutateur logique qui est automatiquement créé. Vous pouvez le trouver dans l'onglet Mise en réseau avec le même nom que le commutateur logique, c'est-à-dire LS1.

NCP doit connaître l'identifiant de VIF du vNIC. Les ports du commutateur logique correspondant doivent avoir les deux balises suivantes : Pour une balise, spécifiez le nom du nœud. Pour l'autre balise, spécifiez le nom du cluster. Pour la portée, spécifiez la valeur appropriée comme indiqué ci-dessous.

Balise	Portée
Nom du nœud	ncp/node_name
Nom du cluster	ncp/cluster

Si le nom du nœud change, vous devez mettre à jour la balise. Pour récupérer le nom du nœud, vous pouvez exécuter la commande suivante :

kubectl get nodes

Si vous souhaitez étendre le cluster Kubernetes alors que NCP est en cours d'exécution, par exemple, ajouter des nœuds au cluster, vous devez ajouter les balises aux ports de commutateur correspondants avant d'exécuter « kubeadm join ». Si vous oubliez d'ajouter les balises avant d'exécuter « kubeadm join », les nouveaux nœuds n'auront pas de connectivité. Dans ce cas, vous devez ajouter les balises et redémarrer NCP pour résoudre le problème.

Pour identifier le port de commutateur pour une machine virtuelle de nœud, vous pouvez effectuer l'appel d'API suivant :

/api/v1/fabric/virtual-machines

Dans la réponse, recherchez la machine virtuelle de nœud et récupérez la valeur de l'attribut « external_id ». Ou vous pouvez effectuer l'appel d'API suivant :

/api/v1/search -G --data-urlencode "query=(resource_type:VirtualMachine AND display_name:<node_vm_name>)"

Une fois que vous avez l'identifiant externe, vous pouvez l'utiliser pour récupérer les VIF de la machine virtuelle avec l'API suivante. Notez que les VIF ne sont pas renseignés tant que la machine virtuelle n'est pas démarrée.

/api/v1/search -G --data-urlencode \
"query=(resource_type:VirtualNetworkInterface AND external_id:<node_vm_ext_id> AND \
_exists_:lport_attachment_id)"

L'attribut lport_attachment_id est l'identifiant de VIF de la machine virtuelle de nœud. Vous pouvez ensuite trouver le port logique de ce VIF et ajouter les balises requises.

Blocs d'adresses IP pour des espaces Kubernetes

Accédez à Mise en réseau > Pools d'adresses IP pour créer un ou plusieurs blocs d'adresses IP. Spécifiez le bloc d'adresses IP au format CIDR. Définissez l'option container_ip_blocks dans la section [nsx_v3] de ncp.ini dans les UUID des blocs d'adresses IP.

Par défaut, les projets partagent des blocs d'adresses IP spécifiés dans container_ip_blocks. Vous pouvez créer des blocs d'adresses IP spécifiquement pour les espaces de noms non-SNAT (pour Kubernetes) ou pour les clusters (pour TAS) en définissant l'option no_snat_ip_blocks dans la section [nsx_v3] de ncp.ini.

Si vous créez des blocs d'adresses IP non SNAT alors que NCP est en cours d'exécution, vous devez redémarrer NCP. Sinon, NCP continuera d'utiliser les blocs d'adresses IP partagés jusqu'à leur épuisement.

Lorsque vous créez un bloc d'adresses IP, le préfixe ne doit pas être supérieur à la valeur de l'option subnet_prefix dans le fichier de configuration de NCP ncp.ini. La valeur par défaut est 24.

NCP allouera des sous-réseaux supplémentaires pour un espace de noms si le sous-réseau alloué initialement est épuisé.

Pools d'adresses IP externes

Le pool d'adresses IP externe sert à allouer des adresses IP qui seront utilisées pour la traduction d'adresses IP d'espace à l'aide de règles SNAT et pour l'exposition de contrôleurs d'entrée et de services de type LoadBalancer à l'aide de règles SNAT/DNAT, comme des adresses IP flottantes OpenStack. Ces adresses IP sont également appelées adresses IP externes.

Accédez à Mise en réseau > Pools d'adresses IP > Pools d'adresses IP pour créer un pool d'adresses IP. Définissez l'option external_ip_pools dans la section [nsx_v3] de ncp.ini dans les UUID des pools d'adresses IP.

Plusieurs clusters Kubernetes utilisent le même pool d'adresses IP externes. Chaque instance NCP utilise un sous-ensemble de ce pool pour le cluster Kubernetes qu'il gère. Par défaut, le même préfixe de sous-réseau pour les sous-réseaux d'espace sera utilisé. Pour utiliser une taille de sous-réseau différente, mettez à jour l'option external_subnet_prefix dans la section [nsx_v3] dans ncp.ini.

Vous pouvez spécifier un pool d'adresses IP différent en modifiant le fichier de configuration et en redémarrant NCP.

Topologie de niveau 1 partagée

Pour activer une topologie de niveau 1 partagée, effectuez les configurations suivantes :

• Définissez l'option top_tier_router sur l'identifiant d'un routeur logique de niveau 0 ou d'un routeur logique de niveau 1. S'il s'agit d'un routeur logique de niveau 1, vous devez le connecter à un routeur logique de niveau 0 pour les connexions externes. Cette option remplace l'option tier0_router.
• Si SNAT pour le trafic d'espaces est activé, déconnectez T1LR1 de LS1 (le commutateur logique pour les nœuds Kubernetes) et connectez l'ensemble de routeurs de niveau 0 ou de niveau 1 dans top_tier_router à LS1.
• Définissez l'option single_tier_topology sur Vrai. La valeur par défaut est Faux.

(Facultatif) (pour Kubernetes uniquement) Sections de marqueur de pare-feu

Pour permettre à l'administrateur de créer des règles de pare-feu et les empêcher d'interférer avec les sections de pare-feu créées par NCP et basées sur des stratégies réseau, accédez à Sécurité > Pare-feu distribué > Général et créez deux sections de pare-feu.

Spécifiez les sections de pare-feu de marqueur en définissant les options bottom_firewall_section_marker et top_firewall_section_marker dans la section [nsx_v3] de ncp.ini.

La section de pare-feu inférieure doit se trouver sous la section de pare-feu supérieure. Une fois ces sections de pare-feu créées, toutes les sections de pare-feu créées par NCP pour une isolation sont créées au-dessus de la section de pare-feu inférieure, et toutes les sections de pare-feu créées par NCP pour une stratégie sont créées en dessous de la section de pare-feu supérieure. Si ces sections de marqueur ne sont pas créées, toutes les règles d'isolation sont créées en bas et toutes les sections de stratégie sont créées en haut. L'utilisation de plusieurs sections de pare-feu de marqueur possédant la même valeur par cluster n'est pas prise en charge et provoque une erreur.