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.
Optimisation de l'utilisation des adresses IP
Les environnements conteneurisés prennent de l'ampleur à un rythme rapide, grâce à la modernisation des applications. Cela signifie que de plus en plus de nœuds de travail et de pods sont déployés.
Le plug-in Amazon VPC CNI attribue à chaque pod une adresse IP issue du ou des CIDR du VPC. Cette approche fournit une visibilité complète des adresses des Pod grâce à des outils tels que les journaux de flux VPC et d'autres solutions de surveillance. En fonction de votre type de charge de travail, cela peut entraîner la consommation d'un nombre important d'adresses IP par les pods.
Lors de la conception de votre architecture réseau AWS, il est important d'optimiser la consommation IP d'Amazon EKS au niveau du VPC et du nœud. Cela vous aidera à atténuer les problèmes d'épuisement des adresses IP et à augmenter la densité des pods par nœud.
Dans cette section, nous aborderons les techniques qui peuvent vous aider à atteindre ces objectifs.
Optimisation de la consommation IP au niveau des nœuds
La délégation de préfixes est une fonctionnalité d'Amazon Virtual Private Cloud (Amazon VPC) qui vous permet d' IPv4 attribuer des préfixes IPv6 à vos instances Amazon Elastic Compute Cloud (Amazon EC2). Il augmente le nombre d'adresses IP par interface réseau (ENI), ce qui augmente la densité de modules par nœud et améliore l'efficacité de votre calcul. La délégation de préfixes est également prise en charge par le Custom Networking.
Pour des informations détaillées, consultez les sections Délégation de préfixes avec les nœuds Linux et Délégation de préfixes avec les nœuds Windows.
Atténuer l'épuisement des IP
Pour éviter que vos clusters n'utilisent toutes les adresses IP disponibles, nous vous recommandons vivement de dimensionner votre réseau VPCs et vos sous-réseaux en tenant compte de la croissance.
L'adoption IPv6est un excellent moyen d'éviter ces problèmes dès le début. Toutefois, pour les entreprises dont les besoins en évolutivité dépassent le planning initial et ne peuvent pas les adopter IPv6, il est recommandé d'améliorer la conception des VPC pour pallier l'épuisement des adresses IP. La technique la plus couramment utilisée par les clients Amazon EKS consiste à ajouter un élément secondaire non routable CIDRs au VPC et à configurer le CNI du VPC pour utiliser cet espace IP supplémentaire lors de l'attribution d'adresses IP aux pods. C'est ce que l'on appelle communément le réseau personnalisé.
Nous aborderons les variables du CNI Amazon VPC que vous pouvez utiliser pour optimiser le pool de chaleur IPs attribué à vos nœuds. Nous clôturerons cette section avec d'autres modèles architecturaux qui ne sont pas intrinsèques à Amazon EKS mais qui peuvent contribuer à atténuer l'épuisement des adresses IP.
Utilisation IPv6 (recommandée)
L'adoption IPv6 est le moyen le plus simple de contourner les RFC1918 limites ; nous vous recommandons vivement d'envisager l'adoption IPv6 comme première option lorsque vous choisissez une architecture réseau. IPv6 fournit un espace d'adresses IP total nettement plus important, et les administrateurs de clusters peuvent se concentrer sur la migration et le dimensionnement des applications sans consacrer d'efforts à contourner IPv4 les limites.
Les clusters Amazon EKS prennent en charge à la fois IPv4 et IPv6. Par défaut, les clusters EKS utilisent l'espace d' IPv4 adressage. La spécification d'un espace d'adressage IPv6 basé au moment de la création du cluster permettra l'utilisation de IPv6. Dans un cluster IPv6 EKS, les pods et les services reçoivent des IPv6 adresses tout en conservant la capacité des IPv4 terminaux existants à se connecter aux services exécutés sur des IPv6 clusters et vice versa. Toutes les pod-to-pod communications au sein d'un cluster ont toujours lieu IPv6. Dans un VPC (/56), la taille de bloc IPv6 CIDR pour les IPv6 sous-réseaux est fixée à /64. Cela fournit 2^64 (environ 18 quintillions) IPv6 adresses permettant d'étendre vos déploiements sur EKS.
Pour des informations détaillées, consultez la section Running IPv6 EKS Clusters et pour une expérience pratique, consultez la section Comprendre IPv6 Amazon EKS
Optimisation de la consommation IP dans les IPv4 clusters
Cette section est dédiée aux clients qui exécutent des applications héritées, mais qui ne and/or sont pas prêts à effectuer la migration IPv6. Bien que nous encouragions toutes les organisations à migrer vers cette solution le plus rapidement IPv6 possible, nous sommes conscients que certaines devront peut-être encore envisager d'autres approches pour augmenter leurs charges de travail liées aux IPv4 conteneurs. C'est pourquoi nous vous expliquerons également les modèles architecturaux permettant d'optimiser IPv4 (RFC1918) la consommation d'espace avec les clusters Amazon EKS.
Plan de croissance
Comme première ligne de défense contre l'épuisement des adresses IP, nous vous recommandons vivement de dimensionner vos sous-réseaux IPv4 VPCs et vos sous-réseaux en tenant compte de la croissance, afin d'éviter que vos clusters n'utilisent toutes les adresses IP disponibles. Vous ne pourrez pas créer de nouveaux pods ou nœuds si les sous-réseaux ne disposent pas d'un nombre suffisant d'adresses IP disponibles.
Avant de créer un VPC et des sous-réseaux, il est conseillé de revenir en arrière à partir de l'échelle de charge de travail requise. Par exemple, lorsque les clusters sont créés à l'aide d'eksctl
Important
Lorsque vous VPCs dimensionnez des sous-réseaux, certains éléments (autres que les pods et les nœuds) peuvent consommer des adresses IP, par exemple les équilibreurs de charge, les bases de données RDS et d'autres services intégrés au VPC.
En outre, Amazon EKS peut créer jusqu'à 4 interfaces réseau élastiques (X-ENI) nécessaires pour permettre la communication avec le plan de contrôle (plus d'informations ici). Lors des mises à niveau de clusters, Amazon EKS crée de nouveaux X ENIs et supprime les anciens lorsque la mise à niveau est réussie. C'est pourquoi nous recommandons un masque réseau d'au moins /28 (16 adresses IP) pour les sous-réseaux associés à un cluster EKS.
Vous pouvez utiliser l'exemple de feuille de calcul EKS Subnet Calculator
Mise en réseau personnalisée
Si vous êtes sur le point d'épuiser l'espace RFC1918 IP, vous pouvez utiliser le modèle de réseau personnalisé pour conserver le routabilité IPs en programmant des pods dans des sous-réseaux supplémentaires dédiés. Bien que le réseau personnalisé accepte une plage VPC valide pour la plage CIDR secondaire, nous vous recommandons d'utiliser CIDRs (/16) à partir de l'espace CG-NAT, c'est-à-dire 198.19.0.0/16 car ces plages sont moins susceptibles 100.64.0.0/10 d'être utilisées dans un environnement d'entreprise que les plages. RFC1918
Pour des informations détaillées, veuillez consulter la section dédiée à la mise en réseau personnalisée.
Découverte améliorée des sous-réseaux
Enhanced Subnet Discovery fournit une alternative de configuration réseau rationalisée pour l'épuisement des adresses IP, en balisant les nouveaux sous-réseaux afin qu'ils soient détectables par le CNI Amazon VPC. Grâce à Enhanced Subnet Discovery, les charges de travail actuelles peuvent continuer à s'exécuter sur les mêmes sous-réseaux et Amazon Elastic Kubernetes Service (Amazon EKS) peut désormais planifier des pods supplémentaires sur les nouveaux « sous-réseaux utilisables ».
Si les sous-réseaux actuels de votre cluster sont à court d'adresses IP, vous pouvez simplement ajouter des sous-réseaux supplémentaires à votre cluster Amazon EKS comme suit :
-
Associez un nouveau bloc CIDR à votre VPC.
-
Créez un nouveau sous-réseau dans le nouveau bloc CIDR et étiquetez-le avec « kubernetes ». io/role/cni» = « 1 ».
-
Activez la configuration ENABLE_SUBNET_DISCOVERY du module complémentaire Amazon VPC CNI sur « true » (valeur par défaut depuis la version 1.18.0).
Une fois la découverte améliorée des sous-réseaux activée sur vos clusters VPC et Amazon EKS, de nouvelles interfaces réseau élastiques ENIs () seront associées à vos nœuds Amazon EKS, comme décrit dans le schéma suivant :
Pour plus d'informations, consultez Amazon VPC CNI présente la découverte améliorée des sous-réseaux sur
Optimisez la piscine IPs chaude
Avec la configuration par défaut, le VPC CNI conserve une ENI complète (et associée IPs) dans le pool de chaleur. Cela peut en consommer un grand nombre IPs, en particulier pour les types d'instances plus importants.
Si le sous-réseau de votre cluster dispose d'un nombre limité d'adresses IP disponibles, examinez ces variables d'environnement de configuration VPC CNI :
-
WARM_IP_TARGET -
MINIMUM_IP_TARGET -
WARM_ENI_TARGET
Vous pouvez configurer la valeur de MINIMUM_IP_TARGET pour qu'elle corresponde étroitement au nombre de pods que vous comptez exécuter sur vos nœuds. Cela garantira qu'au fur et à mesure de la création des pods, le CNI pourra attribuer des adresses IP à partir du warm pool sans appeler l' EC2 API.
N'oubliez pas que définir une valeur WARM_IP_TARGET trop faible entraînera des appels supplémentaires à l' EC2 API, ce qui pourrait entraîner une limitation des demandes. Pour les grands clusters, utilisez along MINIMUM_IP_TARGET pour éviter de limiter le nombre de demandes.
Pour configurer ces options, vous pouvez télécharger le aws-k8s-cni.yaml manifeste et définir les variables d'environnement. Au moment de la rédaction de cet article, la dernière version se trouve ici
Avertissement
Ces paramètres seront réinitialisés aux valeurs par défaut lorsque vous mettrez à jour le CNI. Veuillez effectuer une sauvegarde du CNI avant de le mettre à jour. Passez en revue les paramètres de configuration pour déterminer s'il est nécessaire de les réappliquer une fois la mise à jour réussie.
Vous pouvez ajuster les paramètres CNI à la volée sans interruption pour vos applications existantes, mais vous devez choisir des valeurs adaptées à vos besoins d'évolutivité. Par exemple, si vous travaillez avec des charges de travail par lots, nous vous recommandons de mettre à jour la valeur par défaut WARM_ENI_TARGET pour répondre aux besoins de la balance Pod. Le réglage WARM_ENI_TARGET sur une valeur élevée permet toujours de maintenir le pool d'adresses IP chaudes requis pour exécuter des charges de travail par lots importantes et d'éviter ainsi les retards de traitement des données.
Avertissement
L'amélioration de la conception de votre VPC est la réponse recommandée à l'épuisement des adresses IP. Envisagez des solutions telles que IPv6 et secondaire CIDRs. Le réglage de ces valeurs pour minimiser le nombre de Warm IPs devrait être une solution temporaire une fois les autres options exclues. Une mauvaise configuration de ces valeurs peut interférer avec le fonctionnement du cluster. Avant d'apporter des modifications à un système de production, assurez-vous de prendre connaissance des considérations figurant sur cette page
Surveiller l'inventaire des adresses IP
Outre les solutions décrites ci-dessus, il est également important d'avoir une visibilité sur l'utilisation des adresses IP. Vous pouvez surveiller l'inventaire des adresses IP des sous-réseaux à l'aide de CNI Metrics Helper
-
nombre maximum de personnes que ENIs le cluster peut prendre en charge
-
nombre de personnes ENIs déjà allouées
-
nombre d'adresses IP actuellement attribuées aux Pods
-
nombre total et maximum d'adresses IP disponibles
Vous pouvez également configurer des CloudWatch alarmes pour être averti si un sous-réseau manque d'adresses IP.
Avertissement
Assurez-vous que la DISABLE_METRICS variable pour VPC CNI est définie sur false.
Autres considérations
Il existe d'autres modèles architecturaux non intrinsèques à Amazon EKS qui peuvent contribuer à l'épuisement des adresses IP. Par exemple, vous pouvez optimiser la communication entre plusieurs comptes VPCs ou partager un VPC entre plusieurs comptes afin de limiter l'allocation d' IPv4 adresses.
Pour en savoir plus sur ces modèles, cliquez ici :
