Exécution de clusters IPv6 EKS

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.

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.

Le mode EKS en IPv6 mode résout le problème IPv4 d'épuisement qui se manifeste souvent dans les clusters EKS à grande échelle. L'assistance d'EKS IPv6 est axée sur la résolution du problème d' IPv4 épuisement, qui découle de la taille limitée de l'espace d' IPv4 adressage. Il s'agit d'une préoccupation importante soulevée par un certain nombre de nos clients et elle est distincte de la fonctionnalité IPv4IPv6 Kubernetes/Dual-Stack. EKS/ IPv6 offrira également la flexibilité nécessaire pour interconnecter les limites du réseau en minimisant IPv6 CIDRs ainsi les risques de chevauchement des CIDR, résolvant ainsi un double problème (en cluster, en cluster). Lors du déploiement de clusters EKS en IPv6 mode (--ip-family ipv6), l'action n'est pas réversible. En termes simples, le IPv6 support EKS est activé pendant toute la durée de vie de votre cluster.

Dans un cluster IPv6 EKS, les Pods and Services recevront des IPv6 adresses tout en maintenant la compatibilité avec les IPv4 Endpoints existants. Cela inclut la possibilité pour les IPv4 points de terminaison externes d'accéder aux services du cluster et les pods d'accéder aux points de terminaison externes IPv4 .

Le IPv6 support Amazon EKS tire parti des fonctionnalités IPv6 VPC natives. Chaque VPC est doté d'un préfixe d' IPv4 adresse (la taille du bloc CIDR peut être comprise entre /16 et /28) et d'un préfixe d'adresse /56 unique (fixe) provenant du GUA ( IPv6 adresse globale unicast) d'Amazon ; vous pouvez attribuer un préfixe d'adresse /64 à chaque sous-réseau de votre VPC. IPv4 les fonctionnalités, 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 IPv6 activé. 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 qui prend en charge les clusters basés IPV4 IPv6 sur EKS/ : IPv6

Dans le IPv6 monde, chaque adresse est routable sur Internet. Par défaut, le VPC alloue le IPv6 CIDR à partir de la plage GUA publique. Cependant, depuis août 2024, vous pouvez également utiliser l' IPv6 adressage privé pour VPCs et les sous-réseaux avec Amazon VPC IP Address Manager (IPAM). Consultez ce billet de blog AWS Networking et la documentation VPC pour plus d'informations.

Le schéma suivant illustre un flux de sortie IPv6 Internet Pod au sein d'un cluster IPv6 EKS/ :

Les meilleures pratiques pour implémenter IPv6 des sous-réseaux sont disponibles dans le guide de l'utilisateur du VPC.

Dans un cluster IPv6 EKS, les nœuds et les pods reçoivent des IPv6 adresses publiques. EKS attribue des IPv6 adresses aux services sur la base d'adresses locales uniques de IPv6 monodiffusion (ULA). Le CIDR du service ULA pour un IPv6 cluster 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 basé sur un plan de contrôle de cluster IPv6 basé sur EKS/ :

Présentation

EKS/ n'IPv6 est pris en charge qu'en mode préfixe (mode d'attribution IP ENI du plug-in VPC-CNI). En savoir plus sur le mode préfixe.

L'attribution de préfixes ne fonctionne que sur les EC2 instances basées sur Nitro, c'est pourquoi EKS/ n'IPv6 est pris en charge que lorsque le plan de données du cluster utilise des instances basées sur Nitro. EC2

En termes simples, un IPv6 préfixe de /80 (par nœud de travail) produira environ 10 ^ 14 IPv6 adresses, le facteur limitant IPs ne sera plus celui de la densité du pod (en termes de ressources).

IPv6 l'attribution du préfixe 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 IPv4 clusters EKS/ à taux de désabonnement élevé sont souvent retardés dans 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 privées en temps opportun. IPv4 Il est également connu que les boutons avancés du plug-in VPC-CNI ajustent inutilement WARM_IP/ENI, MINIMUM_IP.

Le schéma suivant zoome sur une interface réseau élastique ( IPv6 ENI) d'un nœud de travail :

Chaque nœud de travail EKS se voit attribuer des IPv6 adresses IPv4 et des entrées DNS correspondantes. Pour un nœud de travail donné, une seule IPv4 adresse du sous-réseau à double pile est consommée. Le support EKS vous IPv6 permet de communiquer avec les IPv4 points de terminaison (AWS, sur site, Internet) par le biais d'un modèle de sortie uniquement basé sur les opinions bien ancrées. IPv4 EKS implémente un plug-in CNI local à l'hôte, secondaire au plug-in VPC CNI, qui alloue et configure une adresse pour un Pod. IPv4 Le plugin CNI configure une IPv4 adresse non routable spécifique à l'hôte pour un Pod de la plage 169.254.172.0/22. L' IPv4 adresse 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 uniques pouvant prendre en charge des types d'instances de grande taille. IPv4

Le schéma suivant illustre le flux d'un IPv6 Pod se connectant à un IPv4 point de terminaison 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' IPv4 adresse unique du nœud du Pod est traduite par traduction d'adresse réseau source (SNAT) en adresse privée ( IPv4 VPC) de l'interface réseau principale attachée au nœud de travail. EC2

Les EKS/ IPv6 Pods devront également se connecter aux IPv4 points de terminaison via Internet à l'aide d' IPv4 adresses publiques, pour qu'un flux similaire existe. Le schéma suivant illustre le flux d'un IPv6 pod se connectant à un IPv4 point de terminaison 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' IPv4 adresse unique du nœud du Pod est traduite par traduction d'adresse réseau source (SNAT) en adresse privée ( IPv4 VPC) de l'interface réseau principale attachée au nœud de travail. EC2 L' IPv4 adresse du pod (source IPv4 : adresse IP EC2 principale) est ensuite acheminée vers la passerelle IPv4 NAT où l'adresse IP EC2 principale est traduite (SNAT) en une adresse IP publique routable valide sur Internet (adresse IP IPv4 publique assignée à la passerelle NAT).

Toute Pod-to-Pod communication entre les nœuds utilise toujours une IPv6 adresse. Le VPC CNI configure iptables pour qu'il le gère IPv6 tout en bloquant les connexions. IPv4

Les services Kubernetes ne recevront que des adresses IPv6 (ClusterIP) provenant d'adresses locales uniques (ULA). IPv6 Le CIDR du service ULA pour un IPv6 cluster 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 le public IPv4 et les IPv6 adresses, c'est-à-dire un équilibreur de charge à double pile. Pour les IPv4 clients accédant aux services Kubernetes du IPv6 cluster, l'équilibreur de charge s'occupe de la traduction. IPv4 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 IPv4 internaute accédant à un service basé sur EKS/ IPv6 Ingress :

Communication avec le plan de données EKS Control Plane

EKS fournira Cross-Account ENIs (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 IPv4 aux IPv6 adresses 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 X- is based. ENIs IPv6 Les pods communiquent avec les serveurs API via le XENIs, et la communication entre les pods et les serveurs API utilise toujours le mode. IPv6

Recommandations

Planification basée sur les ressources informatiques

Un seul IPv6 préfixe suffit 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 que IPv6 la dépendance directe à l'égard des Max-pods soit supprimée, 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 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 en raison de limitations de ressources.

Évaluer l'objectif du réseau personnalisé existant

Si la mise en réseau personnalisée est actuellement activée, Amazon EKS recommande de réévaluer vos besoins en la matière avec IPv6. Si vous avez choisi d'utiliser un réseau personnalisé pour résoudre le problème d' IPv4 épuisement, 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.

Capsules Fargate dans un cluster EKS/ IPv6

EKS prend en IPv6 charge les pods fonctionnant sur Fargate. Les pods exécutés sur Fargate IPv6 consommeront des IPv4 adresses privées routables VPC découpées à partir des plages d'adresses CIDR VPC (). IPv4 IPv6 En termes simples, vous êtes EKS/Fargate Pods cluster wide density will be limited to the available IPv4 and IPv6 addresses. It is recommended to size your dual-stack subnets/VPC CIDRs pour votre croissance future. Vous ne pourrez pas planifier de nouveaux Fargate Pods si le sous-réseau sous-jacent ne contient pas d'adresse disponible, quelles que soient les adresses IPv4 disponibles. IPv6

Déployez le contrôleur AWS Load Balancer (LBC)

Le contrôleur de service Kubernetes intégré en amont n'est pas pris en charge. IPv6 Nous vous recommandons d'utiliser la version la plus récente 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/d'entrée Kubernetes correspondante annotée avec : et "alb.ingress.kubernetes.io/ip-address-type: dualstack" "alb.ingress.kubernetes.io/target-type: ip"

AWS Network Load Balancer ne prend pas en charge les types d'adresses de protocole UDP à double pile. Si vous avez de fortes exigences en matière de diffusion en temps réel à faible latence, de jeux en ligne et d'IoT, nous vous recommandons d'utiliser des IPv4 clusters. Pour en savoir plus sur la gestion des bilans de santé des services UDP, reportez-vous à « Comment acheminer le trafic UDP vers Kubernetes ».