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 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 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'kubeletAPI sont utilisées dans les kubectl port-forward commandes kubectl attach kubectl cpkubectl 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.
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 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.
