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
L'échelle des environnements conteneurisés augmente rapidement, 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 espace une adresse IP à partir du ou des CIDR du VPC. Cette approche fournit une visibilité complète des adresses des pods grâce à des outils tels que les journaux de flux VPC et d'autres solutions de surveillance. Selon le type de votre 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é de pods par nœud.
Dans cette section, nous aborderons les techniques qui peuvent vous aider à atteindre ces objectifs.
Optimisez 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 les adresses IP par interface réseau (ENI), ce qui augmente la densité de pods par nœud et améliore l'efficacité de votre calcul. La délégation de préfixes est également prise en charge avec la mise en réseau personnalisée.
Pour des informations détaillées, veuillez consulter les sections Délégation de préfixes avec des nœuds Linux et Délégation de préfixes avec des nœuds Windows.
Atténuer l'épuisement des adresses IP
Pour éviter que vos clusters ne consomment toutes les adresses IP disponibles, nous vous recommandons vivement de dimensionner vos VPC et vos 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. Cependant, pour les organisations dont les besoins d'évolutivité dépassent la planification initiale et ne peuvent pas adopter IPv6, l'amélioration de la conception du VPC est la réponse recommandée à l'épuisement des adresses IP. La technique la plus couramment utilisée par les clients 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 la mise en réseau personnalisée.
Nous aborderons les variables du CNI Amazon VPC que vous pouvez utiliser pour optimiser le pool chaud d'adresses IP attribuées à 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 à limiter l'épuisement des adresses IP.
Utiliser IPv6 (recommandé)
L'adoption d'IPv6 est le moyen le plus simple de contourner les limites 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'adressage IP total nettement plus important, et les administrateurs de clusters peuvent se concentrer sur la migration et la mise à l'échelle des applications sans consacrer d'efforts à contourner les limites IPv4.
Les clusters Amazon EKS prennent en charge 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 IPv6 EKS, les espaces et les services reçoivent des adresses IPv6 tout en conservant la capacité des terminaux IPv4 existants à se connecter aux services exécutés sur des clusters IPv6 et vice versa. Toutes les communications pod-to-pod au sein d'un cluster se font toujours via IPv6. Au sein d'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 adresses IPv6 (environ 18 quintillions) permettant de faire évoluer vos déploiements sur EKS.
Pour plus d'informations, consultez la section Exécution de clusters EKS IPv6 et, pour une expérience pratique, consultez la section
Optimisez la consommation IP dans les clusters IPv4
Cette section est dédiée aux clients qui exécutent des applications héritées et qui ne and/or sont pas prêts à migrer vers IPv6. Bien que nous encouragions toutes les organisations à migrer vers IPv6 dès que possible, nous reconnaissons que certaines devront peut-être encore envisager d'autres approches pour adapter leurs charges de travail de conteneurs à l'IPv4. C'est pourquoi nous allons également vous présenter les modèles architecturaux permettant d'optimiser la consommation d'espace des adresses IPv4 (RFC1918) avec les clusters Amazon EKS.
Plan de croissance
En tant que 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'éviter que vos clusters ne consomment 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 à l'échelle de charge de travail requise. Par exemple, lorsque des 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 des équilibreurs de charge, des 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) qui sont nécessaires pour permettre la communication vers le plan de contrôle (plus d'informations ici). Lors des mises à niveau du cluster, 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
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 la mise en réseau personnalisée accepte une plage de VPC valide pour la plage d'adresses CIDR secondaire, nous vous recommandons d'utiliser les CIDR de l'espace d'100.64.0.0/10adressage partagé (RFC 6598) car ils sont moins susceptibles d'être utilisés dans un environnement d'entreprise que les plages RFC1918. Par exemple, vous pouvez l'utiliser 100.64.0.0/16 comme CIDR secondaire pour votre VPC. Consultez la section Restrictions d'association de blocs d'adresses CIDR IPv4 pour les plages d'adresses CIDR secondaires autorisées.
Pour plus d'informations, veuillez consulter la section dédiée à la mise en réseau personnalisée.
Découverte de sous-réseaux améliorée
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. CNI Amazon VPC Grâce à la découverte améliorée des sous-réseaux, 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 modules supplémentaires sur le ou 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 marquez-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 que la découverte améliorée des sous-réseaux est 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
Optimisez le pool chaud 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 chaud. Cela peut consommer un grand nombre d'adresses IP, en particulier sur les types d'instances plus importants.
Si le nombre d'adresses IP disponibles est limité pour votre sous-réseau de cluster, examinez attentivement 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. Ainsi, au fur et à mesure de la création des Pods, le CNI pourra attribuer des adresses IP à partir du pool chaud sans appeler l'API EC2.
N'oubliez pas que le fait de définir une valeur WARM_IP_TARGET trop faible entraînera des appels supplémentaires à l'API EC2, ce qui peut entraîner une limitation des requêtes. Pour les grands clusters, utilisez along with MINIMUM_IP_TARGET pour éviter la limitation des requêtes.
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. Vérifiez 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 qui répondront à 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 qu'elle corresponde aux besoins de l'échelle du pod. Le réglage WARM_ENI_TARGET sur une valeur élevée permet toujours de conserver le pool IP chaud 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 perturber 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à attribués
-
nombre d'adresses IP actuellement attribuées aux Pods
-
nombre total et maximum d'adresses IP disponibles
Vous pouvez également définir CloudWatch des alarmes pour être averti si un sous-réseau est à court 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 à réduire 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 :
