Flux de trafic réseau pour les nœuds hybrides - Amazon EKS
Nœud hybride kubelet vers plan de contrôle EKSNœud hybride kube-proxy vers plan de contrôle EKSPlan de contrôle EKS vers nœud hybride (serveur kubelet)Pods exécutés sur des nœuds hybrides vers le plan de contrôle EKSPlan de contrôle EKS pour les pods exécutés sur un nœud hybride (webhooks)Pod-to-Pod exécuté sur des nœuds hybridesDes pods sur des nœuds cloud vers des pods sur des nœuds hybrides (trafic est-ouest)

Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Flux de trafic réseau pour les nœuds hybrides

Cette page détaille les flux de trafic réseau pour les nœuds hybrides EKS à l’aide de schémas illustrant les chemins réseau de bout en bout pour les différents types de trafic.

Les flux de trafic suivants sont couverts :

Nœud hybride kubelet vers plan de contrôle EKS

Nœud hybride kubelet vers plan de contrôle EKS

Demande

1kubelet. Lance une demande

Lorsque kubelet sur un nœud hybride doit communiquer avec le plan de contrôle EKS (par exemple, pour signaler l’état du nœud ou obtenir les spécifications du pod), il utilise le kubeconfig fourni lors de l’enregistrement du nœud. Ce kubeconfig possède l’URL du point de terminaison du serveur API (le nom DNS Route53) plutôt que d’adresses IP directes.

Le kubelet effectue une recherche DNS pour le point de terminaison (par exemple, https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com ). Dans un cluster à accès public, cela se résout en une adresse IP publique (par exemple 54.239.118.52) qui appartient au service EKS s’exécutant dans AWS. Le kubelet crée ensuite une requête HTTPS sécurisée vers ce point de terminaison. Le paquet initial ressemble à ceci :

+--------------------+---------------------+-----------------+
| IP Header          | TCP Header          | Payload         |
| Src: 10.80.0.2     | Src: 52390 (random) |                 |
| Dst: 54.239.118.52 | Dst: 443            |                 |
+--------------------+---------------------+-----------------+

2. Routage du routeur local

Étant donné que l’adresse IP de destination est une adresse IP publique et ne fait pas partie du réseau sur site, le kubelet envoie ce paquet à sa passerelle par défaut (le routeur local sur site). Le routeur examine l’adresse IP de destination et détermine qu’il s’agit d’une adresse IP publique.

Pour le trafic public, le routeur transfère généralement le paquet vers une passerelle Internet ou un routeur frontalier qui gère le trafic sortant vers Internet. Ceci n’apparaît pas dans le schéma et dépendra de la configuration de votre réseau sur site. Le paquet traverse votre infrastructure réseau sur site et atteint finalement le réseau de votre fournisseur d’accès Internet.

3. Livraison au plan de commande EKS

Le paquet transite par l’Internet public et les réseaux de transit jusqu’à ce qu’il atteigne le réseau de AWS. Le réseau de AWS achemine le paquet vers le point de terminaison du service EKS dans la région appropriée. Lorsque le paquet atteint le service EKS, il est transféré vers le plan de contrôle EKS réel de votre cluster.

Ce routage via l’Internet public est différent du chemin privé routé par VPC que nous verrons dans d’autres flux de trafic. La principale différence réside dans le fait que, lorsque vous utilisez le mode d’accès public, le trafic provenant des kubelet locales (mais pas des pods) vers le plan de contrôle EKS ne passe pas par votre VPC, mais utilise plutôt l’infrastructure Internet mondiale.

Réponse

Une fois que le plan de contrôle EKS a traité la demande kubelet, il renvoie une réponse :

3. Le plan de contrôle EKS envoie une réponse

Le plan de contrôle EKS crée un paquet de réponse. Ce paquet a l’adresse IP publique comme source et l’adresse IP du nœud hybride comme destination :

+--------------------+---------------------+-----------------+
| IP Header          | TCP Header          | Payload         |
| Src: 54.239.118.52 | Src: 443            |                 |
| Dst: 10.80.0.2     | Dst: 52390          |                 |
+--------------------+---------------------+-----------------+

2. Routage Internet

Le paquet de réponse retourne sur Internet, en suivant le chemin de routage déterminé par les fournisseurs d’accès Internet, jusqu’à ce qu’il atteigne le routeur périphérique de votre réseau sur site.

1. Livraison locale

Votre routeur local reçoit le paquet et reconnaît que l’adresse IP de destination (10.80.0.2) appartient à votre réseau sur site. Il transmet le paquet via votre infrastructure réseau locale jusqu’à ce qu’il atteigne le nœud hybride cible, où kubelet reçoit et traite la réponse.

Nœud hybride kube-proxy vers plan de contrôle EKS

Si vous activez l’accès public aux points de terminaison pour le cluster, le trafic de retour utilise l’Internet public. Ce trafic provient du kube-proxy sur le nœud hybride vers le plan de contrôle EKS et suit le même chemin que le trafic provenant du kubelet vers le plan de contrôle EKS.

Plan de contrôle EKS vers nœud hybride (serveur kubelet)

Plan de contrôle EKS vers nœud hybride

Demande

1. Le serveur d’API EKS Kubernetes lance une demande

Le serveur API EKS Kubernetes extrait l’adresse IP du nœud (10.80.0.2) à partir de l’état de l’objet nœud. Il achemine ensuite cette demande via son ENI dans le VPC, car l’adresse IP de destination appartient au nœud distant configuré CIDR (10.80.0.0/16). Le paquet initial ressemble à ceci :

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.132 | Src: 67493 (random) |                 |
| Dst: 10.80.0.2  | Dst: 10250          |                 |
+-----------------+---------------------+-----------------+

2. Traitement réseau VPC

Le paquet quitte l’ENI et entre dans la couche réseau VPC, où il est dirigé vers la passerelle du sous-réseau pour un routage supplémentaire.

3. Recherche dans une table de routage VPC

La table de routage VPC pour le sous-réseau contenant l’ENI du plan de contrôle EKS dispose d’un itinéraire spécifique (le deuxième dans le diagramme) pour le CIDR du nœud distant. Sur la base de cette règle de routage, le paquet est dirigé vers la passerelle VPC-to-onprem.

4. Transit transfrontalier

La passerelle transfère le paquet à travers la limite du cloud via votre connexion établie (telle que Direct Connect ou VPN) vers votre réseau sur site.

5. Réception réseau sur site

Le paquet arrive à votre routeur local sur site qui gère le trafic pour le sous-réseau où se trouvent vos nœuds hybrides.

6. Livraison finale

Le routeur local identifie que l’adresse IP (10.80.0.2) de destination appartient à son réseau directement connecté et transfère le paquet directement au nœud hybride cible, où le kubelet reçoit et traite la requête.

Réponse

Une fois que le nœud hybride kubelet a traité la demande, il renvoie une réponse en suivant le même chemin en sens inverse :

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.80.0.2  | Src: 10250          |                 |
| Dst: 10.0.0.132 | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

6. kubelet Envoie une réponse

kubeletLe nœud hybride (10.80.0.2) crée un paquet de réponse avec l’adresse IP source d’origine comme destination. La destination n’appartenant pas au réseau local, elle est envoyée à la passerelle par défaut de l’hôte, qui est le routeur local.

5. Routage du routeur local

Le routeur détermine que l’adresse IP de destination (10.0.0.132) appartient à 10.0.0.0/16, qui dispose d’une route pointant vers la passerelle connectée à AWS.

4. Retour transfrontalier

Le paquet retourne par la même connexion locale vers VPC (telle que Direct Connect ou VPN), franchissant la limite du cloud dans le sens inverse.

3. Routage VPC

Lorsque le paquet arrive dans le VPC, les tables de routage identifient que l’adresse IP de destination appartient à un CIDR VPC. Les acheminements de paquets au sein du VPC.

2. Livraison de réseaux VPC

La couche réseau VPC transmet le paquet au sous-réseau avec le plan de contrôle EKS ENI (10.0.0.132).

1. Réception ENI

Le paquet atteint le plan de contrôle EKS ENI connecté au serveur API Kubernetes, achevant ainsi son aller-retour.

Pods exécutés sur des nœuds hybrides vers le plan de contrôle EKS

Pods exécutés sur des nœuds hybrides vers le plan de contrôle EKS

Sans CNI NAT

Demande

Les pods communiquent généralement avec le serveur API Kubernetes via le service kubernetes. L’adresse IP du service est la première adresse IP du service CIDR du cluster. Cette convention permet aux pods qui doivent s’exécuter avant que CoreDNS soit disponible d’accéder au serveur API, par exemple le CNI. Les demandes quittent le pod avec l’adresse IP du service comme destination. Par exemple, si le CIDR du service est 172.16.0.0/16, l’adresse IP du service sera 172.16.0.1.

1. Le module lance une demande

Le pod envoie une requête à l’adresse IP kubernetes du service ()172.16.0.1 sur le port (443) du serveur API à partir d’un port source aléatoire. Le paquet se présente comme suit :

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.56 | Src: 67493 (random) |                 |
| Dst: 172.16.0.1 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+

2. Traitement CNI

Le CNI détecte que l’adresse IP de destination n’appartient à aucun des pods CIDR qu’il gère. Comme le NAT sortant est désactivé, le CNI transmet le paquet à la pile réseau hôte sans le modifier.

3. Traitement du réseau de nœuds

Le paquet entre dans la pile réseau du nœud où des hooks netfilter déclenchent les règles iptables définies par kube-proxy. Plusieurs règles s’appliquent dans l’ordre suivant :

  1. Le paquet atteint d’abord la chaîne KUBE-SERVICES, qui contient les règles correspondant à l’adresse IP du cluster et au port de chaque service.

  2. La règle de correspondance passe à la chaîne KUBE-SVC-XXX pour le service kubernetes (paquets destinés à 172.16.0.1:443), qui contient les règles d’équilibrage de charge.

  3. La règle d’équilibrage de charge sélectionne aléatoirement l’une des chaînes KUBE-SEP-XXX pour les adresses IP ENI du plan de contrôle (10.0.0.132 ou 10.0.1.23).

  4. La chaîne KUBE-SEP-XXX sélectionnée possède la règle réelle qui change l’adresse IP de destination de l’adresse IP du service à l’adresse IP sélectionnée. C’est ce qu’on appelle la traduction d’adresses réseau de destination (DNAT).

Une fois ces règles appliquées, en supposant que l’adresse IP de l’ENI du plan de contrôle EKS sélectionné soit 10.0.0.132, le paquet se présente comme suit :

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.56 | Src: 67493 (random) |                 |
| Dst: 10.0.0.132 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+

Le nœud transmet le paquet à sa passerelle par défaut car l’adresse IP de destination ne se trouve pas sur le réseau local.

4. Routage du routeur local

Le routeur local détermine que l’adresse IP de destination (10.0.0.132) appartient au CIDR VPC (10.0.0.0/16) et la transfère vers la passerelle connectée à AWS.

5. Transit transfrontalier

Le paquet passe par votre connexion établie (telle que Direct Connect ou VPN) à travers la limite du cloud jusqu’au VPC.

6. Livraison de réseaux VPC

La couche réseau VPC achemine le paquet vers le sous-réseau approprié où se trouve l’ENI (10.0.0.132) du plan de contrôle EKS.

7. Réception ENI

Le paquet atteint le plan de contrôle EKS ENI attaché au serveur d’API Kubernetes.

Réponse

Une fois que le plan de contrôle EKS a traité la demande, il renvoie une réponse au pod :

7. Le serveur API envoie une réponse

Le serveur d’API EKS Kubernetes crée un paquet de réponse avec l’adresse IP source d’origine comme destination. Le paquet se présente comme suit :

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.132 | Src: 443            |                 |
| Dst: 10.85.1.56 | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

Comme l’adresse IP de destination appartient au pod distant CIDR (10.85.0.0/16) configuré, il l’envoie via son ENI dans le VPC avec le routeur du sous-réseau comme saut suivant.

6. Routage VPC

La table de routage VPC contient une entrée pour le CIDR du pod distant (10.85.0.0/16), qui dirige ce trafic vers la passerelle VPC-vers-sur-site.

5. Transit transfrontalier

La passerelle transfère le paquet à travers la limite du cloud via votre connexion établie (telle que Direct Connect ou VPN) vers votre réseau sur site.

4. Réception réseau sur site

Le paquet arrive à votre routeur local sur site.

3. Livraison au nœud

La table du routeur contient une entrée pour 10.85.1.0/24 avec 10.80.0.2 comme prochain saut, livrant le paquet à notre nœud.

2. Traitement du réseau de nœuds

Lorsque le paquet est traité par la pile réseau du nœud, conntrack (une partie de netfilter) correspond au paquet avec la connexion initialement établie par le pod. Depuis l’application initiale du DNAT, conntrack inverse le DNAT en réécrivant l’adresse IP source de l’ENI du plan de contrôle EKS vers l’adresse IP kubernetes du service :

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 172.16.0.1 | Src: 443            |                 |
| Dst: 10.85.1.56 | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

1. Traitement CNI

Le CNI identifie que l’adresse IP de destination appartient à un pod de son réseau et achemine le paquet vers l’espace de noms réseau du pod approprié.

Ce flux montre pourquoi les CIDR des pods distants doivent être correctement routables depuis le VPC jusqu’au nœud spécifique hébergeant chaque pod : l’ensemble du chemin de retour dépend du routage correct des adresses IP des pods à travers les réseaux cloud et sur site.

Avec CNI NAT

Ce flux est très similaire à celui sans CNI NAT, mais avec une différence essentielle : le CNI applique le NAT source (SNAT) au paquet avant de l’envoyer à la pile réseau du nœud. Cela modifie l’adresse IP source du paquet pour la remplacer par l’adresse IP du nœud, ce qui permet au paquet d’être renvoyé vers le nœud sans nécessiter de configuration de routage supplémentaire.

Demande

1. Le module lance une demande

Le pod envoie une requête à l’adresse IP kubernetes du service ()172.16.0.1 sur le port (443) du serveur API EKS Kubernetes à partir d’un port source aléatoire. Le paquet se présente comme suit :

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.56 | Src: 67493 (random) |                 |
| Dst: 172.16.0.1 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+

2. Traitement CNI

Le CNI détecte que l’adresse IP de destination n’appartient à aucun des pods CIDR qu’il gère. Comme le NAT sortant est activé, le CNI applique le SNAT au paquet, en remplaçant l’adresse IP source par celle du nœud avant de le transmettre à la pile réseau du nœud :

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.80.0.2  | Src: 67493 (random) |                 |
| Dst: 172.16.0.1 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+

Remarque : Dans cet exemple, les CNI et iptables sont représentés sous forme de blocs distincts pour plus de clarté, mais dans la pratique, il est possible que certains CNI utilisent iptables pour appliquer le NAT.

3. Traitement du réseau de nœuds

Ici, les règles iptables définies par kube-proxy se comportent de la même manière que dans l’exemple précédent, en répartissant la charge du paquet vers l’une des ENI du plan de contrôle EKS. Le paquet se présente maintenant comme suit :

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.80.0.2  | Src: 67493 (random) |                 |
| Dst: 10.0.0.132 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+

Le nœud transmet le paquet à sa passerelle par défaut car l’adresse IP de destination ne se trouve pas sur le réseau local.

4. Routage du routeur local

Le routeur local détermine que l’adresse IP de destination (10.0.0.132) appartient au CIDR VPC (10.0.0.0/16) et la transfère vers la passerelle connectée à AWS.

5. Transit transfrontalier

Le paquet passe par votre connexion établie (telle que Direct Connect ou VPN) à travers la limite du cloud jusqu’au VPC.

6. Livraison de réseaux VPC

La couche réseau VPC achemine le paquet vers le sous-réseau approprié où se trouve l’ENI (10.0.0.132) du plan de contrôle EKS.

7. Réception ENI

Le paquet atteint le plan de contrôle EKS ENI attaché au serveur d’API Kubernetes.

Réponse

Une fois que le plan de contrôle EKS a traité la demande, il renvoie une réponse au pod :

7. Le serveur API envoie une réponse

Le serveur d’API EKS Kubernetes crée un paquet de réponse avec l’adresse IP source d’origine comme destination. Le paquet se présente comme suit :

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.132 | Src: 443            |                 |
| Dst: 10.80.0.2  | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

Comme l’adresse IP de destination appartient au nœud distant CIDR (10.80.0.0/16) configuré, il l’envoie via son ENI dans le VPC avec le routeur du sous-réseau comme saut suivant.

6. Routage VPC

La table de routage VPC contient une entrée pour le CIDR du nœud distant (10.80.0.0/16), qui dirige ce trafic vers la passerelle VPC-vers-sur-site.

5. Transit transfrontalier

La passerelle transfère le paquet à travers la limite du cloud via votre connexion établie (telle que Direct Connect ou VPN) vers votre réseau sur site.

4. Réception réseau sur site

Le paquet arrive à votre routeur local sur site.

3. Livraison au nœud

Le routeur local identifie que l’adresse IP (10.80.0.2) de destination appartient à son réseau directement connecté et transfère le paquet directement au nœud hybride cible.

2. Traitement du réseau de nœuds

Lorsque le paquet est traité par la pile réseau du nœud, conntrack (une partie de netfilter) correspond au paquet avec la connexion initialement établie par le pod et, comme le DNAT a été appliqué à l’origine, il inverse cette opération en réécrivant l’adresse IP source de l’ENI du plan de contrôle EKS vers l’adresse IP du service kubernetes :

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 172.16.0.1 | Src: 443            |                 |
| Dst: 10.80.0.2  | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

1. Traitement CNI

Le CNI identifie que ce paquet appartient à une connexion à laquelle il a précédemment appliqué le SNAT. Il inverse le SNAT, remplaçant l’adresse IP de destination par l’adresse IP du pod :

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 172.16.0.1 | Src: 443            |                 |
| Dst: 10.85.1.56 | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

Le CNI détecte que l’adresse IP de destination appartient à un pod de son réseau et achemine le paquet vers l’espace de noms réseau du pod approprié.

Ce flux montre comment le NAT CNI peut simplifier la configuration en permettant aux paquets d’être renvoyés vers le nœud sans nécessiter de routage supplémentaire pour les CIDR des pods.

Plan de contrôle EKS pour les pods exécutés sur un nœud hybride (webhooks)

Plan de contrôle EKS pour les pods exécutés sur un nœud hybride

Ce modèle de trafic est le plus souvent observé avec les webhooks, où le plan de contrôle EKS doit initier directement des connexions vers les serveurs webhooks s’exécutant dans des pods sur des nœuds hybrides. Parmi les exemples, citons la validation et la mutation des webhooks d’admission, qui sont appelés par le serveur API pendant les processus de validation ou de mutation des ressources.

Demande

1. Le serveur d’API EKS Kubernetes lance une demande

Lorsqu’un webhook est configuré dans le cluster et qu’une opération API pertinente le déclenche, le serveur API EKS Kubernetes doit établir une connexion directe avec le pod du serveur webhook. Le serveur API recherche d’abord l’adresse IP du pod à partir de la ressource Service ou Endpoint associée au webhook.

En supposant que le pod webhook s’exécute sur un nœud hybride avec l’adresse IP 10.85.1.23, le serveur API Kubernetes EKS crée une requête HTTPS vers le point de terminaison webhook. Le paquet initial est envoyé via l’ENI du plan de contrôle EKS dans votre VPC, car l’adresse IP de destination 10.85.1.23 appartient au CIDR du pod distant configuré (10.85.0.0/16). Le paquet se présente comme suit :

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.132 | Src: 41892 (random) |                 |
| Dst: 10.85.1.23 | Dst: 8443           |                 |
+-----------------+---------------------+-----------------+

2. Traitement réseau VPC

Le paquet quitte l’ENI du plan de contrôle EKS et entre dans la couche réseau VPC avec le routeur du sous-réseau comme prochain saut.

3. Recherche dans une table de routage VPC

La table de routage VPC pour le sous-réseau contenant l’ENI du plan de contrôle EKS contient une route spécifique pour le CIDR du pod distant (10.85.0.0/16). Cette règle de routage achemine le paquet vers la passerelle VPC-to-onprem (par exemple, une passerelle privée virtuelle pour les connexions Direct Connect ou VPN) :

Destination     Target
10.0.0.0/16     local
10.85.0.0/16    vgw-id (VPC-to-onprem gateway)

4. Transit transfrontalier

La passerelle transfère le paquet à travers la limite du cloud via votre connexion établie (telle que Direct Connect ou VPN) vers votre réseau sur site. Le paquet conserve ses adresses IP source et de destination d’origine lorsqu’il traverse cette connexion.

5. Réception réseau sur site

Le paquet arrive à votre routeur local sur site. Le routeur consulte sa table de routage pour déterminer comment atteindre l’adresse 10.85.1.23. Pour que cela fonctionne, votre réseau sur site doit disposer de routes pour les CIDR des pods qui dirigent le trafic vers le nœud hybride approprié.

Dans ce cas, la table de routage du routeur contient une entrée indiquant que le sous-réseau 10.85.1.0/24 est accessible via le nœud hybride avec l’adresse IP 10.80.0.2 :

Destination     Next Hop
10.85.1.0/24    10.80.0.2

6. Livraison au nœud

Sur la base de l’entrée de la table de routage, le routeur transmet le paquet au nœud hybride (10.80.0.2). Lorsque le paquet arrive au nœud, il a le même aspect que lorsqu’il a été envoyé par le serveur API EKS Kubernetes, l’adresse IP de destination étant toujours celle du pod.

7. Traitement CNI

La pile réseau du nœud reçoit le paquet et, constatant que l’adresse IP de destination n’est pas celle du nœud, le transmet au CNI pour traitement. Le CNI identifie que l’adresse IP de destination appartient à un pod s’exécutant localement sur ce nœud et transfère le paquet vers le pod correct via les interfaces virtuelles appropriées :

Original packet -> node routing -> CNI -> Pod's network namespace

Le serveur Webhook du pod reçoit la demande et la traite.

Réponse

Une fois que le pod webhook a traité la requête, il renvoie une réponse en suivant le même chemin en sens inverse :

7. Le pod envoie une réponse

Le pod webhook crée un paquet de réponse avec sa propre adresse IP comme source et le demandeur d’origine (l’ENI du plan de contrôle EKS) comme destination :

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.23 | Src: 8443           |                 |
| Dst: 10.0.0.132 | Dst: 41892          |                 |
+-----------------+---------------------+-----------------+

Le CNI identifie que ce paquet est destiné à un réseau externe (et non à un pod local) et le transmet à la pile réseau du nœud en conservant l’adresse IP source d’origine.

6. Traitement du réseau de nœuds

Le nœud détermine que l’adresse IP de destination (10.0.0.132) ne se trouve pas dans le réseau local et transfère le paquet vers sa passerelle par défaut (le routeur local).

5. Routage du routeur local

Le routeur local consulte sa table de routage et détermine que l’adresse IP de destination (10.0.0.132) appartient au CIDR VPC (10.0.0.0/16). Il transfère le paquet vers la passerelle connectée à AWS.

4. Transit transfrontalier

Le paquet retourne par la même connexion locale vers VPC, traversant la limite du cloud dans le sens inverse.

3. Routage VPC

Lorsque le paquet arrive dans le VPC, les tables de routage identifient que l’adresse IP de destination appartient à un sous-réseau au sein du VPC. Le paquet est acheminé en conséquence au sein du VPC.

2. et 1. Plan de commande EKS ENI Receiption

Le paquet atteint l’ENI rattaché au serveur API EKS Kubernetes, complétant ainsi l’aller-retour. Le serveur API reçoit la réponse du webhook et continue à traiter la requête API initiale en fonction de cette réponse.

Ce flux de trafic montre pourquoi les CIDR des pods distants doivent être correctement configurés et routés :

  • Le VPC doit disposer de routes pour les CIDR du pod distant pointant vers la passerelle sur site

  • Votre réseau sur site doit disposer de routes pour les CIDR des pods qui dirigent le trafic vers les nœuds spécifiques hébergeant ces pods.

  • Sans cette configuration de routage, les webhooks et autres services similaires s’exécutant dans des pods sur des nœuds hybrides ne seraient pas accessibles depuis le plan de contrôle EKS.

Pod-to-Pod exécuté sur des nœuds hybrides

Pod-to-Pod s’exécutant sur des nœuds hybrides

Cette section explique comment les pods s’exécutant sur différents nœuds hybrides communiquent entre eux. Cet exemple suppose que votre CNI utilise VXLAN pour l’encapsulation, ce qui est courant pour les CNI telles que Cilium ou Calico. Le processus global est similaire pour d’autres protocoles d’encapsulation tels que Geneve ou IP-in-IP.

Demande

1. Le pod A initie la communication

Le Pod A (10.85.1.56) sur le Nœud 1 souhaite envoyer du trafic vers le Pod B (10.85.2.67) sur le Nœud 2. Le paquet initial ressemble à ceci :

+------------------+-----------------+-------------+-----------------+
| Ethernet Header  | IP Header       | TCP/UDP     | Payload         |
| Src: Pod A MAC   | Src: 10.85.1.56 | Src: 43721  |                 |
| Dst: Gateway MAC | Dst: 10.85.2.67 | Dst: 8080   |                 |
+------------------+-----------------+-------------+-----------------+

2. CNI intercepte et traite le paquet

Lorsque le paquet du pod A quitte son espace de noms réseau, le CNI l’intercepte. Le CNI consulte sa table de routage et détermine : – L’adresse IP de destination (10.85.2.67) appartient au CIDR du pod – Cette adresse IP ne se trouve pas sur le nœud local, mais appartient au nœud 2 (10.80.0.3) – Le paquet doit être encapsulé avec VXLAN.

La décision d’encapsuler est cruciale, car le réseau physique sous-jacent ne sait pas comment acheminer directement les CIDR des pods : il sait uniquement acheminer le trafic entre les adresses IP des nœuds.

Le CNI encapsule l’intégralité du paquet d’origine dans une trame VXLAN. Cela crée effectivement un « paquet dans un paquet » avec de nouveaux en-têtes :

+-----------------+----------------+--------------+------------+---------------------------+
| Outer Ethernet  | Outer IP       | Outer UDP    | VXLAN      | Original Pod-to-Pod       |
| Src: Node1 MAC  | Src: 10.80.0.2 | Src: Random  | VNI: 42    | Packet (unchanged         |
| Dst: Router MAC | Dst: 10.80.0.3 | Dst: 8472    |            | from above)               |
+-----------------+----------------+--------------+------------+---------------------------+

Points clés concernant cette encapsulation : – Le paquet externe est adressé du nœud 1 (10.80.0.2) au nœud 2 (10.80.0.3) – Le port UDP 8472 est le port VXLAN utilisé par défaut par Cilium – L’identifiant de réseau VXLAN (VNI) identifie le réseau superposé auquel appartient ce paquet – Le paquet d’origine complet (avec l’adresse IP du pod A comme source et l’adresse IP du pod B comme destination) est conservé intact à l’intérieur

Le paquet encapsulé entre alors dans la pile réseau normale du nœud 1 et est traité de la même manière que n’importe quel autre paquet :

  1. Traitement du réseau de nœuds : la pile réseau du nœud 1 achemine le paquet en fonction de sa destination (10.80.0.3)

  2. Livraison sur le réseau local :

    • Si les deux nœuds sont sur le même réseau de couche 2, le paquet est envoyé directement au nœud 2

    • S’ils se trouvent sur des sous-réseaux différents, le paquet est d’abord transféré au routeur local

  3. Gestion du routeur : le routeur transmet le paquet en fonction de sa table de routage et le livre au nœud 2

3. Traitement des nœuds de réception

Lorsque le paquet encapsulé arrive au nœud 2 (10.80.0.3) :

  1. La pile réseau du nœud le reçoit et l’identifie comme un paquet VXLAN (port UDP 4789)

  2. Le paquet est transmis à l’interface VXLAN du CNI pour traitement

4. Décapsulation VXLAN

Le CNI sur le nœud 2 traite le paquet VXLAN :

  1. Il supprime les en-têtes extérieurs (Ethernet, IP, UDP et VXLAN)

  2. Il extrait le paquet intérieur d’origine

  3. Le paquet a maintenant retrouvé sa forme d’origine :

+------------------+-----------------+-------------+-----------------+
| Ethernet Header  | IP Header       | TCP/UDP     | Payload         |
| Src: Pod A MAC   | Src: 10.85.1.56 | Src: 43721  |                 |
| Dst: Gateway MAC | Dst: 10.85.2.67 | Dst: 8080   |                 |
+------------------+-----------------+-------------+-----------------+

Le CNI du nœud 2 examine l’adresse IP de destination (10.85.2.67) et :

  1. Identifie que cette adresse IP appartient à un pod local

  2. Achemine le paquet via les interfaces virtuelles appropriées

  3. Fournit le paquet à l’espace de noms réseau du Pod B

Réponse

Lorsque le Pod B répond au Pod A, l’ensemble du processus se déroule en sens inverse :

  1. Le Pod B envoie un paquet au Pod A (10.85.1.56)

  2. Le CNI du nœud 2 l’encapsule avec VXLAN, en définissant la destination sur le nœud 1 (10.80.0.2)

  3. Le paquet encapsulé est livré au nœud 1

  4. Le CNI du nœud 1 le décapsule et fournit la réponse initiale au module A

Des pods sur des nœuds cloud vers des pods sur des nœuds hybrides (trafic est-ouest)

Des pods sur des nœuds cloud vers des pods sur des nœuds hybrides

Demande

1. Le module A initie la communication

Le pod A (10.0.0.56) sur le nœud EC2 souhaite envoyer du trafic vers le pod B (10.85.1.56) sur le nœud hybride. Le paquet initial ressemble à ceci :

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.56  | Src: 52390 (random) |                 |
| Dst: 10.85.1.56 | Dst: 8080           |                 |
+-----------------+---------------------+-----------------+

Avec le CNI VPC, le pod A dispose d’une adresse IP provenant du CIDR VPC et est directement connecté à une ENI sur l’instance EC2. L’espace de noms réseau du pod est connecté au réseau VPC, de sorte que le paquet entre directement dans l’infrastructure de routage VPC.

2. Routage VPC

La table de routage VPC contient une route spécifique pour le CIDR du pod distant (10.85.0.0/16), qui achemine ce trafic vers la passerelle VPC-vers-site-local :

Destination     Target
10.0.0.0/16     local
10.85.0.0/16    vgw-id (VPC-to-onprem gateway)

Sur la base de cette règle de routage, le paquet est dirigé vers la passerelle qui se connecte à votre réseau sur site.

3. Transit transfrontalier

La passerelle transfère le paquet à travers la limite du cloud via votre connexion établie (telle que Direct Connect ou VPN) vers votre réseau sur site. Le paquet conserve ses adresses IP source et destination d’origine tout au long de ce transit.

4. Réception réseau sur site

Le paquet arrive à votre routeur local sur site. Le routeur consulte sa table de routage pour déterminer le prochain saut permettant d’atteindre l’adresse 10.85.1.56. Votre routeur sur site doit disposer de routes pour les CIDR du pod qui dirigent le trafic vers le nœud hybride approprié.

La table du routeur contient une entrée indiquant que le sous-réseau 10.85.1.0/24 est accessible via le nœud hybride avec l’adresse IP 10.80.0.2 :

Destination     Next Hop
10.85.1.0/24    10.80.0.2

5. Traitement du réseau de nœuds

Le routeur transmet le paquet au nœud hybride (10.80.0.2). Lorsque le paquet arrive au nœud, il a toujours l’adresse IP du pod A comme source et celle du pod B comme destination.

6. Traitement CNI

La pile réseau du nœud reçoit le paquet et, constatant que l’adresse IP de destination n’est pas la sienne, le transmet au CNI pour traitement. Le CNI identifie que l’adresse IP de destination appartient à un pod s’exécutant localement sur ce nœud et transfère le paquet vers le pod correct via les interfaces virtuelles appropriées :

Original packet -> node routing -> CNI -> Pod B's network namespace

Le pod B reçoit le paquet et le traite selon les besoins.

Réponse

6. Le pod B envoie une réponse

Le pod B crée un paquet de réponse avec sa propre adresse IP comme source et celle du pod A comme destination :

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.56 | Src: 8080           |                 |
| Dst: 10.0.0.56  | Dst: 52390          |                 |
+-----------------+---------------------+-----------------+

Le CNI identifie que ce paquet est destiné à un réseau externe et le transmet à la pile réseau du nœud.

5. Traitement du réseau de nœuds

Le nœud détermine que l’adresse IP de destination (10.0.0.56) n’appartient pas au réseau local et transfère le paquet vers sa passerelle par défaut (le routeur local).

4. Routage du routeur local

Le routeur local consulte sa table de routage et détermine que l’adresse IP de destination (10.0.0.56) appartient au CIDR VPC (10.0.0.0/16). Il transfère le paquet vers la passerelle connectée à AWS.

3. Transit transfrontalier

Le paquet retourne par la même connexion locale vers VPC, traversant la limite du cloud dans le sens inverse.

2. Routage VPC

Lorsque le paquet arrive dans le VPC, le système de routage identifie que l’adresse IP de destination appartient à un sous-réseau au sein du VPC. Le paquet est acheminé via le réseau VPC vers l’instance EC2 hébergeant le pod A.

1. Le pod A reçoit une réponse

Le paquet arrive à l’instance EC2 et est livré directement au pod A via son ENI attaché. Étant donné que le CNI VPC n’utilise pas de réseau superposé pour les pods dans le VPC, aucune décapsulation supplémentaire n’est nécessaire : le paquet arrive avec ses en-têtes d’origine intacts.

Ce flux de trafic est-ouest démontre pourquoi les CIDR des pods distants doivent être correctement configurés et routables dans les deux sens :

  • Le VPC doit disposer de routes pour les CIDR du pod distant pointant vers la passerelle sur site

  • Votre réseau sur site doit disposer de routes pour les CIDR des pods qui dirigent le trafic vers les nœuds spécifiques hébergeant ces pods.