

 **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.

# Augmentation du nombre d’adresses IP disponibles pour un nœud Amazon EKS
<a name="cni-increase-ip-addresses-procedure"></a>

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
<a name="_prerequisites"></a>
+ 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 contigus `/28` (pour les `IPv4` clusters) ou `/80` (pour les `IPv6` clusters) de Inter-Domain routage sans classe (CIDR). 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, vos nœuds doivent être AWS Nitro-based. Instances qui ne Nitro-based continuent pas à attribuer des adresses IP secondaires individuelles, mais dont le nombre d'adresses IP à attribuer aux pods est nettement inférieur à celui des Nitro-based instances.
+  **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 de [Attribution d’adresses IP aux pods avec 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
<a name="cni-increase-ip-procedure"></a>

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
<a name="_linux"></a>

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 déployez-y vos pods, ou utilisez une réservation CIDR de sous-réseau Amazon EC2 afin de réserver de l’espace dans un sous-réseau pour l’attribution par préfixe. 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 maximum de pods pour vous.

   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é un ID d'AMI, vous devez définir le nombre maximum de pods pour vos nœuds. Pour plus d'informations sur la manière de déterminer la valeur appropriée, consultez[Comment est déterminé MaxPods](choosing-instance-type.md#max-pods-precedence).
**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 vCPUs, le nombre maximum est 110 et pour toutes les autres instances, le nombre maximum est 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\_PREFIX\_TARGET, WARM\_IP\_TARGET et MINIMUM\_IP\_TARGET](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’instance Nitro, consultez [Instances reposant sur le système Nitro](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances) dans le Guide de l’utilisateur Amazon EC2. 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.
   +  **Self-managed**— Déployez le groupe de nœuds en suivant les instructions de la [section Créer des 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 la `max-pods` valeur recommandée par Amazon EKS pour vous.
     +  **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
<a name="_windows"></a>

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 déployez-y vos pods, ou utilisez une réservation CIDR de sous-réseau Amazon EC2 afin de réserver de l’espace dans un sous-réseau pour l’attribution par préfixe. 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 comprenant au moins un type d’instance Amazon EC2 basé sur Nitro. Pour obtenir la liste des types d’instance Nitro, consultez [Instances reposant sur le système Nitro](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances) dans le Guide de l’utilisateur Amazon EC2. 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
<a name="cni-increase-ip-verify"></a>

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      <none>   19m   v1.XX.X-eks-6b7464
   ip-192-168-97-94.region-code.compute.internal    Ready      <none>   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.