Les ressources de NSX-T Data Center que vous devez configurer incluent une zone de transport de superposition, un routeur logique de niveau 0, un commutateur logique pour connecter les machines virtuelles du nœud, des blocs d'adresses IP pour les nœuds Kubernetes et un pool d'adresses IP pour SNAT.

Important:

Si vous exécutez avec NSX-T Data Center 2.4 ou version ultérieure, vous devez configurer les ressources NSX-T à l'aide de l'onglet Mise en réseau et sécurité avancées.

Dans le fichier de configuration NCP ncp.ini, les ressources NSX-T Data Center sont spécifiées à l'aide de leurs UUID ou de leurs noms.

Zone de transport de superposition

Connectez-vous à NSX Manager et recherchez la zone de transport de superposition utilisée pour la mise en réseau de conteneur ou créez-en une.

Spécifiez une zone de transport de superposition pour un cluster en définissant l'option overlay_tz dans la section [nsx_v3] de ncp.ini. Cette étape est facultative. Si vous ne définissez pas overlay_tz, NCP récupère automatiquement l'ID de zone de transport de superposition à partir du routeur de niveau 0.

Routage logique de niveau 0

Connectez-vous à NSX Manager et recherchez le routeur utilisé pour la mise en réseau de conteneur ou créez-en un.

Spécifiez un routeur logique de niveau 0 pour un cluster en définissant l'option tier0_router dans la section [nsx_v3] de ncp.ini.

Note:

Le routeur doit être créé en mode actif-en veille.

Commutateur logique

Les cartes réseau virtuelles utilisées par le nœud pour le trafic de données doivent être connectées à un commutateur logique de superposition. Il n'est pas obligatoire que l'interface de gestion du nœud soit connectée à NSX-T Data Center, bien que cela facilite la configuration. Vous pouvez créer un commutateur logique en vous connectant à NSX Manager. Sur le commutateur, créez des ports logiques et attachez-y les cartes réseau virtuelles du nœud. Les ports logiques doivent avoir les balises suivantes :

  • balise : <cluster_name>, étendue : ncp/cluster

  • balise : <node_name>, étendue : ncp/node_name

La valeur <cluster_name> doit correspondre à la valeur de l'option cluster dans la section [coe] de ncp.ini.

Blocs d'adresses IP pour des espaces Kubernetes

Connectez-vous à NSX Manager et créer un ou plusieurs blocs d'adresses IP. Spécifiez le bloc d'adresses IP au format CIDR.

Spécifiez les blocs d'adresses IP pour les espaces Kubernetes en définissant l'option container_ip_blocks dans la section [nsx_v3] de ncp.ini.

Vous pouvez également créer des blocs d'adresses IP spécialement pour les espaces de noms non SNAT.

Spécifiez les blocs d'adresses IP non SNAT 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.

Note:

Lorsque vous créez un bloc d'adresses IP, le préfixe ne doit pas être supérieur à la valeur du paramètre subnet_prefix dans le fichier de configuration de NCP ncp.ini.

Pool d'adresses IP pour SNAT

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

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.

Connectez-vous à NSX Manager, et créez un pool ou recherchez un pool existant.

Spécifiez les pools d'adresses IP pour SNAT en définissant l'option external_ip_pools dans la section [nsx_v3] de ncp.ini.

Vous pouvez également configurer SNAT pour un service spécifique en ajoutant une annotation au service. Par exemple,

    apiVersion: v1
    kind: Service
    metadata:
      name: svc-example
      annotations:
        ncp/snat_pool: <external IP pool ID or name>
      selector:
        app: example
    ...

NCP configurera la règle SNAT pour ce service. L'adresse IP source de la règle correspond à l'ensemble des espaces de serveur principal. L'adresse IP de destination est l'adresse IP SNAT allouée à partir du pool d'adresses IP externe spécifié. Notez les points suivants :

  • Le pool d'adresses IP spécifié par ncp/snat_pool doit déjà exister dans NSX-T Data Center avant que le service ne soit configuré. Le pool d'adresses IP doit avoir la balise {"ncp/owner": cluster:<cluster>}.

  • Dans NSX-T Data Center, la priorité de la règle SNAT pour le service est supérieure à celle du projet.

  • Si un espace est configuré avec plusieurs règles SNAT, une seule fonctionnera.

Vous pouvez spécifier l'espace de noms auquel les adresses IP sont allouées à partir du pool d'adresses IP SNAT en ajoutant la balise suivante au pool d'adresses IP.

  • étendue : ncp/owner, balise : ns:<namespace_UUID>

Vous pouvez obtenir l'UUID de l'espace de noms à l'aide de l'une des commandes suivantes :

oc get ns -o yaml

Notez les points suivants :

  • Chaque balise doit spécifier un UUID. Vous pouvez créer plusieurs balises pour le même pool.

  • Si vous modifiez les balises après l'allocation d'adresses IP à des espaces de noms selon les anciennes balises, ces adresses IP sont récupérées uniquement après la modification des configurations SNAT des services ou le redémarrage de NCP.

  • La balise de propriétaire d'un espace de noms est facultative. Sans cette balise, les adresses IP du pool IP SNAT peuvent être allouées à n'importe quel espace de noms.

(Facultatif) Sections de marqueur de pare-feu

Pour permettre à l'administrateur de créer des règles de pare-feu et que celles-ci n'interfèrent pas avec les sections de pare-feu créées par NCP et basées sur des stratégies réseau, connectez-vous à NSX Manager et créer 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.