Aidez à améliorer cette page
Pour contribuer à ce guide de l’utilisateur, cliquez sur le lien Modifier cette page sur GitHub qui se trouve dans le volet droit de chaque page.
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
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 dans AWS vers les nœuds hybrides ou les pods s’exécutant 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 associe des interfaces réseau Elastic (ENI) à votre VPC. Ces ENI gèrent le trafic vers et depuis le serveur API EKS. Vous contrôlez l’emplacement des ENI du plan de contrôle EKS lorsque vous configurez votre cluster, car EKS associe les ENI aux sous-réseaux que vous transmettez lors de la création du cluster.
EKS associe des groupes de sécurité aux ENI qu’EKS attache à vos sous-réseaux. Ces groupes de sécurité autorisent le trafic vers et depuis le plan de contrôle EKS via les ENI. 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’exécutent sur ceux-ci vers les ENI du plan de contrôle EKS.
Réseau de nœuds distants
Les réseaux de nœuds distants, en particulier les CIDR de nœuds distants, correspondent aux plages d’adresses IP attribuées aux machines que vous utilisez comme 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 CIDR de nœuds distants afin qu’EKS sache acheminer tout le trafic destiné aux adresses IP des nœuds hybrides via votre VPC de cluster, comme les requêtes adressées à l’API kubelet.
Réseaux de pods distants
Les réseaux de pods distants correspondent aux plages d’adresses IP attribuées aux pods s’exécutant 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 CIDR de pods distants afin que le plan de contrôle EKS sache qu’il doit acheminer tout le trafic destiné aux pods s’exécutant sur les nœuds hybrides via le VPC de votre cluster, comme les communications avec les webhooks.
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é réseau-Amazon VPC sont disponibles pour connecter votre réseau local à un VPC. Vous pouvez également utiliser votre propre solution VPN.
Il est important que vous configuriez correctement le routage côté AWS Cloud dans le VPC et dans votre réseau local, afin que les deux réseaux acheminent le trafic approprié via la connexion entre les 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 vaut pour les sous-réseaux auxquels sont connectés les ENI du plan de contrôle EKS, ainsi que pour les sous-réseaux contenant des nœuds EC2 ou des pods qui doivent communiquer avec des nœuds hybrides.
Dans votre réseau local, vous devez configurer votre réseau pour autoriser le trafic vers et depuis le VPC de votre cluster EKS et les autres services AWS 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.
CIDR de pods distants routables
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 capable d’acheminer le trafic vers les CIDR des pods via la passerelle vers votre réseau local et que votre réseau local doit être capable 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 les CIDR des pods sur site depuis votre routeur local sur site vers les tables de routage VPC, mais cela n’est pas nécessaire. Si les CIDR de vos pods sur site changent fréquemment et que vos tables de routage VPC doivent être mises à jour pour refléter ces changements, nous vous recommandons de propager les CIDR des pods sur site vers les tables de routage VPC, mais cela est rare.
Remarque : la contrainte visant à rendre routables les CIDR de votre pod sur site est facultative. Si vous n’avez pas besoin d’exécuter des webhooks sur vos nœuds hybrides ou si vos pods sur les nœuds cloud ne communiquent pas avec les pods sur les nœuds hybrides, vous n’avez pas besoin de configurer le routage pour les CIDR des pods sur votre réseau sur site.
Pourquoi les CIDR des pods sur site doivent-ils être routables avec les nœuds hybrides ?
Lorsque vous utilisez EKS avec le CNI VPC pour vos nœuds cloud, le CNI VPC attribue directement les adresses IP du VPC aux pods. Cela signifie qu’aucun routage spécial n’est nécessaire, car les pods cloud et le plan de contrôle EKS peuvent accéder directement aux adresses IP des pods.
Lorsqu’ils fonctionnent sur site (et avec d’autres CNI dans le cloud), les pods s’exécutent généralement dans un réseau superposé isolé et le CNI se charge de acheminer le trafic entre les pods. Cela se fait généralement par encapsulation : le CNI convertit le trafic de pod à pod en trafic de nœud à nœud, en se chargeant de l’encapsulation et de la désencapsulation aux deux extrémité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. Cependant, sans routage pour les CIDR des pods sur le réseau local, tout trafic revenant vers une adresse IP de pod locale sera finalement abandonné si le réseau ne sait pas comment atteindre le réseau superposé et acheminer vers les nœuds corrects.
