24.17. Déploiement d'un pod routeur de sortie en mode redirection


En tant qu'administrateur de cluster, vous pouvez déployer un pod routeur de sortie pour rediriger le trafic vers des adresses IP de destination spécifiées à partir d'une adresse IP source réservée.

L'implémentation du routeur de sortie utilise le plugin CNI (Container Network Interface) du routeur de sortie.

24.17.1. Ressource personnalisée du routeur de sortie

Définir la configuration d'un module de routeur de sortie dans une ressource personnalisée de routeur de sortie. Le fichier YAML suivant décrit les champs de configuration d'un routeur de sortie en mode redirection :

apiVersion: network.operator.openshift.io/v1
kind: EgressRouter
metadata:
  name: <egress_router_name>
  namespace: <namespace>  <.>
spec:
  addresses: [  <.>
    {
      ip: "<egress_router>",  <.>
      gateway: "<egress_gateway>"  <.>
    }
  ]
  mode: Redirect
  redirect: {
    redirectRules: [  <.>
      {
        destinationIP: "<egress_destination>",
        port: <egress_router_port>,
        targetPort: <target_port>,  <.>
        protocol: <network_protocol>  <.>
      },
      ...
    ],
    fallbackIP: "<egress_destination>" <.>
  }

<.> Facultatif : Le champ namespace indique l'espace de noms dans lequel le routeur de sortie doit être créé. Si vous ne spécifiez pas de valeur dans le fichier ou sur la ligne de commande, l'espace de noms default est utilisé.

<.> Le champ addresses spécifie les adresses IP à configurer sur l'interface réseau secondaire.

<.> Le champ ip spécifie l'adresse IP source réservée et le masque de réseau du réseau physique sur lequel se trouve le nœud à utiliser avec le pod du routeur de sortie. Utilisez la notation CIDR pour spécifier l'adresse IP et le masque de réseau.

<.> Le champ gateway indique l'adresse IP de la passerelle réseau.

<.> Facultatif : Le champ redirectRules spécifie une combinaison d'adresse IP de destination de sortie, de port de routeur de sortie et de protocole. Les connexions entrantes au routeur de sortie sur le port et le protocole spécifiés sont acheminées vers l'adresse IP de destination.

<.> Facultatif : Le champ targetPort indique le port réseau de l'adresse IP de destination. Si ce champ n'est pas spécifié, le trafic est acheminé vers le même port réseau que celui par lequel il est arrivé.

<.> Le champ protocol prend en charge TCP, UDP ou SCTP.

<.> Facultatif : Le champ fallbackIP spécifie une adresse IP de destination. Si vous ne spécifiez aucune règle de redirection, le routeur de sortie envoie tout le trafic à cette adresse IP de repli. Si vous spécifiez des règles de redirection, toutes les connexions aux ports réseau qui ne sont pas définies dans les règles sont envoyées par le routeur de sortie à cette adresse IP de repli. Si vous ne spécifiez pas ce champ, le routeur de sortie rejette les connexions aux ports réseau qui ne sont pas définis dans les règles.

Exemple de spécification d'un routeur de sortie

apiVersion: network.operator.openshift.io/v1
kind: EgressRouter
metadata:
  name: egress-router-redirect
spec:
  networkInterface: {
    macvlan: {
      mode: "Bridge"
    }
  }
  addresses: [
    {
      ip: "192.168.12.99/24",
      gateway: "192.168.12.1"
    }
  ]
  mode: Redirect
  redirect: {
    redirectRules: [
      {
        destinationIP: "10.0.0.99",
        port: 80,
        protocol: UDP
      },
      {
        destinationIP: "203.0.113.26",
        port: 8080,
        targetPort: 80,
        protocol: TCP
      },
      {
        destinationIP: "203.0.113.27",
        port: 8443,
        targetPort: 443,
        protocol: TCP
      }
    ]
  }

Vous pouvez déployer un routeur de sortie pour rediriger le trafic de sa propre adresse IP source réservée vers une ou plusieurs adresses IP de destination.

Après l'ajout d'un routeur de sortie, 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.

Conditions préalables

  • Installez le CLI OpenShift (oc).
  • Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

  1. Créer une définition de routeur de sortie.
  2. Pour que les autres modules puissent trouver l'adresse IP du module de routeur de sortie, créez un service qui utilise le routeur de sortie, comme dans l'exemple suivant :

    apiVersion: v1
    kind: Service
    metadata:
      name: egress-1
    spec:
      ports:
      - name: web-app
        protocol: TCP
        port: 8080
      type: ClusterIP
      selector:
        app: egress-router-cni <.>

    <.> Spécifier l'étiquette pour le routeur de sortie. La valeur indiquée est ajoutée par l'opérateur du réseau de cluster et n'est pas configurable.

    Après avoir créé le service, vos pods peuvent se connecter au service. Le pod routeur de sortie redirige le trafic vers le port correspondant de l'adresse IP de destination. Les connexions proviennent de l'adresse IP source réservée.

Vérification

Pour vérifier que l'opérateur du réseau de clusters a démarré le routeur de sortie, suivez la procédure suivante :

  1. Affichez la définition de l'attachement au réseau que l'opérateur a créée pour le routeur de sortie :

    $ oc get network-attachment-definition egress-router-cni-nad

    Le nom de la définition de l'attachement réseau n'est pas configurable.

    Exemple de sortie

    NAME                    AGE
    egress-router-cni-nad   18m

  2. Affichez le déploiement du module de routeur de sortie :

    $ oc get deployment egress-router-cni-deployment

    Le nom du déploiement n'est pas configurable.

    Exemple de sortie

    NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
    egress-router-cni-deployment   1/1     1            1           18m

  3. Affichez l'état du pod du routeur de sortie :

    $ oc get pods -l app=egress-router-cni

    Exemple de sortie

    NAME                                            READY   STATUS    RESTARTS   AGE
    egress-router-cni-deployment-575465c75c-qkq6m   1/1     Running   0          18m

  4. Affichez les journaux et la table de routage pour le pod du routeur de sortie.
  1. Obtenir le nom du nœud pour le pod du routeur de sortie :

    $ POD_NODENAME=$(oc get pod -l app=egress-router-cni -o jsonpath="{.items[0].spec.nodeName}")
  2. Entrez dans une session de débogage sur le nœud cible. Cette étape instancie un pod de débogage appelé <node_name>-debug:

    $ oc debug node/$POD_NODENAME
  3. Définissez /host comme répertoire racine dans le shell de débogage. Le pod de débogage monte le système de fichiers racine de l'hôte dans /host au sein du pod. En changeant le répertoire racine en /host, vous pouvez exécuter des binaires à partir des chemins d'exécution de l'hôte :

    # chroot /host
  4. Dans la console de l'environnement chroot, affichez les journaux du routeur de sortie :

    # cat /tmp/egress-router-log

    Exemple de sortie

    2021-04-26T12:27:20Z [debug] Called CNI ADD
    2021-04-26T12:27:20Z [debug] Gateway: 192.168.12.1
    2021-04-26T12:27:20Z [debug] IP Source Addresses: [192.168.12.99/24]
    2021-04-26T12:27:20Z [debug] IP Destinations: [80 UDP 10.0.0.99/30 8080 TCP 203.0.113.26/30 80 8443 TCP 203.0.113.27/30 443]
    2021-04-26T12:27:20Z [debug] Created macvlan interface
    2021-04-26T12:27:20Z [debug] Renamed macvlan to "net1"
    2021-04-26T12:27:20Z [debug] Adding route to gateway 192.168.12.1 on macvlan interface
    2021-04-26T12:27:20Z [debug] deleted default route {Ifindex: 3 Dst: <nil> Src: <nil> Gw: 10.128.10.1 Flags: [] Table: 254}
    2021-04-26T12:27:20Z [debug] Added new default route with gateway 192.168.12.1
    2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat PREROUTING -i eth0 -p UDP --dport 80 -j DNAT --to-destination 10.0.0.99
    2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat PREROUTING -i eth0 -p TCP --dport 8080 -j DNAT --to-destination 203.0.113.26:80
    2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat PREROUTING -i eth0 -p TCP --dport 8443 -j DNAT --to-destination 203.0.113.27:443
    2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat -o net1 -j SNAT --to-source 192.168.12.99

    L'emplacement du fichier de journalisation et le niveau de journalisation ne sont pas configurables lorsque vous démarrez le routeur de sortie en créant un objet EgressRouter comme décrit dans cette procédure.

  5. Dans la console de l'environnement chroot, récupérez l'identifiant du conteneur :

    # crictl ps --name egress-router-cni-pod | awk '{print $1}'

    Exemple de sortie

    CONTAINER
    bac9fae69ddb6

  6. Déterminer l'ID du processus du conteneur. Dans cet exemple, l'ID du conteneur est bac9fae69ddb6:

    # crictl inspect -o yaml bac9fae69ddb6 | grep 'pid:' | awk '{print $2}'

    Exemple de sortie

    68857

  7. Entrez l'espace de noms du réseau du conteneur :

    # nsenter -n -t 68857
  8. Afficher la table de routage :

    # ip route

    Dans l'exemple suivant, l'interface réseau net1 est la route par défaut. Le trafic pour le réseau cluster utilise l'interface réseau eth0. Le trafic destiné au réseau 192.168.12.0/24 utilise l'interface réseau net1 et provient de l'adresse IP source réservée 192.168.12.99. Le pod achemine tout le reste du trafic vers la passerelle à l'adresse IP 192.168.12.1. Le routage pour le réseau de service n'est pas montré.

    Exemple de sortie

    default via 192.168.12.1 dev net1
    10.128.10.0/23 dev eth0 proto kernel scope link src 10.128.10.18
    192.168.12.0/24 dev net1 proto kernel scope link src 192.168.12.99
    192.168.12.1 dev net1

Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2026 Red Hat
Retour au début