25.7. Considérations relatives à l'utilisation d'un module de routeur de sortie
25.7.1. À propos d'un pod de routeur de sortie
Le pod routeur egress d'OpenShift Container Platform redirige le trafic vers un serveur distant spécifié à partir d'une adresse IP source privée qui n'est pas utilisée à d'autres fins. Un pod routeur egress peut envoyer du trafic réseau à des serveurs qui sont configurés pour n'autoriser l'accès qu'à partir d'adresses IP spécifiques.
Le module de routeur de sortie n'est pas destiné à chaque connexion sortante. La création d'un grand nombre de modules de routeur de sortie peut dépasser les limites de votre matériel réseau. Par exemple, la création d'un module de routeur de sortie pour chaque projet ou application pourrait dépasser le nombre d'adresses MAC locales que l'interface réseau peut gérer avant de revenir au filtrage des adresses MAC dans le logiciel.
L'image du routeur de sortie n'est pas compatible avec Amazon AWS, Azure Cloud ou toute autre plateforme cloud qui ne prend pas en charge les manipulations de la couche 2 en raison de leur incompatibilité avec le trafic macvlan.
25.7.1.1. Modes du routeur de sortie
En redirect modeun pod routeur de sortie configure les règles iptables pour rediriger le trafic de sa propre adresse IP vers une ou plusieurs adresses IP de destination. Les modules clients qui doivent utiliser l'adresse IP source réservée doivent être modifiés pour se connecter au routeur de sortie plutôt que de se connecter directement à l'adresse IP de destination.
En HTTP proxy modeun pod de routeur de sortie fonctionne comme un proxy HTTP sur le port 8080. Ce mode ne fonctionne que pour les clients qui se connectent à des services basés sur HTTP ou HTTPS, mais il nécessite généralement moins de modifications des pods clients pour les faire fonctionner. Il est possible de demander à de nombreux programmes d'utiliser un proxy HTTP en définissant une variable d'environnement.
En DNS proxy modeun pod routeur de sortie fonctionne comme un proxy DNS pour les services basés sur TCP depuis sa propre adresse IP vers une ou plusieurs adresses IP de destination. Pour utiliser l'adresse IP source réservée, les modules clients doivent être modifiés pour se connecter au module de routeur de sortie plutôt que de se connecter directement à l'adresse IP de destination. Cette modification garantit que les destinations externes traitent le trafic comme s'il provenait d'une source connue.
Le mode de redirection fonctionne pour tous les services, à l'exception des services HTTP et HTTPS. Pour les services HTTP et HTTPS, utilisez le mode proxy HTTP. Pour les services basés sur TCP avec des adresses IP ou des noms de domaine, utilisez le mode proxy DNS.
25.7.1.2. Mise en œuvre d'un pod de routeur de sortie
La configuration du pod du routeur de sortie est effectuée par un conteneur d'initialisation. Ce conteneur s'exécute dans un contexte privilégié afin de pouvoir configurer l'interface macvlan et définir les règles iptables. Une fois que le conteneur d'initialisation a fini de configurer les règles iptables, il se termine. Ensuite, le module routeur de sortie exécute le conteneur pour gérer le trafic du routeur de sortie. L'image utilisée varie en fonction du mode du routeur de sortie.
Les variables d'environnement déterminent les adresses utilisées par l'image egress-router. L'image configure l'interface macvlan pour qu'elle utilise EGRESS_SOURCE comme adresse IP, avec EGRESS_GATEWAY comme adresse IP pour la passerelle.
Des règles de traduction d'adresses réseau (NAT) sont mises en place pour que les connexions à l'adresse IP du cluster du pod sur n'importe quel port TCP ou UDP soient redirigées vers le même port sur l'adresse IP spécifiée par la variable EGRESS_DESTINATION.
Si seuls certains nœuds de votre cluster sont capables de revendiquer l'adresse IP source spécifiée et d'utiliser la passerelle spécifiée, vous pouvez spécifier nodeName ou nodeSelector pour identifier les nœuds acceptables.
25.7.1.3. Considérations relatives au déploiement
Un pod routeur de sortie ajoute une adresse IP et une adresse MAC supplémentaires à l'interface réseau principale du nœud. Par conséquent, il se peut que vous deviez configurer votre hyperviseur ou votre fournisseur de cloud pour autoriser l'adresse supplémentaire.
- Plate-forme Red Hat OpenStack (RHOSP)
Si vous déployez OpenShift Container Platform sur RHOSP, vous devez autoriser le trafic à partir des adresses IP et MAC du pod routeur egress sur votre environnement OpenStack. Si vous n'autorisez pas le trafic, la communication échouera:
$ openstack port set --allowed-address \ ip_address=<ip_address>,mac_address=<mac_address> <neutron_port_uuid>
- Red Hat Virtualization (RHV)
- Si vous utilisez RHV, vous devez sélectionner No Network Filter pour le contrôleur d'interface réseau virtuel (vNIC).
- VMware vSphere
- Si vous utilisez VMware vSphere, consultez la documentation VMware pour sécuriser les commutateurs standard vSphere. Affichez et modifiez les paramètres par défaut de VMware vSphere en sélectionnant le commutateur virtuel de l'hôte dans le client Web vSphere.
En particulier, assurez-vous que les éléments suivants sont activés :
25.7.1.4. Configuration du basculement
Pour éviter les temps d'arrêt, vous pouvez déployer un module de routeur de sortie avec une ressource Deployment, comme dans l'exemple suivant. Pour créer un nouvel objet Service pour l'exemple de déploiement, utilisez la commande oc expose deployment/egress-demo-controller.
apiVersion: apps/v1 kind: Deployment metadata: name: egress-demo-controller spec: replicas: 1 1 selector: matchLabels: name: egress-router template: metadata: name: egress-router labels: name: egress-router annotations: pod.network.openshift.io/assign-macvlan: "true" spec: 2 initContainers: ... containers: ...
