**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. # Concepts pour les nœuds hybrides Avec les *nœuds hybrides Amazon EKS*, vous pouvez connecter des machines physiques ou virtuelles fonctionnant dans des environnements sur site ou en périphérie à des clusters Amazon EKS fonctionnant dans le cloud AWS. Cette approche présente de nombreux avantages, mais introduit également de nouveaux concepts et architectures de réseau pour ceux qui sont habitués à exploiter des clusters Kubernetes dans un environnement réseau unique. Les sections suivantes approfondissent les concepts Kubernetes et réseau pour les nœuds hybrides EKS et détaillent la manière dont le trafic circule à travers l’architecture hybride. Ces sections nécessitent que vous ayez des connaissances de base sur les réseaux Kubernetes, telles que les concepts de pods, de nœuds, de services, du plan de contrôle Kubernetes, de kubelet et de kube-proxy. Nous vous recommandons de lire ces pages dans l’ordre, en commençant par la [Concepts de mise en réseau pour les nœuds hybrides](hybrid-nodes-concepts-networking.md), puis la [Concepts Kubernetes pour les nœuds hybrides](hybrid-nodes-concepts-kubernetes.md), et enfin la [Flux de trafic réseau pour les nœuds hybrides](hybrid-nodes-concepts-traffic-flows.md). **Topics** + [Concepts de mise en réseau pour les nœuds hybrides](hybrid-nodes-concepts-networking.md) + [Concepts Kubernetes pour les nœuds hybrides](hybrid-nodes-concepts-kubernetes.md) + [Flux de trafic réseau pour les nœuds hybrides](hybrid-nodes-concepts-traffic-flows.md) # Concepts de mise en réseau pour les nœuds hybrides Cette section détaille les concepts fondamentaux du réseau et les contraintes à prendre en compte lors de la conception de la topologie réseau pour les nœuds hybrides EKS. ## Concepts de mise en réseau pour les nœuds hybrides EKS ![\[Schéma du réseau de nœuds hybrides de haut niveau\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-highlevel-network.png) **Le VPC en tant que hub réseau** Tout le trafic qui traverse les limites du cloud passe par votre VPC. Cela inclut le trafic entre le plan de contrôle EKS ou les pods s'exécutant AWS vers les nœuds hybrides ou les pods exécutés sur ceux-ci. Vous pouvez considérer le VPC de votre cluster comme le hub réseau entre vos nœuds hybrides et le reste du cluster. Cette architecture vous donne un contrôle total sur le trafic et son routage, mais vous rend également responsable de la configuration correcte des routes, des groupes de sécurité et des pare-feu pour le VPC. **Plan de contrôle EKS vers le VPC** Le plan de contrôle EKS attache les **interfaces réseau élastiques (ENIs)** à votre VPC. Ils ENIs gèrent le trafic à destination et en provenance du serveur API EKS. Vous contrôlez le placement du plan de contrôle EKS ENIs lorsque vous configurez votre cluster, car EKS s'attache ENIs aux sous-réseaux que vous transmettez lors de la création du cluster. EKS associe les groupes de sécurité aux groupes ENIs qu'EKS attache à vos sous-réseaux. Ces groupes de sécurité autorisent le trafic à destination et en provenance du plan de contrôle EKS via le ENIs. Ceci est important pour les nœuds hybrides EKS, car vous devez autoriser le trafic provenant des nœuds hybrides et des pods qui s'y exécutent vers le plan de contrôle EKS ENIs. **Réseau de nœuds distants** Les réseaux de nœuds distants, en particulier le nœud distant CIDRs, sont les plages de nœuds IPs attribuées aux machines que vous utilisez en tant que nœuds hybrides. Lorsque vous provisionnez des nœuds hybrides, ceux-ci résident dans votre centre de données sur site ou à la périphérie, qui est un domaine réseau différent du plan de contrôle EKS et du VPC. Chaque nœud hybride possède une ou plusieurs adresses IP provenant d’un CIDR de nœud distant distinct des sous-réseaux de votre VPC. Vous configurez le cluster EKS avec ces nœuds distants CIDRs afin qu'EKS sache qu'il doit acheminer tout le trafic destiné aux nœuds hybrides IPs via le VPC de votre cluster, comme les demandes adressées à l'API kubelet. Les connexions à l'`kubelet`API sont utilisées dans les `kubectl port-forward` commandes `kubectl attach` `kubectl cp``kubectl exec`,`kubectl logs`,, et. **Réseaux de pods distants** Les réseaux de pods distants sont les plages IPs attribuées aux pods exécutés sur les nœuds hybrides. En général, vous configurez votre CNI avec ces plages et la fonctionnalité de gestion des adresses IP (IPAM) du CNI se charge d’attribuer une tranche de ces plages à chaque nœud hybride. Lorsque vous créez un pod, le CNI attribue une adresse IP au pod à partir de la tranche allouée au nœud où le pod a été planifié. Vous configurez le cluster EKS avec ces pods distants CIDRs afin que le plan de contrôle EKS sache qu'il doit acheminer tout le trafic destiné aux pods exécutés sur les nœuds hybrides via le VPC de votre cluster, par exemple pour les communications avec les webhooks. ![\[Réseaux de pods distants\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-remote-pod-cidrs.png) **Sur site, sur le VPC** Le réseau local que vous utilisez pour les nœuds hybrides doit être acheminé vers le VPC que vous utilisez pour votre cluster EKS. Plusieurs [options de connectivité Network-to-Amazon VPC](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html) sont disponibles pour connecter votre réseau local à un VPC. Vous pouvez également utiliser votre propre solution VPN. Il est important de configurer correctement le routage côté AWS cloud dans le VPC et dans votre réseau sur site, afin que les deux réseaux acheminent le trafic approprié via la connexion des deux réseaux. Dans le VPC, tout le trafic à destination du nœud distant et des réseaux de pods distants doit transiter par la connexion à votre réseau local (appelée « passerelle »). Si certains de vos sous-réseaux ont des tables de routage différentes, vous devez configurer chaque table de routage avec les routes pour vos nœuds hybrides et les pods qui s’exécutent sur ceux-ci. Cela est vrai pour les sous-réseaux auxquels le plan ENIs de contrôle EKS est attaché, ainsi que pour les sous-réseaux contenant des EC2 nœuds ou des pods devant communiquer avec des nœuds hybrides. Dans votre réseau sur site, vous devez configurer votre réseau pour autoriser le trafic à destination et en provenance du VPC de votre cluster EKS et les AWS autres services requis pour les nœuds hybrides. Le trafic pour le cluster EKS traverse la passerelle dans les deux sens. ## Contraintes du réseau **Réseau entièrement routé** La principale contrainte réside dans le fait que le plan de contrôle EKS et tous les nœuds, qu’ils soient cloud ou hybrides, doivent former un réseau **entièrement routé**. Cela signifie que tous les nœuds doivent pouvoir se joindre mutuellement au niveau de la couche trois, par adresse IP. Le plan de contrôle EKS et les nœuds cloud sont déjà accessibles les uns depuis les autres, car ils se trouvent dans un réseau plat (le VPC). Les nœuds hybrides se trouvent toutefois dans un domaine de réseau différent. C’est pourquoi vous devez configurer un routage supplémentaire dans le VPC et sur votre réseau local afin d’acheminer le trafic entre les nœuds hybrides et le reste du cluster. Si les nœuds hybrides sont accessibles les uns depuis les autres et depuis le VPC, vos nœuds hybrides peuvent se trouver dans un seul réseau plat ou dans plusieurs réseaux segmentés. **Module de télécommande routable CIDRs** Pour que le plan de contrôle EKS puisse communiquer avec les pods s’exécutant sur des nœuds hybrides (par exemple, les webhooks ou le serveur Metrics) ou pour que les pods s’exécutant sur des nœuds cloud puissent communiquer avec les pods s’exécutant sur des nœuds hybrides (communication est-ouest de la charge de travail), votre CIDR de pod distant doit être routable à partir du VPC. Cela signifie que le VPC doit être en mesure d'acheminer le trafic vers le pod CIDRs via la passerelle vers votre réseau local et que votre réseau local doit être en mesure d'acheminer le trafic d'un pod vers le bon nœud. Il est important de noter la distinction entre les exigences de routage des pods dans le VPC et sur site. Le VPC doit uniquement savoir que tout trafic destiné à un pod distant doit passer par la passerelle. Si vous ne possédez qu’un seul CIDR du pod distant, vous n’avez besoin que d’un seul itinéraire. Cette exigence s’applique à tous les sauts de votre réseau local jusqu’au routeur local situé dans le même sous-réseau que vos nœuds hybrides. C’est le seul routeur qui doit connaître la tranche CIDR du pod attribuée à chaque nœud, afin de s’assurer que le trafic destiné à un pod particulier est acheminé vers le nœud où le pod a été planifié. Vous pouvez choisir de propager ces routes pour le pod local CIDRs depuis votre routeur local vers les tables de routage VPC, mais cela n'est pas nécessaire. Si votre espace sur site CIDRs change fréquemment et que vos tables de routage VPC doivent être mises à jour pour refléter le changement d' CIDRsespace, nous vous recommandons de propager l'espace sur site CIDRs vers les tables de routage VPC, mais cela est rare. Notez que la contrainte permettant de rendre votre module local CIDRs routable est facultative. Si vous n'avez pas besoin d'exécuter des webhooks sur vos nœuds hybrides ou de laisser les pods sur les nœuds cloud communiquer avec les pods sur les nœuds hybrides, vous n'avez pas besoin de configurer le routage pour le pod CIDRs sur votre réseau local. *Pourquoi le pod sur site CIDRs doit-il être routable avec des nœuds hybrides ?* Lorsque vous utilisez EKS avec le VPC CNI pour vos nœuds de cloud, le VPC CNI est attribué directement IPs du VPC aux pods. Cela signifie qu'aucun routage spécial n'est nécessaire, car les modules cloud et le plan de contrôle EKS peuvent accéder IPs directement au pod. Lorsqu'ils sont exécutés sur site (et avec d'autres CNIs dans le cloud), les pods s'exécutent généralement sur un réseau superposé isolé et le CNI se charge de distribuer le trafic entre les pods. Cela se fait généralement par le biais de l'encapsulation : le CNI convertit le pod-to-pod trafic en node-to-node trafic, en se chargeant de l'encapsulation et du désencapsulage des deux côtés. De cette manière, aucune configuration supplémentaire n’est nécessaire sur les nœuds et les routeurs. La mise en réseau avec des nœuds hybrides est unique, car elle combine les deux topologies : le plan de contrôle EKS et les nœuds cloud (avec le VPC CNI) s’attendent à un réseau plat comprenant des nœuds et des pods, tandis que les pods s’exécutant sur des nœuds hybrides se trouvent dans un réseau superposé utilisant VXLAN pour l’encapsulation (par défaut dans Cilium). Les pods exécutés sur des nœuds hybrides peuvent atteindre le plan de contrôle EKS et les pods exécutés sur des nœuds cloud, à condition que le réseau local puisse acheminer vers le VPC. Toutefois, sans routage pour le module CIDRs sur le réseau local, tout trafic revenant vers une adresse IP d'espace local sera finalement abandonné si le réseau ne sait pas comment atteindre le réseau superposé et acheminer vers les nœuds appropriés. # Concepts Kubernetes pour les nœuds hybrides Cette page détaille les concepts clés de Kubernetes qui sous-tendent l’architecture système des nœuds hybrides EKS. ## Plan de contrôle EKS dans le VPC Les adresses IP des ENI du plan de contrôle EKS sont stockées dans l’objet `kubernetes` `Endpoints` dans l’espace de noms `default`. Lorsque EKS crée de nouveaux ENI ou supprime les anciens, EKS met à jour cet objet afin que la liste des adresses IP soit toujours à jour. Vous pouvez utiliser ces points de terminaison via le service `kubernetes`, également dans l’espace de noms `default`. Ce service, de type `ClusterIP`, se voit toujours attribuer la première adresse IP du CIDR du service du cluster. Par exemple, pour le service CIDR `172.16.0.0/16`, l’adresse IP du service sera `172.16.0.1`. En général, c’est ainsi que les pods (qu’ils fonctionnent dans le cloud ou sur des nœuds hybrides) accèdent au serveur API EKS Kubernetes. Les pods utilisent l’adresse IP du service comme adresse IP de destination, qui est traduite en adresses IP réelles de l’une des ENI du plan de contrôle EKS. La principale exception est `kube-proxy`, car elle configure la traduction. ## point de terminaison de serveur d’API E L’adresse IP du service `kubernetes` n’est pas le seul moyen d’accéder au serveur API EKS. EKS crée également un nom DNS Route53 lorsque vous créez votre cluster. Il s’agit du champ `endpoint` de votre cluster EKS lorsque vous appelez l’action API `DescribeCluster` EKS. ``` { "cluster": { "endpoint": "https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com", "name": "my-cluster", "status": "ACTIVE" } } ``` Dans un cluster d’accès aux points de terminaison publics ou d’accès aux points de terminaison publics et privés, vos nœuds hybrides résoudront ce nom DNS en une adresse IP publique par défaut, routable via Internet. Dans un cluster d’accès aux points de terminaison privés, le nom DNS est résolu en adresses IP privées des ENI du plan de contrôle EKS. Voici comment le `kubelet` et `kube-proxy` accèdent au serveur API Kubernetes. Si vous souhaitez que tout le trafic de votre cluster Kubernetes passe par le VPC, vous devez soit configurer votre cluster en mode d’accès privé, soit modifier votre serveur DNS sur site afin de résoudre le point de terminaison du cluster EKS vers les adresses IP privées des ENI du plan de contrôle EKS. ## Point de terminaison `kubelet` Le `kubelet` expose plusieurs points de terminaison REST, permettant à d’autres parties du système d’interagir avec chaque nœud et d’y recueillir des informations. Dans la plupart des clusters, la majorité du trafic vers le serveur `kubelet` provient du plan de contrôle, mais certains agents de surveillance peuvent également interagir avec lui. Grâce à cette interface, le `kubelet` gère diverses requêtes : récupération des journaux (`kubectl logs`), exécution de commandes à l’intérieur des conteneurs (`kubectl exec`) et redirection du trafic (`kubectl port-forward`). Chacune de ces requêtes interagit avec l’exécution de conteneur sous-jacent via `kubelet`, ce qui semble transparent pour les administrateurs de cluster et les développeurs. Le serveur d’API Kubernetes est le serveur d’API Kubernetes. Lorsque vous utilisez l’une des commandes `kubectl` mentionnées précédemment, `kubectl` envoie une requête API au serveur API, qui appelle ensuite l’API `kubelet` du nœud sur lequel le pod est exécuté. C’est la principale raison pour laquelle l’adresse IP du nœud doit être accessible depuis le plan de contrôle EKS et pourquoi, même si vos pods sont en cours d’exécution, vous ne pourrez pas accéder à leurs journaux ou à `exec` si la route du nœud est mal configurée. **IP des nœuds** Lorsque le plan de contrôle EKS communique avec un nœud, il utilise l’une des adresses indiquées dans l’état de l’objet `Node` (`status.addresses`). Avec les nœuds cloud EKS, il est courant que le kubelet signale l’adresse IP privée de l’instance EC2 comme une `InternalIP` lors de l’enregistrement du nœud. Cette adresse IP est ensuite validée par le Cloud Controller Manager (CCM) qui s’assure qu’elle appartient bien à l’instance EC2. De plus, le CCM ajoute généralement les adresses IP publiques (comme `ExternalIP`) et les noms DNS (`InternalDNS` et `ExternalDNS`) de l’instance au statut du nœud. Cependant, il n’existe pas de CCM pour les nœuds hybrides. Lorsque vous enregistrez un nœud hybride avec la CLI des nœuds hybrides EKS (`nodeadm`), celle-ci configure le kubelet pour qu’il signale l’adresse IP de votre machine directement dans l’état du nœud, sans passer par le CCM. ``` apiVersion: v1 kind: Node metadata: name: my-node-1 spec: providerID: eks-hybrid:///us-west-2/my-cluster/my-node-1 status: addresses: - address: 10.1.1.236 type: InternalIP - address: my-node-1 type: Hostname ``` Si votre machine dispose de plusieurs adresses IP, le kubelet en sélectionnera une selon sa propre logique. Vous pouvez contrôler l’adresse IP sélectionnée à l’aide du drapeau `--node-ip`, que vous pouvez passer dans la configuration `nodeadm` dans `spec.kubelet.flags`. Seule l’adresse IP indiquée dans l’objet `Node` nécessite une route depuis le VPC. Vos machines peuvent avoir d’autres adresses IP qui ne sont pas accessibles depuis le cloud. ## `kube-proxy` `kube-proxy` est responsable de la mise en œuvre de l’abstraction du service au niveau de la couche réseau de chaque nœud. Il agit comme un proxy réseau et un équilibreur de charge pour le trafic destiné aux services Kubernetes. En surveillant en permanence le serveur API Kubernetes pour détecter les changements liés aux services et aux points de terminaison, `kube-proxy` met à jour de manière dynamique les règles de réseau de l’hôte sous-jacent afin de garantir que le trafic est correctement acheminé. En mode `iptables`, `kube-proxy` programme plusieurs chaînes `netfilter` pour gérer le trafic de service. Les règles forment la hiérarchie suivante : 1. **Chaîne KUBE-SERVICES** : point d’entrée pour tout le trafic de services. Il comporte des règles correspondant à chaque `ClusterIP` et port du service. 1. **Chaînes KUBE-SVC-XXX** : les chaînes spécifiques à un service disposent de règles d’équilibrage de charge pour chaque service. 1. **Chaînes KUBE-SEP-XXX** : les chaînes spécifiques aux points de terminaison contiennent les règles `DNAT` effectives. Examinons ce qui se passe pour un service `test-server` dans l’espace de noms `default` : \$1 Service ClusterIP : `172.16.31.14` \$1 Port du service : `80` \$1 Pods de sauvegarde : `10.2.0.110`, `10.2.1.39`, et `10.2.2.254` Lorsque nous inspectons les règles `iptables` (à l’aide de `iptables-save –0— grep -A10 KUBE-SERVICES`) : 1. Dans la chaîne **KUBE-SERVICES**, nous trouvons une règle correspondant au service : ``` -A KUBE-SERVICES -d 172.16.31.14/32 -p tcp -m comment --comment "default/test-server cluster IP" -m tcp --dport 80 -j KUBE-SVC-XYZABC123456 ``` + Cette règle correspond aux paquets destinés à 172.16.31.14:80 + Le commentaire indique à quoi sert cette règle : `default/test-server cluster IP` + Les paquets correspondants passent à la chaîne `KUBE-SVC-XYZABC123456` 1. La chaîne **KUBE-SVC-XYZABC123456** dispose de règles d’équilibrage de charge basées sur la probabilité : ``` -A KUBE-SVC-XYZABC123456 -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-POD1XYZABC -A KUBE-SVC-XYZABC123456 -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-POD2XYZABC -A KUBE-SVC-XYZABC123456 -j KUBE-SEP-POD3XYZABC ``` + Première règle : 33,3 % de chances de passer à `KUBE-SEP-POD1XYZABC` + Deuxième règle : 50 % de chances que le trafic restant (33,3 % du total) passe à `KUBE-SEP-POD2XYZABC` + Dernière règle : tout le trafic restant (33,3 % du total) passe à `KUBE-SEP-POD3XYZABC` 1. Les chaînes **KUBE-SEP-XXX** individuelles exécutent le DNAT (Destination NAT) : ``` -A KUBE-SEP-POD1XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.0.110:80 -A KUBE-SEP-POD2XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.1.39:80 -A KUBE-SEP-POD3XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.2.254:80 ``` + Ces règles DNAT réécrivent l’adresse IP et le port de destination afin de diriger le trafic vers des pods spécifiques. + Chaque règle gère environ 33,3 % du trafic, assurant ainsi un équilibrage de charge uniforme entre `10.2.0.110`, `10.2.1.39` et `10.2.2.254`. Cette structure en chaîne à plusieurs niveaux permet à `kube-proxy` de mettre en œuvre efficacement l’équilibrage de charge et la redirection des services grâce à la manipulation des paquets au niveau du noyau, sans nécessiter de processus proxy dans le chemin de données. ### Impact sur les opérations Kubernetes Une `kube-proxy` rompu sur un nœud empêche ce dernier d’acheminer correctement le trafic du service, ce qui entraîne des délais d’attente ou des échecs de connexion pour les pods qui dépendent des services du cluster. Cela peut être particulièrement perturbant lors de la première inscription d’un nœud. Le CNI doit communiquer avec le serveur API Kubernetes pour obtenir des informations, telles que le CIDR du pod du nœud, avant de pouvoir configurer le réseau des pods. Pour ce faire, il utilise l’adresse IP du service `kubernetes`. Cependant, si `kube-proxy` n’a pas pu démarrer ou n’a pas réussi à définir les règles `iptables` appropriées, les requêtes envoyées à l’adresse IP du service `kubernetes` ne sont pas traduites en adresses IP réelles des ENI du plan de contrôle EKS. En conséquence, le CNI entrera dans une boucle de crash et aucun des pods ne pourra fonctionner correctement. Nous savons que les pods utilisent l’adresse IP `kubernetes` du service pour communiquer avec le serveur API Kubernetes, mais il faut d’abord que `kube-proxy` définisse des règles `iptables` pour que cela fonctionne. Comment `kube-proxy` communique-t-il avec le serveur API ? Le `kube-proxy` doit être configuré pour utiliser les adresses IP réelles du serveur API Kubernetes ou un nom DNS qui les résout. Dans le cas d’EKS, EKS configure la valeur `kube-proxy` par défaut pour pointer vers le nom DNS Route53 créé par EKS lors de la création du cluster. Vous pouvez voir cette valeur dans le `kube-proxy` ConfigMap dans l’espace de noms `kube-system`. Le contenu de ce ConfigMap est un `kubeconfig` qui est injecté dans le pod `kube-proxy`, recherchez donc le champ `clusters–0—.cluster.server`. Cette valeur correspondra au champ `endpoint` de votre cluster EKS (lorsque vous appelez l’API `DescribeCluster` EKS). ``` apiVersion: v1 data: kubeconfig: |- kind: Config apiVersion: v1 clusters: - cluster: certificate-authority: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt server: https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com name: default contexts: - context: cluster: default namespace: default user: default name: default current-context: default users: - name: default user: tokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token kind: ConfigMap metadata: name: kube-proxy namespace: kube-system ``` ## CIDR de pods distants routables Cette page [Concepts de mise en réseau pour les nœuds hybrides](hybrid-nodes-concepts-networking.md) détaille les conditions requises pour exécuter des webhooks sur des nœuds hybrides ou pour que les pods exécutés sur des nœuds cloud communiquent avec les pods exécutés sur des nœuds hybrides. La condition essentielle est que le routeur sur site doit savoir quel nœud est responsable d’une adresse IP de pod particulière. Il existe plusieurs façons d’y parvenir, notamment le protocole de passerelle frontière (BGP), les routes statiques et le proxy ARP (Address Resolution Protocol). Ces points sont abordés dans les sections suivantes. **Protocole de passerelle frontière (BGP)** Si votre CNI le prend en charge (comme Cilium et Calico), vous pouvez utiliser le mode BGP de votre CNI pour propager les routes vers vos CIDR de pod par nœud depuis vos nœuds vers votre routeur local. Lorsque vous utilisez le mode BGP du CNI, votre CNI agit comme un routeur virtuel, de sorte que votre routeur local considère que le CIDR du pod appartient à un sous-réseau différent et que votre nœud est la passerelle vers ce sous-réseau. ![\[Routage BGP des nœuds hybrides\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-bgp.png) **Routes statiques** Vous pouvez également configurer des routes statiques dans votre routeur local. Il s’agit de la méthode la plus simple pour acheminer le CIDR du pod sur site vers votre VPC, mais c’est aussi la plus sujette aux erreurs et la plus difficile à maintenir. Vous devez vous assurer que les routes sont toujours à jour avec les nœuds existants et leurs CIDR de pod attribués. Si votre nombre de nœuds est faible et que votre infrastructure est statique, cette option est viable et élimine le besoin d’une prise en charge BGP dans votre routeur. Si vous optez pour cette solution, nous vous recommandons de configurer votre CNI avec la tranche CIDR du pod que vous souhaitez attribuer à chaque nœud, plutôt que de laisser son IPAM décider. ![\[Routage statique des nœuds hybrides\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-static-routes.png) **Proxy ARP (Address Resolution Protocol)** Le proxy ARP est une autre approche permettant de rendre routables les adresses IP des pods sur site, particulièrement utile lorsque vos nœuds hybrides se trouvent sur le même réseau de couche 2 que votre routeur local. Lorsque le proxy ARP est activé, un nœud répond aux requêtes ARP pour les adresses IP des pods qu’il héberge, même si ces adresses IP appartiennent à un sous-réseau différent. Lorsqu’un appareil de votre réseau local tente d’atteindre une adresse IP de pod, il envoie d’abord une requête ARP demandant « Qui possède cette adresse IP ? ». Le nœud hybride hébergeant ce pod répondra avec sa propre adresse MAC, indiquant « Je peux gérer le trafic pour cette adresse IP ». Cela crée un chemin direct entre les appareils de votre réseau local et les pods sans nécessiter de configuration du routeur. Pour que cela fonctionne, votre CNI doit prendre en charge la fonctionnalité ARP proxy. Cilium dispose d’un support intégré pour le proxy ARP que vous pouvez activer via la configuration. Le point essentiel à prendre en compte est que le CIDR du pod ne doit pas chevaucher aucun autre réseau de votre environnement, car cela pourrait entraîner des conflits de routage. Cette approche présente plusieurs avantages : \$1 Pas besoin de configurer votre routeur avec BGP ou de maintenir des routes statiques \$1 Fonctionne bien dans les environnements où vous n’avez pas le contrôle sur la configuration de votre routeur ![\[Nœuds hybrides (ARP), proxy\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-arp-proxy.png) ## Encapsulation de pod à pod Dans les environnements sur site, les CNI utilisent généralement des protocoles d’encapsulation pour créer des réseaux superposés qui peuvent fonctionner au-dessus du réseau physique sans qu’il soit nécessaire de le reconfigurer. Cette section explique comment fonctionne cette encapsulation. Veuillez noter que certains détails peuvent varier en fonction du CNI que vous utilisez. L’encapsulation consiste à envelopper les paquets réseau du pod d’origine dans un autre paquet réseau qui peut être acheminé via le réseau physique sous-jacent. Cela permet aux pods de communiquer entre les nœuds exécutant le même CNI sans que le réseau physique ait besoin de savoir comment acheminer ces CIDR de pod. Le protocole d’encapsulation le plus couramment utilisé avec Kubernetes est le Virtual Extensible LAN (VXLAN), mais d’autres protocoles (tels que `Geneve`) sont également disponibles en fonction de votre CNI. ### Encapsulation VXLAN VXLAN encapsule les trames Ethernet de couche 2 dans des paquets UDP. Lorsqu’un pod envoie du trafic à un autre pod sur un nœud différent, le CNI effectue les opérations suivantes : 1. Le CNI intercepte les paquets provenant du Pod A. 1. Le CNI encapsule le paquet d’origine dans un en-tête VXLAN. 1. Ce paquet encapsulé est ensuite envoyé via la pile réseau standard du nœud vers le nœud de destination. 1. Le CNI sur le nœud de destination déballe le paquet et le transmet au Pod B Voici ce qui arrive à la structure du paquet lors de l’encapsulation VXLAN : Paquet original de pod à pod : ``` +-----------------+---------------+-------------+-----------------+ | Ethernet Header | IP Header | TCP/UDP | Payload | | Src: Pod A MAC | Src: Pod A IP | Src Port | | | Dst: Pod B MAC | Dst: Pod B IP | Dst Port | | +-----------------+---------------+-------------+-----------------+ ``` Après l’encapsulation VXLAN : ``` +-----------------+-------------+--------------+------------+---------------------------+ | Outer Ethernet | Outer IP | Outer UDP | VXLAN | Original Pod-to-Pod | | Src: Node A MAC | Src: Node A | Src: Random | VNI: xx | Packet (unchanged | | Dst: Node B MAC | Dst: Node B | Dst: 4789 | | from above) | +-----------------+-------------+--------------+------------+---------------------------+ ``` L’identifiant réseau VXLAN (VNI) permet de distinguer les différents réseaux superposés. ### Scénarios de communication de pod **Pods sur le même nœud hybride** Lorsque des pods sur le même nœud hybride communiquent, aucune encapsulation n’est généralement nécessaire. Le CNI configure des routes locales qui dirigent le trafic entre les pods via les interfaces virtuelles internes du nœud : ``` Pod A -> veth0 -> node's bridge/routing table -> veth1 -> Pod B ``` Le paquet ne quitte jamais le nœud et ne nécessite pas d’encapsulation. **Pods sur différents nœuds hybrides** La communication entre les pods sur différents nœuds hybrides nécessite une encapsulation : ``` Pod A -> CNI -> [VXLAN encapsulation] -> Node A network -> router or gateway -> Node B network -> [VXLAN decapsulation] -> CNI -> Pod B ``` Cela permet au trafic des pods de traverser l’infrastructure réseau physique sans que celle-ci ait besoin de comprendre le routage IP des pods. # 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 avec des diagrammes montrant les chemins end-to-end réseau pour les différents types de trafic. Les flux de trafic suivants sont couverts : + [Nœud hybride `kubelet` vers plan de contrôle EKS](#hybrid-nodes-concepts-traffic-flows-kubelet-to-cp) + [Plan de contrôle EKS vers nœud hybride (serveur `kubelet`)](#hybrid-nodes-concepts-traffic-flows-cp-to-kubelet) + [Pods exécutés sur des nœuds hybrides vers le plan de contrôle EKS](#hybrid-nodes-concepts-traffic-flows-pods-to-cp) + [Plan de contrôle EKS pour les pods exécutés sur un nœud hybride (webhooks)](#hybrid-nodes-concepts-traffic-flows-cp-to-pod) + [Pod-to-Pod exécution sur des nœuds hybrides](#hybrid-nodes-concepts-traffic-flows-pod-to-pod) + [Des pods sur des nœuds cloud vers des pods sur des nœuds hybrides (trafic est-ouest)](#hybrid-nodes-concepts-traffic-flows-east-west) ## Nœud hybride `kubelet` vers plan de contrôle EKS ![\[Nœud hybride kubelet vers plan de contrôle EKS\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-kubelet-to-cp-public.png) ### Demande **1`kubelet`. 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 traverse l'Internet public et les réseaux de transit jusqu'à ce qu' AWS il atteigne le réseau. AWS le réseau 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\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-cp-to-kubelet.png) ### 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 VPC-to-onprem passerelle. **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** `kubelet`Le 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\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-pod-to-cp.png) ### 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. 1. 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. 1. La règle d'équilibrage de charge sélectionne aléatoirement l'une des `KUBE-SEP-XXX` chaînes pour le plan de commande ENI IPs (`10.0.0.132`or`10.0.1.23`). 1. 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 pod distant CIDR (`10.85.0.0/16`), qui dirige ce trafic vers la passerelle. VPC-to-onprem **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 Remote Pod CIDRs doit être correctement routable depuis le VPC jusqu'au nœud spécifique hébergeant chaque pod. Le chemin de retour complet dépend du routage correct du pod sur les réseaux cloud et IPs 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 : CNI et CNI `iptables` sont présentés dans l'exemple sous forme de blocs séparés pour plus de clarté, mais dans la pratique, il est possible que certains CNIs utilisent le NAT `iptables` pour appliquer le NAT. **3. Traitement du réseau de nœuds** Ici, les `iptables` règles définies par `kube-proxy` se comportent de la même manière que dans l'exemple précédent, en équilibrant la charge du paquet sur l'un des plans de contrôle EKS ENIs. 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 nœud distant CIDR (`10.80.0.0/16`), qui dirige ce trafic vers la passerelle. VPC-to-onprem **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 CNI Nat-ing peut simplifier la configuration en permettant le renvoi des paquets vers le nœud sans nécessiter de routage supplémentaire pour le pod. CIDRs ## 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\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-cp-to-pod.png) 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 dirige le paquet vers la VPC-to-onprem passerelle (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 local doit disposer de routes pour le pod CIDRs 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 le module distant CIDRs doit être correctement configuré et routé : + Le VPC doit disposer de routes pour le pod distant CIDRs pointant vers la passerelle sur site + Votre réseau sur site doit disposer de routes pour les pods CIDRs 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écution sur des nœuds hybrides ![\[Pod-to-Pod s’exécutant sur des nœuds hybrides\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-pod-to-pod.png) 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 Cilium CNIs 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 essentielle car le réseau physique sous-jacent ne sait pas comment acheminer CIDRs directement le pod. Il sait uniquement comment acheminer le trafic entre les nœuds IPs. 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`) 1. **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 1. **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`) 1. 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) 1. Il extrait le paquet intérieur d’origine 1. 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 1. Achemine le paquet via les interfaces virtuelles appropriées 1. 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`) 1. Le CNI du nœud 2 l’encapsule avec VXLAN, en définissant la destination sur le nœud 1 (`10.80.0.2`) 1. Le paquet encapsulé est livré au nœud 1 1. 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\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/hybrid-nodes-east-west.png) ### Demande **1. Le module A initie la communication** Le pod A (`10.0.0.56`) sur le EC2 nœud 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 VPC CNI, le Pod A possède une adresse IP provenant du VPC CIDR et est directement attaché à un 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 Remote Pod CIDR (`10.85.0.0/16`), dirigeant ce trafic vers la passerelle : VPC-to-onprem ``` 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 local doit disposer de routes pour le pod CIDRs 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 hébergeant EC2 le Pod A. **1. Le pod A reçoit une réponse** Le paquet arrive à l' EC2 instance 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 montre pourquoi le module distant CIDRs doit être correctement configuré et routable dans les deux sens : + Le VPC doit disposer de routes pour le pod distant CIDRs pointant vers la passerelle sur site + Votre réseau local doit disposer de routes pour les pods CIDRs qui dirigent le trafic vers les nœuds spécifiques hébergeant ces pods.