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 de l'IPv4, qui provient de la taille limitée de l'espace d'adressage IPv4. [Il s'agit d'une préoccupation importante soulevée par un certain nombre de nos clients et elle est distincte de la fonctionnalité Dual-Stack de Kubernetes. IPv4/IPv6 ](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) EKS/IPv6 offrira également la flexibilité nécessaire pour interconnecter les limites du réseau à l'aide de CIDR IPv6, minimisant ainsi les risques de chevauchement des CIDR, résolvant ainsi un double problème (,). In-Cluster Cross-Cluster Lors du déploiement de clusters EKS en mode IPv6 (--ip-family ipv6), l'action n'est pas réversible. En termes simples, le support IPv6 d'EKS est activé pendant toute la durée de vie de votre cluster.
[](http://www.youtube.com/watch?v=zdXpTT0bZXo?rel=0)
Dans un cluster EKS IPv6, les Pods and Services recevront des adresses IPv6 tout en maintenant la compatibilité avec les points de terminaison IPv4 existants. Cela inclut la possibilité pour les points de terminaison IPv4 externes d'accéder aux services du cluster, et les Pods d'accéder aux points de terminaison IPv4 externes.
La prise en charge IPv6 d'Amazon EKS tire parti des fonctionnalités IPv6 natives du VPC. Chaque VPC est doté d'un préfixe d'adresse IPv4 (la taille du bloc CIDR peut être comprise entre /16 et /28) et d'un préfixe d'adresse IPv6 /56 unique (fixe) provenant du GUA (adresse globale unicast) 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, suivant les sous-réseaux à double pile. Le schéma suivant décrit le modèle de base du VPC IPv4IPv6 qui prend en charge les clusters basés : EKS/IPv6
Dans le monde IPv6, chaque adresse est routable sur Internet. Par défaut, le VPC alloue du CIDR IPv6 à partir de la plage GUA publique. Cependant, depuis [août 2024](https://aws.amazon.com/about-aws/whats-new/2024/08/aws-private-ipv6-addressing-vpcs-subnets/), vous pouvez également utiliser l'adressage IPv6 privé pour les VPC et les sous-réseaux avec Amazon VPC IP Address Manager (IPAM). Consultez [ce billet de blog AWS Networking](https://aws.amazon.com/blogs/networking-and-content-delivery/understanding-ipv6-addressing-on-aws-and-designing-a-scalable-addressing-plan) et la [documentation VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#vpc-ipv6-addresses) pour plus d'informations.
Le schéma suivant illustre un flux de sortie Internet Pod IPv6 au sein d'un EKS/IPv6 cluster :
Les meilleures pratiques pour implémenter des sous-réseaux IPv6 sont disponibles dans le guide de l'[utilisateur VPC.](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/IPv6-on-AWS.html)
Dans un cluster EKS IPv6, les nœuds et les pods reçoivent des adresses IPv6 publiques. EKS attribue des adresses IPv6 aux services sur la base d'adresses IPv6 unicast (ULA) locales uniques. 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 un plan de contrôle de cluster basé sur un plan de données :
## 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.](prefix-mode-linux.md)
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 démarrage 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 lors de la planification des pods en raison d'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 rendre inutile le réglage avancé des boutons du VPC-CNI plug-in [WARM\_IP/ENI*, MINIMUM\_IP*](https://github.com/aws/amazon-vpc-cni-k8s#warm_ip_target).
Le schéma suivant zoome sur une interface réseau élastique (ENI) à nœud de travail IPv6 :
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 du sous-réseau à double pile est consommée. La prise en charge d'IPv6 par EKS vous permet de communiquer avec les points de terminaison IPv4 (AWS, sur site, Internet) par le biais d'un modèle IPv4 basé uniquement sur les sorties, basé sur des opinions bien ancrées. 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 plugin 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 situé 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, après réception d'une réponse IPv4 « A », l'adresse IPv4 unique du nœud du Pod 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 modèle 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 points de terminaison ainsi qu'une adresse IPv4. Par conséquent, le trafic passe par 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 des coûts associés.
EKS/IPv6 Les pods devront également se connecter aux points de terminaison IPv4 via Internet à l'aide d'adresses IPv4 publiques, pour qu'un flux similaire existe. Le schéma suivant illustre le flux d'un pod IPv6 se connectant à un point de terminaison IPv4 situé 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, après réception d'une réponse IPv4 « A », l'adresse IPv4 unique du nœud du Pod 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 (IPv4 source : 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 (adresse IP publique assignée à la passerelle NAT).
Toute Pod-to-Pod communication entre les nœuds utilise toujours une adresse IPv6. Le VPC CNI configure iptables pour gérer IPv6 tout en bloquant les connexions IPv4.
[Les services Kubernetes recevront uniquement des adresses IPv6 (ClusterIP) provenant d'adresses IPv6 Unicast (ULA) locales uniques.](https://datatracker.ietf.org/doc/html/rfc4193) Le CIDR du service ULA pour un cluster IPv6 est automatiquement attribué lors de la phase de création du cluster EKS et ne peut pas être modifié. Le schéma suivant illustre le flux de service Pod to Kubernetes :
Les services sont accessibles à 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 qui équilibrent 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 montre un utilisateur IPv4 d'Internet accédant à un service basé sur EKS/IPv6 Ingress :
**Note**
Le modèle ci-dessus nécessite de déployer la [version la plus récente](https://kubernetes-sigs.github.io/aws-load-balancer-controller) du contrôleur d'équilibrage de charge AWS
### Communication avec le plan de données EKS Control Plane
EKS fournira les Cross-Account ENI (X-ENIs) en mode double pile (IPv4/IPv6). Les composants des nœuds Kubernetes tels que kubelet et kube-proxy sont configurés pour prendre en charge le dual stack. 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 le protocole IPv6. X-ENIs Les pods communiquent avec les serveurs d'API via le X-ENIs, et la communication entre les pods et les serveurs d'API utilise toujours le mode IPv6.
## Recommandations
### Planification basée sur les ressources informatiques
Un seul préfixe IPv6 est suffisant pour exécuter de nombreux pods sur un seul nœud. Cela supprime également efficacement les limites ENI et IP sur le nombre maximum de pods sur un nœud. Bien qu'IPv6 supprime la dépendance directe à l'égard des Max-pods, lorsque vous utilisez des pièces jointes de préfixes avec des types d'instance plus petits tels que le 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és 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 EKS IPv6.
```
((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 en raison de limitations de ressources.
### Évaluer l'objectif du réseau personnalisé existant
Si la [mise en réseau personnalisée](https://docs.aws.amazon.com/eks/latest/best-practices/custom-networking.html) est actuellement activée, Amazon EKS recommande de réévaluer vos besoins avec IPv6. Si vous avez choisi d'utiliser un réseau personnalisé pour résoudre le problème d'épuisement de l'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](https://github.com/aws/containers-roadmap/issues).
### Pods Fargate en cluster EKS/IPv6
EKS prend en charge le protocole IPv6 pour les pods exécutés sur Fargate. Les pods exécutés sur Fargate consommeront des adresses IPv4 privées routables IPv6 et VPC découpées à partir des plages d'adresses CIDR VPC (). IPv4IPv6 En termes simples, la densité 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](https://kubernetes-sigs.github.io/aws-load-balancer-controller) du module complémentaire AWS Load Balancer Controller. Le LBC ne déploiera un NLB à double pile ou un ALB à double pile qu'après avoir consommé la définition de service/ingress Kubernetes correspondante annotée avec : et `"alb.ingress.kubernetes.io/ip-address-type: dualstack"` `"alb.ingress.kubernetes.io/target-type: ip"`