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](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) meilleures pratiques grâce aux ateliers Amazon EKS.
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](vpc-cni.md) 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 d'adresses IP 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](https://docs.aws.amazon.com/eks/latest/userguide/cni-increase-ip-addresses.html) 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](prefix-mode-linux.md) et [Délégation de préfixes avec les nœuds Windows](prefix-mode-win.md).
## 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 [IPv6](ipv6.md)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 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é](custom-networking.md).
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](ipv6.md) et pour une expérience pratique, consultez la section [Comprendre IPv6 Amazon EKS](https://catalog.workshops.aws/ipv6-on-aws/en-US/lab-6) de l'[ IPv6 atelier Get hands with](https://catalog.workshops.aws/ipv6-on-aws/en-US).
![\[Cluster EKS en IPv6 mode\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/networking/opt_ipv6.gif)
### 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](https://eksctl.io/) (un outil CLI simple pour créer et gérer des clusters sur EKS), 19 sous-réseaux sont créés par défaut. Un masque réseau de /19 convient à la majorité des types de charge de travail permettant d'allouer plus de 8 000 adresses.
**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](subnets.md)). 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](https://github.com/aws/aws-eks-best-practices/blob/master/latest/bpg/networking/subnet-calc/subnet-calc.xlsx) pour planifier votre réseau. La feuille de calcul calcule l'utilisation des adresses IP en fonction des charges de travail et de la configuration VPC ENI. L'utilisation de l'adresse IP est comparée à celle d'un IPv4 sous-réseau afin de déterminer si la configuration et la taille du sous-réseau sont suffisantes pour votre charge de travail. N'oubliez pas que, si les sous-réseaux de votre VPC n'ont plus d'adresses IP disponibles, nous [vous suggérons de créer un nouveau](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-subnets.html#create-subnets) sous-réseau en utilisant les blocs d'adresse CIDR d'origine du VPC. Notez qu'[Amazon EKS permet désormais de modifier les sous-réseaux et les groupes de sécurité du cluster](https://aws.amazon.com/about-aws/whats-new/2023/10/amazon-eks-modification-cluster-subnets-security/).
#### 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é](custom-networking.md) 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](custom-networking.md).
![\[Mise en réseau personnalisée\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/networking/opt_custom-networking.gif)
#### 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.](vpc-cni.md) 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 :
1. Associez un nouveau bloc CIDR à votre VPC.
1. Créez un nouveau sous-réseau dans le nouveau bloc CIDR et étiquetez-le avec « kubernetes ». io/role/cni» = « 1 ».
1. Activez la configuration ENABLE\$1SUBNET\$1DISCOVERY 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 :
![\[Découverte améliorée des sous-réseaux\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/networking/opt_enhanced-subnet-discovery.gif)
Pour plus d'informations, consultez [Amazon VPC CNI présente la découverte améliorée des sous-réseaux sur](https://aws.amazon.com/blogs/containers/amazon-vpc-cni-introduces-enhanced-subnet-discovery/) le blog consacré aux conteneurs AWS.
#### 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'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 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](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/config/master/aws-k8s-cni.yaml). Vérifiez que la version de la valeur de configuration correspond à la version VPC CNI installée.
**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](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/eni-and-ip-target.md).
#### 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](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/cmd/cni-metrics-helper/README.md). Certaines des mesures disponibles sont les suivantes :
+ 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](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 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 plusieurs](subnets.md#cross-vpcs) comptes VPCs ou [partager un VPC entre plusieurs comptes](subnets.md#subnets-multiple-accounts) afin de limiter l'allocation d' IPv4 adresses.
Pour en savoir plus sur ces modèles, cliquez ici :
+ [Conception de réseaux Amazon VPC à très grande échelle](https://aws.amazon.com/blogs/networking-and-content-delivery/designing-hyperscale-amazon-vpc-networks/),
+ [Développez une connectivité multi-comptes multi-VPC sécurisée avec Amazon VPC Lattice](https://aws.amazon.com/blogs/networking-and-content-delivery/build-secure-multi-account-multi-vpc-connectivity-for-your-applications-with-amazon-vpc-lattice/).