Concepts de réseau pour Azure Red Hat OpenShift

Article
06/21/2023

Ce guide propose une vue d’ensemble de la mise en réseau Azure Red Hat OpenShift sur des clusters OpenShift 4, ainsi qu’un diagramme et une liste des points de terminaison importants. Pour plus d’informations sur les principaux concepts de réseau OpenShift, consultez la documentation sur les réseaux Azure Red Hat OpenShift 4.

Lorsque vous déployez Azure Red Hat OpenShift sur OpenShift 4, l’ensemble de votre cluster est contenu dans un réseau virtuel. Dans ce réseau virtuel, vos nœuds de plan de contrôle et les nœuds Worker résident tous dans leur propre sous-réseau. Chaque sous-réseau utilise un équilibreur de charge interne et un équilibreur de charge public.

Notes

Pour plus d’informations sur les dernières modifications apportées à ARO, reportez-vous à Qu’est-ce qui est nouveau avec Azure Red Hat OpenShift.

Composants de mise en réseau

La liste suivante présente les composants réseau importants d’un cluster Azure Red Hat OpenShift.

aro-pls
- Ce point de terminaison Azure Private Link est utilisé par les ingénieurs de fiabilité des sites Microsoft et Red Hat pour gérer le cluster.
aro-internal
- Ce point de terminaison équilibre le trafic vers le serveur d’API et le trafic de service interne. Les nœuds de plan de contrôle et les nœuds Worker se trouvent dans le pool du serveur principal.
- Cet équilibreur de charge n’est pas créé par défaut. Il est créé une fois que vous avez créé un service de type LoadBalancer avec les annotations correctes. Par exemple : service.beta.kubernetes.io/azure-load-balancer-internal: "true".
aro
- Ce point de terminaison est utilisé pour tout trafic public. Lorsque vous créez une application et une route, ce point de terminaison est le chemin pour le trafic d’entrée.
- Ce point de terminaison achemine et équilibre également le trafic vers le serveur API (si l’API est publique). Ce point de terminaison assigne une adresse IP sortante publique afin que les plans de contrôle puissent accéder à Azure Resource Manager et rapporter l’intégrité du cluster.
- Cet équilibreur de charge couvre également la connectivité Internet sortante à partir de tout pod s’exécutant dans les nœuds Worker via les règles de trafic sortant Azure Load Balancer.
  - Actuellement, les règles de trafic sortant ne sont pas configurables. Elles allouent 1 024 ports TCP à chaque nœud.
  - DisableOutboundSnat n’est pas configuré dans les règles d’équilibreur de charge. Par conséquent, les pods peuvent obtenir comme adresse IP de sortie toute adresse IP publique configurée dans cet équilibreur de charge Azure.
  - En conséquence des deux points précédents, le seul moyen d’ajouter des ports SNAT éphémères consiste à ajouter des services publics de type LoadBalancer à ARO.
aro-nsg
- Lorsque vous exposez un service, l’API crée une règle dans ce groupe de sécurité réseau pour que le trafic passe et atteigne le plan de contrôle et les nœuds par le port 6443.
- Par défaut, ce groupe de sécurité réseau autorise tout le trafic sortant. Actuellement, le trafic sortant peut être limité uniquement au plan de contrôle Azure Red Hat OpenShift.
Azure Container Registry
- Ce registre de conteneurs est fourni et utilisé en interne par Microsoft. Il est en lecture seule et n’est pas destiné à être utilisé par les utilisateurs Azure Red Hat OpenShift.
  - Ce registre fournit des images de plateforme hôte et des composants de cluster. Par exemple, des conteneurs de surveillance ou de journalisation.
  - Les connexions à ce registre se produisent sur le point de terminaison de service (connectivité interne entre les services Azure).
  - Par défaut, ce registre interne n’est pas disponible en dehors du cluster.
Liaison privée
- Une liaison privée autorise la connectivité réseau à partir du plan de gestion dans un cluster. Elle est utilisée par les ingénieurs de fiabilité des sites Microsoft et Red Hat afin de faciliter la gestion de votre cluster.

Stratégies réseau

Entrée : la stratégie réseau d’entrée est prise en charge dans le cadre d’OpenShift SDN. Cette stratégie réseau est activée par défaut et l’application est exécutée par les utilisateurs. Alors que la stratégie réseau d’entrée est conforme à la version V1 de NetworkPolicy, les types Sortie et IPBlock ne sont pas pris en charge.
Sortie : les stratégies réseau de sortie sont prises en charge à l’aide de la fonctionnalité de pare-feu de sortie d’OpenShift. Il n’y a qu’une seule stratégie de sortie par espace de noms/projet. Les stratégies de sortie ne sont pas prises en charge sur l’espace de noms « par défaut » et sont évaluées dans l’ordre (de la première à la dernière).

Notions de base des réseaux dans OpenShift

OpenShift SDN (Software Defined Networking) est utilisé pour configurer un réseau de superposition à l’aide d’Open vSwitch (OVS), une implémentation OpenFlow basée sur la spécification CNI (Container Network Interface). SDN prend en charge différents plug-ins. La stratégie de réseau est le plugin utilisé dans Azure Red Hat sur OpenShift 4. Toutes les communications réseau sont gérées par SDN, de sorte qu’aucune route supplémentaire n’est nécessaire sur vos réseaux virtuels pour mettre en place une communication de pod à pod.

Mise en réseau pour Azure Red Hat OpenShift

Les fonctionnalités réseau suivantes sont spécifiques à Azure Red Hat OpenShift :

Les utilisateurs peuvent créer leur cluster Azure Red Hat OpenShift dans un réseau virtuel existant ou créer un nouveau réseau virtuel lors de la création de leur cluster ARO.
Les CIDR des réseaux de service et de pod sont configurables.
Les nœuds et les plans de contrôle se trouvent dans des sous-réseaux différents.
Les nœuds et les sous-réseaux de réseau virtuel des plans de contrôle doivent être /27 au minimum.
Le CIDR de pod par défaut est 10.128.0.0/14.
Le CIDR de service par défaut est 172.30.0.0/16.
Les CIDR de pod et de réseau de service ne doivent pas chevaucher d’autres plages d’adresses en cours d’utilisation sur votre réseau. Ils ne doivent pas figurer dans la plage d’adresses IP de réseau virtuel de votre cluster.
Les CIDR de pod doivent avoir une taille minimale de /18. (Le réseau de pod est constitué d’adresses IP non routables et n’est utilisé qu’à l’intérieur d’OpenShift SDN.)
Chaque nœud se voit allouer un sous-réseau /23 (512 adresses IP) pour ses pods. Il n’est pas possible de modifier cette valeur.
Vous ne pouvez pas attacher un pod à plusieurs réseaux.
Pour les clusters ARO privés utilisant le plug-in réseau OVN-Kubernetes, il est possible de configurer des adresses IP de sortie. Pour obtenir des informations, consultez la configuration d’une adresse IP de sortie.

Paramètres réseau

Les paramètres réseau suivants sont disponibles pour les clusters Azure Red Hat OpenShift 4 :

Visibilité de l’API – Définissez la visibilité de l’API lors de l’exécution de la commande az aro create.
- « Publique » – Le serveur d’API est accessible par les réseaux externes.
- « Privée » – Le serveur d’API a affecté une adresse IP privée à partir du sous-réseau du plan de contrôle, accessible uniquement à l’aide des réseaux connectés (réseaux virtuels appairés et autres sous-réseaux du cluster).
Visibilité des entrées – Définissez la visibilité de l’API lors de l’exécution de la commande az aro create.
- Les routes « publiques » sont définies par défaut sur l’équilibreur de charge public Standard Load Balancer. (La valeur par défaut peut être modifiée.)
- Les routes « privées » sont acheminées par défaut vers un équilibreur de charge interne. (La valeur par défaut peut être modifiée.)

Groupes de sécurité réseau

Les groupes de sécurité réseau sont créés dans le groupe de ressources du nœud, qui est verrouillé pour les utilisateurs. Les groupes de sécurité réseau sont attribués directement aux sous-réseaux et non aux cartes réseau du nœud. Les groupes de sécurité réseau ne sont pas modifiables. Les utilisateurs ne disposent pas des autorisations pour les modifier.

Avec un serveur d’API visible publiquement, vous ne pouvez pas créer des groupes de sécurité réseau et les affecter aux cartes réseau.

Transfert de domaine

Azure Red Hat OpenShift utilise CoreDNS. Le transfert de domaine peut être configuré. Vous ne pouvez pas apporter votre propre serveur DNS dans vos réseaux virtuels. Pour plus d'informations, consultez la documentation sur l’utilisation du transfert DNS.

Étapes suivantes

Pour plus d’informations sur le trafic sortant et sur ce qu’Azure Red Hat OpenShift prend en charge pour la sortie, consultez la documentation sur les stratégies de prise en charge.

Partager via