Masquerade - réseau d'infrastructure en grappe (NAT)

Utilisez ce réseau comme choix par défaut pour le réseau principal de l'infrastructure du cluster et pour les pods qui s'exécutent dans le cluster. Si vous l'utilisez pour les réseaux de machines virtuelles, cela fonctionne comme une machine virtuelle derrière une règle NAT sur un NSX Edge :

• Les machines virtuelles peuvent établir des connexions sortantes vers l'extérieur.
• Les machines virtuelles ne peuvent pas recevoir de connexions entrantes directes provenant de sources externes. Le trafic doit passer par un équilibreur de charge ou un service, tout comme vous utiliseriez une règle NAT de destination (DNAT) sur un NSX Edge pour rendre un service accessible.
• Les machines virtuelles utilisent l'attribution automatique d'adresses IP. Ce n'est pas toi qui t'en occupes.
• Les machines virtuelles peuvent utiliser l'ensemble des fonctionnalités réseau d' Kubernetes, notamment les équilibreurs de charge, les services, les politiques réseau et le DNS.

Certains cas d'utilisation en périphérie peuvent nécessiter la mise en place d'un réseau « masquerade » pour votre machine virtuelle, notamment lorsque vos machines virtuelles ont besoin d'un accès direct aux services Kubernetes. Cependant, la plupart des cas d'utilisation des machines virtuelles ne font pas appel au réseau « masquerade ».

Réseau de machines virtuelles de couche 2 primaire - directement routable (liaison montante BGP)

Cette topologie équivaut à un segment overlay NSX connecté à une passerelle « Tier-0 » sur laquelle la redistribution des routes BGP est activée. Utilisez cette option, moins courante, lorsque vous avez besoin que les machines virtuelles soient directement accessibles depuis des réseaux externes sans passer par un équilibreur de charge ou un NAT :

• Les machines virtuelles reçoivent des adresses IP directement du sous-réseau du segment et restent accessibles depuis l'extérieur grâce au routage.
• Les réseaux externes accèdent aux machines virtuelles individuelles via les annonces de routes BGP émises par chaque nœud de travail. Cette approche correspond à ce que fait le routeur de service (SR) NSX Edge lorsqu'il redistribue les routes connectées.
• Les machines virtuelles prennent en charge la multidiffusion et la diffusion générale.
• Les espaces de noms ne peuvent pas utiliser la fonctionnalité « masquerade » lorsque vous activez un réseau principal de couche 2. Les deux ne peuvent pas coexister.

À l'heure actuelle, le VPC ne prend pas en charge le service de routage dynamique (BGP, Border Gateway Protocol); par conséquent, il est nécessaire d'utiliser des routes VPC personnalisées avec un saut suivant.

L'attribution des adresses IP s'effectue selon un système DHCP fonctionnant selon le principe du « premier arrivé, premier servi ». Les adresses IP ne changent pas pendant toute la durée de vie d'une machine virtuelle, mais il n'est pas possible d'attribuer à l'avance une adresse IP spécifique à une machine virtuelle donnée. Si vous avez besoin d'adresses IP statiques, utilisez plutôt un réseau secondaire de couche 2.

Certains cas d'utilisation en périphérie peuvent nécessiter le réseau principal pour votre machine virtuelle, notamment lorsque vos machines virtuelles ont besoin d'un accès direct aux services d' Kubernetes. Cependant, dans la plupart des cas d'utilisation des machines virtuelles, le réseau principal n'est pas utilisé.

Couche 2 secondaire - réseau des charges de travail des machines virtuelles (segment isolé)

Utilisez ce type de réseau pour la quasi-totalité des cas d'utilisation des machines virtuelles. Cette topologie équivaut à un segment overlay NSX sans liaison montante externe : un segment dédié que vous contrôlez entièrement.

• Ce réseau prend en charge l'attribution d'adresses IP statiques. Vous gérez l'adressage IP, ce qui correspond à ce que l'on attend généralement pour les charges de travail des machines virtuelles.
• Ce réseau ne se connecte pas automatiquement à l'extérieur. Pour permettre l'accès depuis l'extérieur, connectez un pare-feu ou un routeur virtuel au segment, de la même manière que vous connecteriez une machine virtuelle NSX Edge ou « pfSense » à un segment dans vSphere.
• Prend en charge la multidiffusion et la diffusion générale.
• Vous pouvez associer plusieurs réseaux secondaires de couche 2 à une même machine virtuelle. Cette configuration permet de séparer le trafic des applications, celui de la gestion et celui du stockage sur des segments distincts.
• Le réseau peut s'étendre sur plusieurs espaces de noms lorsqu'il est configuré en tant que CUDN.

Ce réseau constitue le choix idéal pour la plupart des charges de travail des machines virtuelles dans l'environnement de virtualisation d' Red Hat OpenShift.

Localnet - transmission directe des VLAN

Cette topologie est l'équivalent le plus proche d'un groupe de ports standard ou d'un groupe de ports virtuels distribués ( dvPortGroup ) basé sur un VLAN, sans superposition NSX. La machine virtuelle se connecte directement au réseau auquel l'hôte physique est connecté :

• Cette topologie n'utilise pas de réseau superposé de type SDN (Software-Defined Networking). Le trafic contourne entièrement la commutation logicielle OVN.
• Cette topologie ne prend pas en charge les services réseau d' Red Hat OpenShift on IBM Cloud, tels que l'équilibrage de charge, les politiques réseau ou le DNS interne.
• Cette topologie ne prend pas en charge la gestion intégrée des adresses IP. L'attribution des adresses IP s'effectue à l'aide des interfaces de réseau virtuel (VNI) du VPC.
• Vous configurez cette topologie par zone de disponibilité.
• Cette topologie prend en charge plusieurs réseaux locaux sur une même machine virtuelle.

Utilisez « localnet » pour les machines virtuelles qui ont besoin d'un accès direct à un sous-réseau VPC existant. Par exemple, vous pourriez migrer une charge de travail héritée qui communique avec des systèmes sur site via un VLAN spécifique ou se connecter à un réseau de stockage situé en dehors du cluster.