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.
Exécution de clusters EKS IPv6
EKS en mode IPv6 résout le problème d'épuisement IPv4 qui se manifeste souvent dans les clusters EKS à grande échelle. Le support d'EKS pour IPv6 est axé sur la résolution du problème d'épuisement IPv4, qui provient de la taille limitée de l'espace d'adressage IPv4. Il s'agit d'une préoccupation majeure soulevée par un certain nombre de nos clients et qui est distincte de la fonctionnalité Dual-Stack de Kubernetes. IPv4/IPv6
Dans un cluster IPv6 EKS, les Pods and Services recevront des adresses IPv6 tout en préservant la compatibilité avec les anciens points de terminaison IPv4. Cela inclut la possibilité pour les points de terminaison IPv4 externes d'accéder aux services intégrés au cluster et pour les Pods d'accéder à des points de terminaison IPv4 externes.
La prise en charge IPv6 d'Amazon EKS exploite les fonctionnalités IPv6 natives du VPC. Chaque VPC est attribué avec un préfixe d'adresse IPv4 (la taille du bloc CIDR peut être comprise entre /16 et /28) et un préfixe d'adresse IPv6 /56 unique (fixe) depuis le GUA (Global Unicast Address) d'Amazon ; vous pouvez attribuer un préfixe d'adresse /64 à chaque sous-réseau de votre VPC. Les fonctionnalités IPv4, telles que les tables de routage, les listes de contrôle d'accès réseau, le peering et la résolution DNS, fonctionnent de la même manière dans un VPC compatible IPv6. Le VPC est alors appelé VPC à double pile. Après les sous-réseaux à double pile, le schéma suivant illustre le modèle de base du VPC IPv4IPv6 qui prend en charge les clusters basés sur les clusters : EKS/IPv6
Dans le monde IPv6, chaque adresse est routable sur Internet. Par défaut, VPC alloue le CIDR IPv6 à partir de la plage GUA publique. Cependant, depuis août 2024,
Le schéma suivant illustre le flux de sortie Internet d'un pod IPv6 à l'intérieur d'un EKS/IPv6 cluster :
Les meilleures pratiques pour la mise en œuvre de sous-réseaux IPv6 sont disponibles dans le guide de l'utilisateur du VPC.
Dans un cluster IPv6 EKS, les nœuds et les pods reçoivent des adresses IPv6 publiques. EKS attribue des adresses IPv6 aux services sur la base d'adresses Unicast IPv6 locales uniques (ULA). Le CIDR du service ULA pour un cluster IPv6 est automatiquement attribué lors de la phase de création du cluster et ne peut pas être spécifié, contrairement à IPv4. Le schéma suivant illustre un modèle de base de plan de données EKS/IPv6 basé sur le plan de contrôle du cluster :
Présentation de
EKS/IPv6 n'est pris en charge qu'en mode préfixe (mode d'attribution IP VPC-CNI Plug-in ENI). En savoir plus sur le mode préfixe.
L'attribution de préfixes ne fonctionne que sur les instances Nitro-based EC2 et n' EKS/IPv6 est donc prise en charge que lorsque le plan de données du cluster utilise des instances EC2. Nitro-based
En termes simples, un préfixe IPv6 de /80 (par nœud de travail) produira environ 10^14 adresses IPv6, le facteur limitant ne sera plus les adresses IP mais la densité des pods (en termes de ressources).
L'attribution du préfixe IPv6 n'a lieu qu'au moment du bootstrap du nœud de travail EKS. Ce comportement est connu pour atténuer les scénarios dans lesquels les EKS/IPv4 clusters à taux de désabonnement élevé sont souvent retardés dans la planification des pods en raison des appels d'API limités générés par le plug-in VPC CNI (ipamd) visant à allouer des adresses IPv4 privées en temps opportun. Il est également connu pour régler inutilement les boutons avancés du VPC-CNI plug-in WARM_IP/ENI,
Le schéma suivant zoome sur un nœud de travail IPv6 Elastic Network Interface (ENI) :
Chaque nœud de travail EKS se voit attribuer des adresses IPv4 et IPv6, ainsi que les entrées DNS correspondantes. Pour un nœud de travail donné, une seule adresse IPv4 provenant du sous-réseau à double pile est consommée. La prise en charge d'EKS pour IPv6 vous permet de communiquer avec des points de terminaison IPv4 (AWS, sur site, Internet) via un modèle IPv4 de sortie uniquement très élaboré. EKS implémente un plug-in CNI local à l'hôte, secondaire au plug-in VPC CNI, qui alloue et configure une adresse IPv4 pour un pod. Le plug-in CNI configure une adresse IPv4 non routable spécifique à l'hôte pour un Pod à partir du 169.254.172. 0/22 gamme. L'adresse IPv4 attribuée au pod est unique au nœud de travail et n'est pas annoncée au-delà du nœud de travail. 169.254.172. 0/22 fournit jusqu'à 1 024 adresses IPv4 uniques qui peuvent prendre en charge de grands types d'instances.
Le schéma suivant illustre le flux d'un pod IPv6 se connectant à un point de terminaison IPv4 en dehors des limites du cluster (hors Internet) :
Dans le schéma ci-dessus, Pods effectuera une recherche DNS pour le point de terminaison et, à la réception d'une réponse IPv4 « A » IPv4, l'adresse IPv4 unique du nœud uniquement est traduite par traduction d'adresse réseau source (SNAT) en adresse IPv4 privée (VPC) de l'interface réseau principale connectée à l'EC2. Worker-node
Note
Le schéma ci-dessus nécessite la désactivation de DNS64 sur les sous-réseaux sur lesquels les EKS/IPv6 pods sont exécutés. Lorsque DNS64 est activé, le résolveur DNS renvoie une adresse IPv6 synthétisée pour les IPv4-only terminaux ainsi qu'une adresse IPv4. Par conséquent, le trafic est acheminé via la fonctionnalité NAT64 de la passerelle NAT (si elle est incluse dans l'architecture) au lieu de rester dans le VPC, comme indiqué dans le schéma ci-dessus. Cela peut entraîner une utilisation inattendue de la passerelle NAT et entraîner des coûts associés.
EKS/IPv6 Les pods devront également se connecter à des points de terminaison IPv4 via Internet à l'aide d'adresses IPv4 publiques, pour garantir l'existence d'un flux similaire. Le schéma suivant illustre le flux d'un pod IPv6 se connectant à un point de terminaison IPv4 en dehors des limites du cluster (routable par Internet) :
Dans le schéma ci-dessus, Pods effectuera une recherche DNS pour le point de terminaison et, à la réception d'une réponse IPv4 « A » IPv4, l'adresse IPv4 unique du nœud uniquement est traduite par traduction d'adresse réseau source (SNAT) en adresse IPv4 privée (VPC) de l'interface réseau principale connectée à l'EC2. Worker-node L'adresse IPv4 du pod (source IPv4 : adresse IP principale EC2) est ensuite acheminée vers la passerelle NAT IPv4 où l'adresse IP principale EC2 est traduite (SNAT) en une adresse IP publique IPv4 routable sur Internet valide (IP publique attribuée à la passerelle NAT).
Toute Pod-to-Pod communication entre les nœuds utilise toujours une adresse IPv6. VPC CNI configure iptables pour gérer IPv6 tout en bloquant toutes les connexions IPv4.
Les services Kubernetes recevront uniquement des adresses IPv6 (ClusterIP) provenant d'adresses Unicast IPv6 locales uniques (ULA).
Les services sont exposés à Internet à l'aide d'un équilibreur de charge AWS. L'équilibreur de charge reçoit des adresses IPv4 et IPv6 publiques, c'est-à-dire un équilibreur de charge à double pile. Pour les clients IPv4 accédant aux services Kubernetes du cluster IPv6, l'équilibreur de charge effectue la traduction IPv4 vers IPv6.
Amazon EKS recommande d'exécuter des nœuds de travail et des pods dans des sous-réseaux privés. Vous pouvez créer des équilibreurs de charge publics dans les sous-réseaux publics afin d'équilibrer la charge du trafic vers les pods exécutés sur des nœuds situés dans des sous-réseaux privés. Le schéma suivant représente un utilisateur Internet IPv4 accédant à un service basé sur EKS/IPv6 Ingress :
Note
Le schéma ci-dessus nécessite le déploiement de la version la plus récente
Communication entre les plans de données EKS Control Plane
EKS fournira Cross-Account ENiS (X-ENIs) en mode double pile (IPv4/IPv6). Les composants du nœud Kubernetes tels que kubelet et kube-proxy sont configurés pour prendre en charge la double pile. Kubelet et kube-proxy s'exécutent en mode HostNetwork et se lient à la fois aux adresses IPv4 et IPv6 associées à l'interface réseau principale d'un nœud. Le serveur API Kubernetes communique avec les pods et les composants des nœuds via IPv6. X-ENIs Les pods communiquent avec les serveurs API via le X-ENIs, et la communication entre les pods et les serveurs API utilise toujours le mode IPv6.
Recommandations
Calendrier basé sur les ressources de calcul
Un seul préfixe IPv6 est suffisant pour exécuter de nombreux Pods sur un seul nœud. Cela supprime également efficacement les limitations ENI et IP sur le nombre maximum de Pods sur un nœud. Bien qu'IPv6 supprime la dépendance directe vis-à-vis des MAX-Pods, lorsque vous utilisez des pièces jointes avec des préfixes avec des types d'instances plus petits tels que m5.large, vous risquez d'épuiser les ressources du processeur et de la mémoire de l'instance bien avant d'épuiser ses adresses IP. Vous devez définir manuellement la valeur maximale de pod recommandée par EKS si vous utilisez des groupes de nœuds autogérés ou un groupe de nœuds géré avec un ID AMI personnalisé.
Vous pouvez utiliser la formule suivante pour déterminer le nombre maximum de pods que vous pouvez déployer sur un nœud pour un cluster IPv6 EKS.
((Number of network interfaces for instance type (number of prefixes per network interface-1)* 16) + 2
((3 ENIs)_((10 secondary IPs per ENI-1)_ 16)) + 2 = 460 (real)
Les groupes de nœuds gérés calculent automatiquement le nombre maximum de pods pour vous. Évitez de modifier la valeur recommandée par EKS pour le nombre maximum de Pods afin d'éviter les échecs de planification des Pods dus à des limites de ressources.
Évaluer l'objectif de la mise en réseau personnalisée existante
Si la mise en réseau personnalisée est actuellement activée, Amazon EKS recommande de réévaluer vos besoins en utilisant IPv6. Si vous avez choisi d'utiliser un réseau personnalisé pour résoudre le problème d'épuisement du protocole IPv4, cela n'est plus nécessaire avec IPv6. Si vous utilisez un réseau personnalisé pour répondre à une exigence de sécurité, telle qu'un réseau distinct pour les nœuds et les pods, nous vous encourageons à soumettre une demande de feuille de route EKS
Pods Fargate en grappe EKS/IPv6
EKS prend en charge IPv6 pour les Pods s'exécutant sur Fargate. Les pods exécutés sur Fargate consommeront des adresses IPv4 privées routables IPv6 et VPC extraites des plages d'adresses CIDR du VPC (). IPv4IPv6 En termes simples, la densité de l'ensemble de votre cluster EKS/Fargate Pods sera limitée aux adresses IPv4 et IPv6 disponibles. Il est recommandé de dimensionner vos subnets/VPC CIDR à double pile pour une croissance future. Vous ne pourrez pas planifier de nouveaux Fargate Pods si le sous-réseau sous-jacent ne contient pas d'adresse IPv4 disponible, quelles que soient les adresses IPv6 disponibles.
Déployez le contrôleur AWS Load Balancer (LBC)
Le contrôleur de service Kubernetes intégré en amont ne prend pas en charge IPv6. Nous vous recommandons d'utiliser la version la plus récente "alb.ingress.kubernetes.io/ip-address-type: dualstack" "alb.ingress.kubernetes.io/target-type: ip"
