25.2. Configuration des IP de sortie pour un projet
En tant qu'administrateur de cluster, vous pouvez configurer le plugin réseau OpenShift SDN Container Network Interface (CNI) pour attribuer une ou plusieurs adresses IP de sortie à un projet.
25.2.1. Conception architecturale et mise en œuvre de l'adresse IP de sortie
La fonctionnalité d'adresse IP de sortie d'OpenShift Container Platform vous permet de vous assurer que le trafic d'un ou plusieurs pods dans un ou plusieurs espaces de noms a une adresse IP source cohérente pour les services en dehors du réseau du cluster.
Par exemple, vous pouvez avoir un pod qui interroge périodiquement une base de données hébergée sur un serveur extérieur à votre cluster. Pour appliquer les conditions d'accès au serveur, un dispositif de filtrage des paquets est configuré pour n'autoriser le trafic qu'à partir d'adresses IP spécifiques. Pour garantir la fiabilité de l'accès au serveur à partir de ce module spécifique, vous pouvez configurer une adresse IP de sortie spécifique pour le module qui envoie les requêtes au serveur.
Une adresse IP de sortie attribuée à un espace de noms est différente d'un routeur de sortie, qui est utilisé pour envoyer le trafic vers des destinations spécifiques.
Dans certaines configurations de cluster, les pods d'application et les pods de routeur d'entrée fonctionnent sur le même nœud. Si vous configurez une adresse IP de sortie pour un projet d'application dans ce scénario, l'adresse IP n'est pas utilisée lorsque vous envoyez une requête à une route à partir du projet d'application.
Une adresse IP de sortie est mise en œuvre sous la forme d'une adresse IP supplémentaire sur l'interface réseau principale d'un nœud et doit se trouver dans le même sous-réseau que l'adresse IP principale du nœud. L'adresse IP supplémentaire ne doit être attribuée à aucun autre nœud de la grappe.
Les adresses IP de sortie ne doivent pas être configurées dans les fichiers de configuration du réseau Linux, tels que ifcfg-eth0
.
25.2.1.1. Soutien à la plate-forme
La prise en charge de la fonctionnalité d'adresse IP de sortie sur diverses plates-formes est résumée dans le tableau suivant :
Plate-forme | Soutenu |
---|---|
Métal nu | Oui |
VMware vSphere | Oui |
Plate-forme Red Hat OpenStack (RHOSP) | Oui |
Amazon Web Services (AWS) | Oui |
Google Cloud Platform (GCP) | Oui |
Microsoft Azure | Oui |
L'attribution d'adresses IP de sortie aux nœuds du plan de contrôle avec la fonctionnalité EgressIP n'est pas prise en charge sur un cluster provisionné sur Amazon Web Services (AWS). (BZ#2039656)
25.2.1.2. Considérations relatives à la plateforme de cloud public
Pour les clusters provisionnés sur une infrastructure de cloud public, il existe une contrainte sur le nombre absolu d'adresses IP assignables par nœud. Le nombre maximal d'adresses IP assignables par nœud, ou le IP capacitypeut être décrit par la formule suivante :
IP capacity = public cloud default capacity - sum(current IP assignments)
Bien que la fonction Egress IPs gère la capacité d'adresses IP par nœud, il est important de tenir compte de cette contrainte dans vos déploiements. Par exemple, pour un cluster installé sur une infrastructure bare-metal avec 8 nœuds, vous pouvez configurer 150 adresses IP de sortie. Toutefois, si un fournisseur de cloud public limite la capacité d'adresses IP à 10 adresses IP par nœud, le nombre total d'adresses IP assignables n'est que de 80. Pour obtenir la même capacité d'adresses IP dans cet exemple de fournisseur de cloud, il faudrait allouer 7 nœuds supplémentaires.
Pour confirmer la capacité IP et les sous-réseaux de n'importe quel nœud de votre environnement de cloud public, vous pouvez entrer la commande oc get node <node_name> -o yaml
. L'annotation cloud.network.openshift.io/egress-ipconfig
comprend des informations sur la capacité et les sous-réseaux du nœud.
La valeur d'annotation est un tableau contenant un objet unique dont les champs fournissent les informations suivantes pour l'interface réseau primaire :
-
interface
: Spécifie l'ID de l'interface sur AWS et Azure et le nom de l'interface sur GCP. -
ifaddr
: Spécifie le masque de sous-réseau pour une ou les deux familles d'adresses IP. -
capacity
: Spécifie la capacité d'adresses IP pour le nœud. Sur AWS, la capacité d'adresses IP est fournie par famille d'adresses IP. Sur Azure et GCP, la capacité d'adresses IP comprend les adresses IPv4 et IPv6.
L'attachement et le détachement automatiques des adresses IP de sortie pour le trafic entre les nœuds sont disponibles. Cela permet au trafic de nombreux pods dans les espaces de noms d'avoir une adresse IP source cohérente vers des emplacements en dehors du cluster. Cela prend également en charge OpenShift SDN et OVN-Kubernetes, qui est le plugin de mise en réseau par défaut dans Red Hat OpenShift Networking dans OpenShift Container Platform 4.12.
La fonctionnalité RHOSP egress IP address crée un port de réservation Neutron appelé egressip-<IP address>
. En utilisant le même utilisateur RHOSP que celui utilisé pour l'installation du cluster OpenShift Container Platform, vous pouvez attribuer une adresse IP flottante à ce port de réservation afin de disposer d'une adresse SNAT prévisible pour le trafic de sortie. Lorsqu'une adresse IP de sortie sur un réseau RHOSP est déplacée d'un nœud à un autre, en raison d'un basculement de nœud, par exemple, le port de réservation Neutron est supprimé et recréé. Cela signifie que l'association IP flottante est perdue et que vous devez réassigner manuellement l'adresse IP flottante au nouveau port de réservation.
Lorsqu'un administrateur de cluster RHOSP assigne une IP flottante au port de réservation, OpenShift Container Platform ne peut pas supprimer le port de réservation. L'objet CloudPrivateIPConfig
ne peut pas effectuer d'opérations de suppression et de déplacement jusqu'à ce qu'un administrateur de cluster RHOSP désassigne l'IP flottante du port de réservation.
Les exemples suivants illustrent l'annotation des nœuds de plusieurs fournisseurs de nuages publics. Les annotations sont en retrait pour faciliter la lecture.
Exemple d'annotation cloud.network.openshift.io/egress-ipconfig
sur AWS
cloud.network.openshift.io/egress-ipconfig: [ { "interface":"eni-078d267045138e436", "ifaddr":{"ipv4":"10.0.128.0/18"}, "capacity":{"ipv4":14,"ipv6":15} } ]
Exemple cloud.network.openshift.io/egress-ipconfig
annotation sur GCP
cloud.network.openshift.io/egress-ipconfig: [ { "interface":"nic0", "ifaddr":{"ipv4":"10.0.128.0/18"}, "capacity":{"ip":14} } ]
Les sections suivantes décrivent la capacité d'adresses IP pour les environnements de cloud public pris en charge, à utiliser dans votre calcul de capacité.
25.2.1.2.1. Limites de capacité des adresses IP d'Amazon Web Services (AWS)
Sur AWS, les contraintes d'attribution des adresses IP dépendent du type d'instance configuré. Pour plus d'informations, voir Adresses IP par interface réseau par type d'instance
25.2.1.2.2. Limites de capacité des adresses IP de Google Cloud Platform (GCP)
Sur le GCP, le modèle de réseau met en œuvre des adresses IP de nœuds supplémentaires par le biais de l'alias d'adresses IP, plutôt que par l'attribution d'adresses IP. Toutefois, la capacité d'adresses IP est directement liée à la capacité d'alias d'adresses IP.
Les limites de capacité suivantes s'appliquent à l'attribution de l'alias IP :
- Le nombre maximum d'alias IP, tant IPv4 qu'IPv6, est de 10 par nœud.
- Par VPC, le nombre maximum d'alias IP n'est pas spécifié, mais les tests d'évolutivité d'OpenShift Container Platform révèlent que le maximum est d'environ 15 000.
Pour plus d'informations, voir Quotas par instance et Aperçu des plages d'adresses IP alias.
25.2.1.2.3. Limites de capacité des adresses IP de Microsoft Azure
Sur Azure, les limites de capacité suivantes existent pour l'attribution d'adresses IP :
- Par NIC, le nombre maximum d'adresses IP assignables, tant pour IPv4 que pour IPv6, est de 256.
- Par réseau virtuel, le nombre maximum d'adresses IP attribuées ne peut dépasser 65 536.
Pour plus d'informations, voir Limites de mise en réseau.
25.2.1.3. Limites
Les limitations suivantes s'appliquent lors de l'utilisation d'adresses IP de sortie avec le plugin réseau SDN OpenShift :
- Vous ne pouvez pas utiliser des adresses IP de sortie attribuées manuellement et automatiquement sur les mêmes nœuds.
- Si vous attribuez manuellement des adresses IP de sortie à partir d'une plage d'adresses IP, vous ne devez pas rendre cette plage disponible pour l'attribution automatique d'adresses IP.
- Vous ne pouvez pas partager les adresses IP de sortie entre plusieurs espaces de noms en utilisant l'implémentation de l'adresse IP de sortie d'OpenShift SDN.
Si vous devez partager des adresses IP entre plusieurs espaces de noms, l'implémentation de l'adresse IP de sortie du plugin réseau OVN-Kubernetes vous permet de répartir les adresses IP entre plusieurs espaces de noms.
Si vous utilisez OpenShift SDN en mode multitenant, vous ne pouvez pas utiliser d'adresses IP de sortie avec un espace de noms qui est joint à un autre espace de noms par les projets qui leur sont associés. Par exemple, si project1
et project2
sont joints en exécutant la commande oc adm pod-network join-projects --to=project1 project2
, aucun des deux projets ne peut utiliser d'adresse IP de sortie. Pour plus d'informations, voir BZ#1645577.
25.2.1.4. Méthodes d'attribution des adresses IP
Vous pouvez attribuer des adresses IP de sortie à des espaces de noms en définissant le paramètre egressIPs
de l'objet NetNamespace
. Une fois qu'une adresse IP de sortie est associée à un projet, OpenShift SDN vous permet d'attribuer des adresses IP de sortie à des hôtes de deux manières :
- Dans cette approche, une plage d'adresses IP de sortie est attribuée à un nœud automatically assigned une plage d'adresses IP de sortie est attribuée à un nœud.
- Dans cette approche, une liste d'une ou plusieurs adresses IP de sortie est attribuée à un nœud manually assigned une liste d'une ou plusieurs adresses IP de sortie est attribuée à un nœud.
Les espaces de noms qui demandent une adresse IP de sortie sont mis en correspondance avec les nœuds qui peuvent héberger ces adresses IP de sortie, puis les adresses IP de sortie sont attribuées à ces nœuds. Si le paramètre egressIPs
est défini sur un objet NetNamespace
, mais qu'aucun nœud n'héberge cette adresse IP de sortie, le trafic de sortie de l'espace de noms sera abandonné.
La haute disponibilité des nœuds est automatique. Si un nœud hébergeant une adresse IP de sortie est inaccessible et qu'il existe des nœuds capables d'héberger cette adresse IP de sortie, l'adresse IP de sortie est déplacée vers un nouveau nœud. Lorsque le nœud inaccessible revient en ligne, l'adresse IP de sortie est automatiquement déplacée afin d'équilibrer les adresses IP de sortie entre les nœuds.
25.2.1.4.1. Points à prendre en compte lors de l'utilisation d'adresses IP de sortie attribuées automatiquement
Les considérations suivantes s'appliquent lors de l'utilisation de l'approche d'attribution automatique pour les adresses IP de sortie :
-
Vous définissez le paramètre
egressCIDRs
de la ressourceHostSubnet
de chaque nœud pour indiquer la plage d'adresses IP de sortie pouvant être hébergées par un nœud. OpenShift Container Platform définit le paramètreegressIPs
de la ressourceHostSubnet
en fonction de la plage d'adresses IP spécifiée.
Si le nœud hébergeant l'adresse IP de sortie de l'espace de noms est inaccessible, OpenShift Container Platform réattribuera l'adresse IP de sortie à un autre nœud avec une plage d'adresses IP de sortie compatible. L'approche d'attribution automatique fonctionne mieux pour les clusters installés dans des environnements offrant une certaine flexibilité dans l'association d'adresses IP supplémentaires aux nœuds.
25.2.1.4.2. Points à prendre en considération lors de l'utilisation d'adresses IP de sortie attribuées manuellement
Cette approche permet de contrôler quels nœuds peuvent héberger une adresse IP de sortie.
Si votre cluster est installé sur une infrastructure de cloud public, vous devez vous assurer que chaque nœud auquel vous attribuez des adresses IP de sortie dispose d'une capacité de réserve suffisante pour héberger les adresses IP. Pour plus d'informations, voir "Considérations sur la plate-forme" dans une section précédente.
Les considérations suivantes s'appliquent à l'attribution manuelle des adresses IP de sortie :
-
Le paramètre
egressIPs
de la ressourceHostSubnet
de chaque nœud indique les adresses IP qui peuvent être hébergées par un nœud. - Plusieurs adresses IP de sortie par espace de noms sont prises en charge.
Si un espace de noms possède plusieurs adresses IP de sortie et que ces adresses sont hébergées sur plusieurs nœuds, les considérations supplémentaires suivantes s'appliquent :
- Si un pod se trouve sur un nœud hébergeant une adresse IP de sortie, ce pod utilise toujours l'adresse IP de sortie du nœud.
- Si un pod ne se trouve pas sur un nœud hébergeant une adresse IP de sortie, il utilise une adresse IP de sortie aléatoire.
25.2.2. Configuration des adresses IP de sortie attribuées automatiquement à un espace de noms
Dans OpenShift Container Platform, vous pouvez activer l'attribution automatique d'une adresse IP de sortie pour un espace de noms spécifique sur un ou plusieurs nœuds.
Conditions préalables
-
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin
. -
Vous avez installé l'OpenShift CLI (
oc
).
Procédure
Mettez à jour l'objet
NetNamespace
avec l'adresse IP de sortie en utilisant le JSON suivant :$ oc patch netnamespace <project_name> --type=merge -p \ '{ "egressIPs": [ "<ip_address>" ] }'
où :
<project_name>
- Spécifie le nom du projet.
<ip_address>
-
Spécifie une ou plusieurs adresses IP de sortie pour le réseau
egressIPs
.
Par exemple, pour attribuer à
project1
une adresse IP de 192.168.1.100 et àproject2
une adresse IP de 192.168.1.101 :$ oc patch netnamespace project1 --type=merge -p \ '{"egressIPs": ["192.168.1.100"]}' $ oc patch netnamespace project2 --type=merge -p \ '{"egressIPs": ["192.168.1.101"]}'
NoteComme OpenShift SDN gère l'objet
NetNamespace
, vous ne pouvez effectuer des changements qu'en modifiant l'objetNetNamespace
existant. Ne créez pas de nouvel objetNetNamespace
.Indiquez quels nœuds peuvent héberger des adresses IP de sortie en définissant le paramètre
egressCIDRs
pour chaque hôte à l'aide du JSON suivant :$ oc patch hostsubnet <node_name> --type=merge -p \ '{ "egressCIDRs": [ "<ip_address_range>", "<ip_address_range>" ] }'
où :
<node_name>
- Spécifie un nom de nœud.
<ip_address_range>
-
Spécifie une plage d'adresses IP au format CIDR. Vous pouvez spécifier plusieurs plages d'adresses pour le réseau
egressCIDRs
.
Par exemple, pour configurer
node1
etnode2
afin qu'ils hébergent des adresses IP de sortie dans la plage 192.168.1.0 à 192.168.1.255 :$ oc patch hostsubnet node1 --type=merge -p \ '{"egressCIDRs": ["192.168.1.0/24"]}' $ oc patch hostsubnet node2 --type=merge -p \ '{"egressCIDRs": ["192.168.1.0/24"]}'
OpenShift Container Platform attribue automatiquement des adresses IP de sortie spécifiques aux nœuds disponibles de manière équilibrée. Dans ce cas, elle attribue l'adresse IP de sortie 192.168.1.100 à
node1
et l'adresse IP de sortie 192.168.1.101 ànode2
ou vice versa.
25.2.3. Configuration des adresses IP de sortie attribuées manuellement pour un espace de noms
Dans OpenShift Container Platform, vous pouvez associer une ou plusieurs adresses IP de sortie à un espace de noms.
Conditions préalables
-
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin
. -
Vous avez installé l'OpenShift CLI (
oc
).
Procédure
Mettez à jour l'objet
NetNamespace
en spécifiant l'objet JSON suivant avec les adresses IP souhaitées :$ oc patch netnamespace <project_name> --type=merge -p \ '{ "egressIPs": [ "<ip_address>" ] }'
où :
<project_name>
- Spécifie le nom du projet.
<ip_address>
-
Spécifie une ou plusieurs adresses IP de sortie pour le réseau
egressIPs
.
Par exemple, pour attribuer le projet
project1
aux adresses IP192.168.1.100
et192.168.1.101
:$ oc patch netnamespace project1 --type=merge \ -p '{"egressIPs": ["192.168.1.100","192.168.1.101"]}'
Pour assurer une haute disponibilité, définissez la valeur
egressIPs
sur deux adresses IP ou plus sur des nœuds différents. Si plusieurs adresses IP de sortie sont définies, les pods utilisent toutes les adresses IP de sortie de manière à peu près égale.NoteComme OpenShift SDN gère l'objet
NetNamespace
, vous ne pouvez effectuer des changements qu'en modifiant l'objetNetNamespace
existant. Ne créez pas de nouvel objetNetNamespace
.Attribuer manuellement l'adresse IP de sortie aux hôtes du nœud.
Si votre cluster est installé sur une infrastructure de cloud public, vous devez confirmer que le nœud dispose d'une capacité d'adresses IP disponible.
Définissez le paramètre
egressIPs
sur l'objetHostSubnet
de l'hôte du nœud. En utilisant le JSON suivant, incluez autant d'adresses IP que vous souhaitez attribuer à cet hôte de nœud :$ oc patch hostsubnet <node_name> --type=merge -p \ '{ "egressIPs": [ "<ip_address>", "<ip_address>" ] }'
où :
<node_name>
- Spécifie un nom de nœud.
<ip_address>
-
Spécifie une adresse IP. Vous pouvez spécifier plusieurs adresses IP pour la matrice
egressIPs
.
Par exemple, pour spécifier que
node1
doit avoir les IP de sortie192.168.1.100
,192.168.1.101
et192.168.1.102
:$ oc patch hostsubnet node1 --type=merge -p \ '{"egressIPs": ["192.168.1.100", "192.168.1.101", "192.168.1.102"]}'
Dans l'exemple précédent, tout le trafic de sortie pour
project1
sera acheminé vers le nœud hébergeant l'adresse IP de sortie spécifiée, puis connecté à cette adresse IP via la traduction d'adresses de réseau (NAT).
25.2.4. Ressources supplémentaires
- Si vous configurez l'attribution manuelle d'adresses IP de sortie, reportez-vous à la section Considérations relatives à la plate-forme pour obtenir des informations sur la planification de la capacité IP.