**Aidez à améliorer cette page**
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.
Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien **Modifier cette page sur** qui se trouve dans le volet droit de chaque page.
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.
# Attribution de davantage d’adresses IP aux nœuds Amazon EKS avec des préfixes
**S’applique à** : nœuds Linux et Windows avec instances Amazon EC2
**S’applique à** : sous-réseaux publics et privés
Chaque instance Amazon EC2 prend en charge un nombre maximum d'interfaces réseau élastiques et un nombre maximum d'adresses IP pouvant être attribuées à chaque interface réseau. Chaque nœud a besoin d'une adresse IP pour chaque interface réseau. Toutes les autres adresses IP disponibles peuvent être attribuées aux `Pods`. Chaque `Pod` a besoin de sa propre adresse IP. Il peut arriver que des nœuds disposent encore de ressources de calcul et de mémoire, mais ne puissent plus accueillir de nouveaux `Pods`, car ils n’ont plus d’adresses IP disponibles à attribuer aux `Pods`.
Vous pouvez augmenter le nombre d’adresses IP que les nœuds peuvent attribuer aux `Pods` en utilisant des préfixes IP, plutôt que des adresses IP secondaires individuelles. Chaque préfixe inclut plusieurs adresses IP. Si vous ne configurez pas votre cluster pour l’attribution de préfixes IP, le cluster doit effectuer un plus grand nombre d’appels d’interface de programmation d’application (API) Amazon EC2 pour configurer les interfaces réseau et les adresses IP nécessaires à la connectivité des pods. À mesure que les clusters augmentent en taille, la fréquence de ces appels d’API peut entraîner des délais plus longs pour le lancement des pods et des instances. Cela entraîne des retards de mise à l'échelle pour répondre à la demande d'applications volumineuses et épineuses, et ajoute des coûts et des frais généraux de gestion, car vous devez allouer des clusters et des VPC supplémentaires pour répondre aux exigences de mise à l'échelle. Pour plus d’informations, consultez les [Seuils de capacité de mise à l’échelle de Kubernetes](https://github.com/kubernetes/community/blob/master/sig-scalability/configs-and-limits/thresholds.md) sur GitHub.
## Compatibilité avec les fonctionnalités du module complémentaire plug-in Amazon VPC CNI pour Kubernetes
Vous pouvez utiliser les préfixes IP avec les fonctionnalités suivantes :
+ Traduction d’adresses réseau source IPv4 ; pour plus d’informations, consultez [Activer l’accès Internet sortant pour les Pods](external-snat.md).
+ Adresses IPv6 pour les clusters, pods et services ; pour plus d’informations, consultez [En savoir plus sur IPv6 les adresses des clusters, des pods et des services](cni-ipv6.md).
+ Restriction du trafic à l’aide des politiques réseau Kubernetes ; pour plus d’informations, consultez [Limitation du trafic des pods à l’aide des politiques réseau Kubernetes](cni-network-policy.md).
La liste suivante présente les paramètres pertinents du module complémentaire plug-in Amazon VPC CNI pour Kubernetes. Pour plus d’informations sur chaque paramètre, consultez [amazon-vpc-cni-k8s](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) sur GitHub.
+ `WARM_IP_TARGET`
+ `MINIMUM_IP_TARGET`
+ `WARM_PREFIX_TARGET`
## Considérations
Considérations liées à l’utilisation de cette fonctionnalité :
+ Chaque type d’instance Amazon EC2 prend en charge un nombre maximal de pods. Si votre groupe de nœuds géré comporte plusieurs types d’instances, le plus petit nombre maximal de pods parmi ces types d’instances est appliqué à tous les nœuds du cluster.
+ Par défaut, le nombre maximum de `Pods` que vous pouvez exécuter sur un nœud est de 110, mais vous pouvez modifier ce nombre. Si vous modifiez le numéro et que vous disposez d'un groupe de nœuds géré existant, la prochaine mise à jour d'AMI ou de modèle de lancement de votre groupe de nœuds entraînera la création de nouveaux nœuds avec la valeur modifiée.
+ Lorsque vous passez de l'attribution d'adresses IP à l'attribution de préfixes IP, nous vous recommandons de créer de nouveaux groupes de nœuds afin d'augmenter le nombre d'adresses IP disponibles, plutôt que de remplacer progressivement les nœuds existants. Exécuter des pods sur un nœud ayant à la fois des adresses IP classiques et des préfixes IP peut entraîner une incohérence dans la capacité IP annoncée, ce qui peut affecter les charges de travail futures sur ce nœud. Pour connaître la méthode recommandée pour effectuer la transition, consultez [Mode de délégation de préfixes pour Linux](https://docs.aws.amazon.com/eks/latest/best-practices/prefix-mode-linux.html) dans le *Guide des bonnes pratiques Amazon EKS*.
+ La portée des groupes de sécurité s’applique au niveau du nœud ; pour plus d’informations, consultez [Groupe de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html).
+ Les préfixes IP attribués à une interface réseau permettent une forte densité de pods par nœud et offrent les meilleurs temps de lancement.
+ Les préfixes IP et les adresses IP sont associés aux interfaces réseau Elastic Amazon EC2 standards. Les pods nécessitant des groupes de sécurité spécifiques se voient attribuer l'adresse IP principale d'une interface réseau de branche. Vous pouvez mélanger, sur un même nœud, des pods recevant des adresses IP individuelles ou des adresses issues de préfixes IP, ainsi que des pods recevant des interfaces réseau dérivées.
+ Pour les clusters dotés de nœuds Linux uniquement.
+ Après avoir configuré le module complémentaire plug-in Amazon VPC CNI pour Kubernetes pour attribuer des préfixes aux interfaces réseau, vous ne pouvez pas rétrograder ce module à une version antérieure à la version `1.9.0` (ou `1.10.1`), sans supprimer tous les nœuds de tous les groupes de nœuds de votre cluster.
+ Si vous utilisez également des groupes de sécurité pour les pods, avec les paramètres `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard` et `AWS_VPC_K8S_CNI_EXTERNALSNAT`=`false`, alors lorsque vos pods communiquent avec des points de terminaison situés hors de votre VPC, ce sont les groupes de sécurité du nœud qui sont appliqués, et non les groupes de sécurité attribués aux pods.
Si vous utilisez également des [groupes de sécurité pour les pods](security-groups-for-pods.md), avec `POD_SECURITY_GROUP_ENFORCING_MODE`=`strict`, lorsque vos `Pods` communiquent avec des points de terminaison hors de votre VPC, ce sont les groupes de sécurité `Pod’s` qui sont utilisés.
# Augmentation du nombre d’adresses IP disponibles pour un nœud Amazon EKS
Vous pouvez augmenter le nombre d’adresses IP que les nœuds peuvent attribuer aux pods en attribuant des préfixes IP, plutôt qu’en attribuant des adresses IP secondaires individuelles aux nœuds.
## Conditions préalables
+ Vous devez disposer d’un cluster existant. Pour en déployer un, consultez [Création d’un cluster Amazon EKS](create-cluster.md).
+ Les sous-réseaux dans lesquels se trouvent vos nœuds Amazon EKS doivent comporter suffisamment de blocs de routage inter-domaines sans classe (CIDR) contigus `/28` (pour les clusters `IPv4`) ou `/80` (pour les clusters `IPv6`). Vous ne pouvez avoir que des nœuds Linux dans un cluster `IPv6`. L'utilisation de préfixes IP peut échouer si les adresses IP sont dispersées dans le CIDR du sous-réseau. Nous vous recommandons la procédure suivante :
+ L’utilisation d’une réservation CIDR de sous-réseau garantit que, même si certaines adresses IP de la plage réservée sont encore utilisées, elles ne seront pas réattribuées après leur libération. Cela permet de s'assurer que les préfixes sont disponibles pour l'allocation sans segmentation.
+ Utilisez de nouveaux sous-réseaux spécifiquement utilisés pour exécuter les charges de travail auxquelles les préfixes IP sont attribués. Les charges de travail Windows et Linux peuvent fonctionner dans le même sous-réseau lors de l’attribution de préfixes IP.
+ Pour attribuer des préfixes IP à vos nœuds, ceux-ci doivent être basés sur AWS Nitro. Les instances qui ne sont pas basées sur Nitro continuent d’allouer des adresses IP secondaires individuelles, mais disposent d’un nombre beaucoup plus faible d’adresses à attribuer aux pods que les instances basées sur Nitro.
+ **Pour les clusters avec des nœuds Linux uniquement** : si votre cluster est configuré pour la famille `IPv4`, la version `1.9.0` ou une version ultérieure du module complémentaire plug-in Amazon VPC CNI pour Kubernetes doit être installée. Vous pouvez vérifier votre version actuelle à l'aide de la commande suivante.
```
kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2
```
Si votre cluster est configuré pour la famille `IPv6`, la version `1.10.1` du module complémentaire doit être installée. Si la version de votre plugin est antérieure aux versions requises, vous devez la mettre à jour. Pour plus d'informations, consultez les sections de mise à jour d'[Assign IPs to Pods with the Amazon VPC CNI.](managing-vpc-cni.md)
+ **Pour les clusters avec des nœuds Windows uniquement**
+ Vous devez avoir activé la prise en charge de Windows pour votre cluster. Pour de plus amples informations, veuillez consulter [Déployer des nœuds Windows sur des clusters EKS](windows-support.md).
## Attribution de préfixes d’adresses IP aux nœuds
Configurez votre cluster pour attribuer des préfixes d'adresses IP aux nœuds. Suivez la procédure correspondant au système d’exploitation de vos nœuds.
### Linux
1. Activez le paramètre pour attribuer des préfixes aux interfaces réseau pour le CNI Amazon DaemonSet VPC. Lors du déploiement d’un cluster, la version `1.10.1` ou ultérieure du module complémentaire plug-in Amazon VPC CNI est déployée avec celui-ci. Si vous avez créé le cluster avec la famille `IPv6`, ce paramètre a été réglé sur `true` par défaut. Si vous avez créé le cluster avec la famille `IPv4`, ce paramètre a été réglé sur `false` par défaut.
```
kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
```
**Important**
Même si votre sous-réseau dispose d’adresses IP disponibles, s’il n’a pas de blocs `/28` contigus disponibles, vous verrez l’erreur suivante dans les journaux du plug-in Amazon VPC CNI pour Kubernetes.
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
Cela peut se produire en raison de la fragmentation des adresses IP secondaires existantes réparties sur un sous-réseau. Pour résoudre cette erreur, créez un nouveau sous-réseau et lancez-y des pods, ou utilisez une réservation CIDR du EC2 sous-réseau Amazon pour réserver de l'espace au sein d'un sous-réseau à utiliser avec l'attribution de préfixes. Pour plus d'informations, consultez la section [Réservations CIDR de sous-réseau](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html) dans le Guide de l'utilisateur Amazon VPC.
1. Si vous prévoyez de déployer un groupe de nœuds gérés sans modèle de lancement ou avec un modèle de lancement sans AMI spécifié, et que vous utilisez une version du module complémentaire plug-in Amazon VPC CNI égale ou supérieure aux versions répertoriées dans les prérequis, passez à l’étape suivante. Les groupes de nœuds gérés calculent automatiquement le nombre maximal de pods.
Si vous déployez un groupe de nœuds autogéré ou un groupe de nœuds gérés avec un modèle de lancement dans lequel vous avez spécifié une AMI, vous devez déterminer le nombre maximal de pods recommandé par Amazon EKS pour vos nœuds. Suivez les instructions de la section , en ajoutant `--cni-prefix-delegation-enabled` à l'étape 3. Notez la sortie pour une utilisation ultérieure.
**Important**
Les groupes de nœuds gérés appliquent un nombre maximal sur la valeur de `maxPods`. Pour les instances avec moins de 30 v, CPUs le nombre maximum est de 110 et pour toutes les autres instances, le nombre maximum est de 250. Ce nombre maximal est appliqué que la délégation du préfixe soit activée ou non.
1. Si vous utilisez un cluster configuré pour `IPv6`, passez à l’étape suivante.
Spécifiez les paramètres dans l'une des options suivantes. Pour déterminer quelle option vous convient le mieux et quelle valeur lui fournir, consultez [WARM\$1PREFIX\$1TARGET, WARM\$1IP\$1TARGET et MINIMUM\$1IP\$1TARGET](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/prefix-and-ip-target.md) on. GitHub
Vous pouvez remplacer la commande example values par une valeur supérieure à zéro.
+ `WARM_PREFIX_TARGET`
```
kubectl set env ds aws-node -n kube-system WARM_PREFIX_TARGET=1
```
+ `WARM_IP_TARGET` ou `MINIMUM_IP_TARGET` : si l'une ou l'autre des valeurs est définie, elle remplace toute valeur définie pour `WARM_PREFIX_TARGET`.
```
kubectl set env ds aws-node -n kube-system WARM_IP_TARGET=5
```
```
kubectl set env ds aws-node -n kube-system MINIMUM_IP_TARGET=2
```
1. Créez l'un des types de groupes de nœuds suivants avec au moins un type d'instance Amazon EC2 Nitro Amazon Linux 2023. Pour obtenir la liste des types d'[instances Nitro, consultez la section Instances créées sur le système Nitro](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances) dans le guide de EC2 l'utilisateur Amazon. Cette fonctionnalité n'est pas prise en charge sur Windows. Pour les options qui incluent *110*, remplacez-le par la valeur de l'étape 3 (recommandée) ou par votre propre valeur.
+ **Autogéré** : déployez le groupe de nœuds en suivant les instructions de la section [Création de nœuds Amazon Linux autogérés](launch-workers.md). Avant de créer la CloudFormation pile, ouvrez le fichier modèle et ajustez `NodeLaunchTemplate` le `UserData` dans le comme suit
```
...
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: ${ClusterName}
apiServerEndpoint: ${ApiServerEndpoint}
certificateAuthority: ${CertificateAuthorityData}
cidr: ${ServiceCidr}
kubelet:
config:
maxPods: 110
...
```
Si vous utilisez `eksctl` pour créer le groupe de nœuds, vous pouvez utiliser la commande suivante.
```
eksctl create nodegroup --cluster my-cluster --managed=false --max-pods-per-node 110
```
+ **Géré** : déployez votre groupe de nœuds à l'aide de l'une des options suivantes :
+ **Sans modèle de lancement ou avec un modèle de lancement sans ID d’AMI spécifié** : suivez la procédure décrite dans [Création d’un groupe de nœuds géré pour votre cluster](create-managed-node-group.md). Les groupes de nœuds gérés calculent automatiquement pour vous la valeur `max-pods` recommandée par Amazon EKS.
+ **Avec un modèle de lancement avec un ID d'AMI spécifié** : dans votre modèle de lancement, spécifiez un ID d'AMI optimisé pour Amazon EKS ou une AMI personnalisée créée à partir de l'AMI optimisée pour Amazon EKS, puis [Déployez le groupe de nœuds avec un modèle de lancement](launch-templates.md) et fournissez les données utilisateur suivantes dans le modèle de lancement. Ces données utilisateur transmettent un `NodeConfig` objet à lire par l'`nodeadm`outil sur le nœud. Pour plus d'informations`nodeadm`, consultez [la documentation de nodeadm.](https://awslabs.github.io/amazon-eks-ami/nodeadm)
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="//"
--//
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
apiServerEndpoint: [.replaceable]`my-cluster`
certificateAuthority: [.replaceable]`LS0t...`
cidr: [.replaceable]`10.100.0.0/16`
name: [.replaceable]`my-cluster
kubelet:
config:
maxPods: [.replaceable]`110`
--//--
```
Si vous utilisez `eksctl` pour créer le groupe de nœuds, vous pouvez utiliser la commande suivante.
```
eksctl create nodegroup --cluster my-cluster --max-pods-per-node 110
```
Si vous avez créé une AMI personnalisée qui n’est pas basée sur l’AMI optimisée Amazon EKS, vous devez alors créer la configuration manuellement.
**Note**
Si vous souhaitez également attribuer des adresses IP aux pods à partir d’un sous-réseau différent de celui de l’instance, vous devez activer cette fonctionnalité à cette étape. Pour de plus amples informations, veuillez consulter [Déploiement de pods dans des sous-réseaux alternatifs avec réseau personnalisé](cni-custom-network.md).
### Windows
1. Activez l'attribution de préfixes IP.
1. Ouvrez le `amazon-vpc-cni` `ConfigMap` pour le modifier.
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. Ajoutez les lignes suivantes à la section `data`.
```
enable-windows-prefix-delegation: "true"
```
1. Enregistrez le fichier et fermez l'éditeur.
1. Confirmez que la ligne a été ajoutée à la `ConfigMap`.
```
kubectl get configmap -n kube-system amazon-vpc-cni -o "jsonpath={.data.enable-windows-prefix-delegation}"
```
Si le résultat renvoyé n’est pas `true`, il se peut qu’il y ait eu une erreur. Essayez à nouveau d'effectuer l'étape.
**Important**
Même si votre sous-réseau dispose d’adresses IP disponibles, s’il n’a pas de blocs `/28` contigus disponibles, vous verrez l’erreur suivante dans les journaux du plug-in Amazon VPC CNI pour Kubernetes.
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
Cela peut se produire en raison de la fragmentation des adresses IP secondaires existantes réparties sur un sous-réseau. Pour résoudre cette erreur, créez un nouveau sous-réseau et lancez-y des pods, ou utilisez une réservation CIDR du EC2 sous-réseau Amazon pour réserver de l'espace au sein d'un sous-réseau à utiliser avec l'attribution de préfixes. Pour plus d'informations, consultez la section [Réservations CIDR de sous-réseau](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html) dans le Guide de l'utilisateur Amazon VPC.
1. (Facultatif) Spécifiez une configuration supplémentaire pour contrôler le comportement de pré-échelonnement et d'échelonnement dynamique de votre cluster. Pour plus d'informations, consultez [la section Options de configuration avec le mode de délégation de préfixes sous Windows activé](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/docs/windows/prefix_delegation_config_options.md) GitHub.
1. Ouvrez le `amazon-vpc-cni` `ConfigMap` pour le modifier.
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. Remplacez les valeurs d'exemple par une valeur supérieure à zéro et ajoutez les entrées dont vous avez besoin dans la `data` section du`ConfigMap`. Si vous définissez une valeur pour `warm-ip-target` ou `minimum-ip-target`, la valeur remplace toute valeur définie pour `warm-prefix-target`.
```
warm-prefix-target: "1"
warm-ip-target: "5"
minimum-ip-target: "2"
```
1. Enregistrez le fichier et fermez l'éditeur.
1. Créez des groupes de nœuds Windows avec au moins un type d'instance Amazon EC2 Nitro. Pour obtenir la liste des types d'[instances Nitro, consultez la section Instances créées sur le système Nitro](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances) dans le guide de EC2 l'utilisateur Amazon. Par défaut, le nombre maximum de pods que vous pouvez déployer sur un nœud est de 110. Si vous souhaitez augmenter ou diminuer ce nombre, indiquez ce qui suit dans les données utilisateur de la configuration d'amorçage. Remplacez *max-pods-quantity* par votre valeur maximale de pods.
```
-KubeletExtraArgs '--max-pods=max-pods-quantity'
```
Si vous déployez des groupes de nœuds gérés, cette configuration doit être ajoutée dans le modèle de lancement. Pour de plus amples informations, veuillez consulter [Personnaliser les nœuds gérés à l’aide de modèles de lancement](launch-templates.md). Pour plus d’informations sur les paramètres du script d’amorçage Windows, consultez [Paramètres de configuration du script d'amorçage](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
## Détermination du nombre maximal de pods et du nombre d’adresses IP disponibles
1. Une fois que vos nœuds sont déployés, affichez les nœuds de votre cluster.
```
kubectl get nodes
```
L'exemple qui suit illustre un résultat.
```
NAME STATUS ROLES AGE VERSION
ip-192-168-22-103.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464
ip-192-168-97-94.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464
```
1. Décrivez l'un des nœuds pour déterminer la valeur de `max-pods` pour le nœud et le nombre d'adresses IP disponibles. Remplacez *192.168.30.193* par l'adresse `IPv4` dans le nom de l'un de vos nœuds renvoyés dans la sortie précédente.
```
kubectl describe node ip-192-168-30-193.region-code.compute.internal | grep 'pods\|PrivateIPv4Address'
```
L'exemple qui suit illustre un résultat.
```
pods: 110
vpc.amazonaws.com/PrivateIPv4Address: 144
```
Dans la sortie précédente, `110` c'est le nombre maximum de pods que Kubernetes déploiera sur le nœud, même si des adresses *144* IP sont disponibles.