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
Astuce
Découvrez les
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'attribuer des préfixes IPv4 ou 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 vos VPC et sous-réseaux en tenant compte de la croissance.
L'adoption d'IPv6 est un excellent moyen d'éviter ces problèmes dès le début. Toutefois, pour les entreprises dont les besoins en évolutivité dépassent la planification initiale et ne peuvent pas adopter IPv6, l'amélioration de la conception des VPC est la réponse recommandée à l'épuisement des adresses IP. La technique la plus couramment utilisée par les clients d'Amazon EKS consiste à ajouter des CIDR secondaires non routables 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 d'adresses IP 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.
Utiliser IPv6 (recommandé)
L'adoption d'IPv6 est le moyen le plus simple de contourner les limitations de la RFC1918 ; nous vous recommandons vivement d'envisager d'adopter 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 devoir se concentrer sur le contournement des limites IPv4.
Les clusters Amazon EKS prennent en charge les protocoles IPv4 et IPv6. Par défaut, les clusters EKS utilisent l'espace d'adressage IPv4. La spécification d'un espace d'adressage basé sur IPv6 au moment de la création du cluster permettra d'utiliser IPv6. Dans un cluster EKS IPv6, les pods et les services reçoivent des adresses IPv6 tout en conservant la capacité des points de terminaison IPv4 existants à se connecter aux services exécutés sur des clusters IPv6 et vice versa. Toutes les communications point à point au sein d'un cluster se font toujours via IPv6. Dans un VPC (/56), la taille de bloc d'adresse CIDR IPv6 pour les sous-réseaux IPv6 est fixée à /64. Cela fournit 2^64 (environ 18 quintillions) adresses IPv6 permettant d'étendre vos déploiements sur EKS.
Pour des informations détaillées, consultez la section Exécuter des clusters EKS IPv6 et pour une expérience pratique, consultez la section Comprendre l'IPv6 sur Amazon EKS
Optimisation de la consommation IP dans les clusters IPv4
Cette section est dédiée aux clients qui exécutent des applications existantes et qui ne and/or sont pas prêts à migrer vers IPv6. Tout en encourageant toutes les entreprises à migrer vers IPv6 dès que possible, nous sommes conscients que certaines devront peut-être encore envisager d'autres approches pour adapter leurs charges de travail de conteneurs à l'IPv4. C'est pourquoi nous vous expliquerons également les modèles architecturaux permettant d'optimiser la consommation d'espace d'adressage IPv4 (RFC1918) 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 VPC et sous-réseaux IPv4 en tenant compte de la croissance, afin d'empêcher vos clusters de consommer 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 dimensionnez des VPC et 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 en crée de nouveaux X-ENIs et supprime les anciens une fois la mise à niveau 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 IP de la RFC1918, vous pouvez utiliser le modèle de réseau personnalisé pour conserver les adresses IP routables 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 des CIDR (/16) depuis l' CG-NAT espace, c'est-à-dire 198.19.0.0/16 car ils sont moins susceptibles 100.64.0.0/10 d'être utilisés 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 (ENI) 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 le pool de chaleur de l'IP
Avec la configuration par défaut, le VPC CNI conserve un ENI complet (et les adresses IP associées) dans le pool de chaleur. Cela peut consommer un grand nombre d'adresses IP, en particulier sur 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'API EC2.
N'oubliez pas que définir une valeur WARM_IP_TARGET trop faible entraînera des appels supplémentaires vers l'API EC2, ce qui pourrait entraîner une limitation des demandes. Pour les grands clusters, utilisez along MINIMUM_IP_TARGET pour éviter de limiter les 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 les CIDR secondaires. L'ajustement de ces valeurs pour minimiser le nombre d'adresses IP chaudes 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 d'ENI que le cluster peut prendre en charge
-
nombre d'ENI déjà alloués
-
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 qui ne sont pas intrinsèques à Amazon EKS et qui peuvent contribuer à l'épuisement des adresses IP. Par exemple, vous pouvez optimiser la communication entre les VPC ou partager un VPC entre plusieurs comptes afin de limiter l'allocation d'adresses IPv4.
Pour en savoir plus sur ces modèles, cliquez ici :
