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

# Personnalisation de l’interface réseau secondaire sur les nœuds Amazon EKS
<a name="cni-custom-network-tutorial"></a>

Avant de commencer le tutoriel, veuillez effectuer les opérations suivantes :
+ Passer en revue les considérations
+ Avoir une bonne compréhension du fonctionnement du plug-in Amazon VPC CNI pour Kubernetes concernant la création d’interfaces réseau secondaires et l’attribution d’adresses IP aux pods. Pour de plus amples informations, veuillez consulter [Allocation ENI](https://github.com/aws/amazon-vpc-cni-k8s#eni-allocation) sur GitHub.
+ Version `2.12.3` ou version ultérieure `1.27.160` ou version ultérieure de l'interface de ligne de AWS commande (AWS CLI) installée et configurée sur votre appareil ou AWS CloudShell. Pour vérifier votre version actuelle, utilisez `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Les gestionnaires de packages tels que `yum``apt-get`, ou Homebrew pour macOS ont souvent plusieurs versions de retard sur la dernière version de la AWS CLI. Pour installer la dernière version, consultez la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) et [configuration rapide avec aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) dans le *Guide de l'utilisateur de l'interface de ligne de AWS commande*. La version de la AWS CLI installée AWS CloudShell peut également avoir plusieurs versions de retard par rapport à la dernière version. Pour le mettre à jour, consultez la section [Installation de la AWS CLI dans votre répertoire](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) de base dans le *guide de AWS CloudShell l'utilisateur*.
+ L'outil de ligne de commande `kubectl` est installé sur votre appareil ou AWS CloudShell. Pour installer ou mettre à niveau `kubectl`, veuillez consulter [Configuration de `kubectl` et `eksctl`](install-kubectl.md).
+ Nous vous recommandons de terminer les étapes de cette rubrique dans un shell Bash. Si vous n’utilisez pas de shell Bash, certaines commandes de script telles que les caractères de continuation de ligne et la façon dont les variables sont définies et utilisées nécessitent un ajustement pour votre shell. En outre, les règles de votre shell en matière de guillemets peuvent être différentes. Pour plus d'informations, consultez la section [Utilisation de guillemets avec des chaînes dans la AWS CLI du](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-quoting-strings.html) Guide de l'utilisateur de l'interface de ligne de AWS commande.

Pour ce tutoriel, nous vous recommandons d’utiliser les exemples de valeurs, sauf dans les cas où il est noté de les remplacer. Vous pouvez remplacer n'importe quel exemple de valeur lorsque vous terminez les étapes d'un cluster de production. Nous vous recommandons de terminer toutes les étapes dans le même terminal. En effet, les variables sont définies et utilisées tout au long des étapes et n’existent pas dans différents terminaux.

Les commandes de cette rubrique sont mises en forme selon les conventions répertoriées dans la section [Exemples d'utilisation de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/welcome-examples.html). Si vous exécutez des commandes depuis la ligne de commande sur des ressources situées dans une AWS région différente de la AWS région par défaut définie dans le [profil AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-profiles) CLI que vous utilisez, vous `--region us-west-2` devez ajouter des commandes en les `us-west-2` remplaçant par votre AWS région.

Lorsque vous souhaitez déployer une mise en réseau personnalisée sur votre cluster de production, passez à [Étape 2 : configuration de votre VPC](#custom-networking-configure-vpc).

## Étape 1 : créer un VPC test et un cluster
<a name="custom-networking-create-cluster"></a>

Les procédures suivantes vous aident à créer un VPC test et un cluster et à configurer une mise en réseau personnalisée pour ce cluster. Nous ne recommandons pas d’utiliser le cluster test pour les charges de travail de production, car plusieurs fonctionnalités non liées que vous pouvez utiliser sur votre cluster de production ne sont pas couvertes dans cette rubrique. Pour de plus amples informations, veuillez consulter [Création d’un cluster Amazon EKS](create-cluster.md).

1. Exécutez la commande suivante afin de définir la variable `account_id`.

   ```
   account_id=$(aws sts get-caller-identity --query Account --output text)
   ```

1. Créez un VPC.

   1. Si vous effectuez un déploiement sur un système de test, créez un VPC à l'aide d'un modèle Amazon EKS AWS CloudFormation .

      ```
      aws cloudformation create-stack --stack-name my-eks-custom-networking-vpc \
        --template-url https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-vpc-private-subnets.yaml \
        --parameters ParameterKey=VpcBlock,ParameterValue=192.168.0.0/24 \
        ParameterKey=PrivateSubnet01Block,ParameterValue=192.168.0.64/27 \
        ParameterKey=PrivateSubnet02Block,ParameterValue=192.168.0.96/27 \
        ParameterKey=PublicSubnet01Block,ParameterValue=192.168.0.0/27 \
        ParameterKey=PublicSubnet02Block,ParameterValue=192.168.0.32/27
      ```

   1. La création de la AWS CloudFormation pile prend quelques minutes. Utilisez la commande suivante pour vérifier l’état du déploiement de la pile.

      ```
      aws cloudformation describe-stacks --stack-name my-eks-custom-networking-vpc --query Stacks\[\].StackStatus  --output text
      ```

      Ne passez pas à l’étape suivante tant que le résultat de la commande n’est pas `CREATE_COMPLETE`.

   1. Définissez les variables avec les valeurs du sous-réseau privé IDs créé par le modèle.

      ```
      subnet_id_1=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \
          --query "StackResources[?LogicalResourceId=='PrivateSubnet01'].PhysicalResourceId" --output text)
      subnet_id_2=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \
          --query "StackResources[?LogicalResourceId=='PrivateSubnet02'].PhysicalResourceId" --output text)
      ```

   1. Définissez des variables avec les zones de disponibilité des sous-réseaux récupérés lors de l'étape précédente.

      ```
      az_1=$(aws ec2 describe-subnets --subnet-ids $subnet_id_1 --query 'Subnets[*].AvailabilityZone' --output text)
      az_2=$(aws ec2 describe-subnets --subnet-ids $subnet_id_2 --query 'Subnets[*].AvailabilityZone' --output text)
      ```

1. Créez un rôle IAM de cluster.

   1. Exécutez la commande suivante pour créer un fichier JSON de politique d'approbation IAM.

      ```
      {
        "Version":"2012-10-17",		 	 	 
        "Statement": [
          {
            "Effect": "Allow",
            "Principal": {
              "Service": "eks.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
      ```

   1. Créez le rôle IAM de cluster Amazon EKS. Si nécessaire, faites précéder `eks-cluster-role-trust-policy.json` par le chemin d'accès sur votre ordinateur sur lequel vous avez enregistré le fichier lors de l'étape précédente. La commande associe la politique d'approbation que vous avez créée lors de l'étape précédente à ce rôle. Pour créer un rôle IAM, le [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) qui crée le rôle doit se voir attribuer l'action (autorisation) IAM `iam:CreateRole`.

      ```
      aws iam create-role --role-name myCustomNetworkingAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
      ```

   1. Associez la politique gérée par Amazon EKS nommée [Amazon EKSCluster Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) au rôle. Pour attacher une politique IAM à un [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), le principal qui attache la politique doit se voir attribuer l'une des actions (autorisations) IAM `iam:AttachUserPolicy` ou `iam:AttachRolePolicy`.

      ```
      aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy --role-name myCustomNetworkingAmazonEKSClusterRole
      ```

1. Créez un cluster Amazon EKS et configurez votre appareil pour qu'il communique avec lui.

   1. Créer un cluster.

      ```
      aws eks create-cluster --name my-custom-networking-cluster \
         --role-arn arn:aws: iam::$account_id:role/myCustomNetworkingAmazonEKSClusterRole \
         --resources-vpc-config subnetIds="$subnet_id_1","$subnet_id_2"
      ```
**Note**  
Il est possible que vous receviez un message d’erreur indiquant que l’une des zones de disponibilité de votre demande ne dispose pas d’une capacité suffisante pour créer un cluster Amazon EKS. Si cela se produit, la sortie de l'erreur contient les zones de disponibilité qui peuvent prendre en charge un nouveau cluster. Essayez à nouveau de créer votre cluster avec au moins deux sous-réseaux situés dans les zones de disponibilité prises en charge pour votre compte. Pour de plus amples informations, veuillez consulter [Capacité insuffisante](troubleshooting.md#ice).

   1. La création du cluster prend quelques minutes. Utilisez la commande suivante pour vérifier l’état du déploiement du cluster.

      ```
      aws eks describe-cluster --name my-custom-networking-cluster --query cluster.status
      ```

      Ne passez pas à l’étape suivante tant que le résultat de la commande n’est pas `"ACTIVE"`.

   1. Configurez `kubectl` pour communiquer avec votre cluster.

      ```
      aws eks update-kubeconfig --name my-custom-networking-cluster
      ```

## Étape 2 : configuration de votre VPC
<a name="custom-networking-configure-vpc"></a>

Dans ce didacticiel, vous devez disposer du VPC créé dans [Étape 1 : créer un VPC test et un cluster](#custom-networking-create-cluster). Pour un cluster de production, ajustez les étapes en conséquence pour votre VPC en remplaçant tous les exemples de valeur par vos propres valeurs.

1. Confirmez que la version installée du plug-in Amazon VPC CNI pour Kubernetes est la plus récente. Pour déterminer la version la plus récente du type de module complémentaire Amazon EKS et mettre à jour votre version en conséquence, consultez [Mettre à jour un module complémentaire Amazon EKS](updating-an-add-on.md). Pour déterminer la version la plus récente du type de module complémentaire autogéré et mettre à jour votre version en conséquence, consultez [Attribuer IPs à des pods avec l'Amazon VPC CNI](managing-vpc-cni.md).

1. Récupérez l'ID du VPC de votre cluster et stockez-le dans une variable pour une utilisation ultérieure.

   ```
   vpc_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query "cluster.resourcesVpcConfig.vpcId" --output text)
   ```

1. Associez un bloc de routage inter-domaines sans classe (CIDR) supplémentaire au VPC de votre cluster. Le bloc CIDR ne peut pas se chevaucher avec des blocs CIDR associés existants.

   1. Affichez les blocs CIDR actuels associés à votre VPC.

      ```
      aws ec2 describe-vpcs --vpc-ids $vpc_id \
          --query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table
      ```

      L'exemple qui suit illustre un résultat.

      ```
      ----------------------------------
      |          DescribeVpcs          |
      +-----------------+--------------+
      |    CIDRBlock    |    State     |
      +-----------------+--------------+
      |  192.168.0.0/24 |  associated  |
      +-----------------+--------------+
      ```

   1. Associez un bloc CIDR supplémentaire à votre VPC. Remplacez la valeur du bloc CIDR dans la commande suivante. Pour plus d'informations, consultez [Associer des blocs IPv4 CIDR supplémentaires à votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/modify-vpcs.html#add-ipv4-cidr) dans le guide de l'utilisateur Amazon VPC.

      ```
      aws ec2 associate-vpc-cidr-block --vpc-id $vpc_id --cidr-block 192.168.1.0/24
      ```

   1. Vérifiez que le nouveau bloc est associé.

      ```
      aws ec2 describe-vpcs --vpc-ids $vpc_id --query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table
      ```

      L'exemple qui suit illustre un résultat.

      ```
      ----------------------------------
      |          DescribeVpcs          |
      +-----------------+--------------+
      |    CIDRBlock    |    State     |
      +-----------------+--------------+
      |  192.168.0.0/24 |  associated  |
      |  192.168.1.0/24 |  associated  |
      +-----------------+--------------+
      ```

   Ne passez pas à l’étape suivante tant que le `State` de votre nouveau bloc CIDR n’est pas `associated`.

1. Créez autant de sous-réseaux que vous souhaitez utiliser dans chaque zone de disponibilité dans laquelle se trouvent vos sous-réseaux existants. Spécifiez un bloc CIDR qui se trouve dans le bloc CIDR que vous avez associé à votre VPC lors d’une étape précédente.

   1. Créez de nouveaux sous-réseaux. Remplacez les valeurs du bloc CIDR dans la commande suivante. Les sous-réseaux doivent être créés dans un bloc CIDR VPC différent de celui de vos sous-réseaux existants, mais dans les mêmes zones de disponibilité que vos sous-réseaux existants. Dans cet exemple, un sous-réseau est créé dans le nouveau bloc CIDR de chaque zone de disponibilité dans laquelle les sous-réseaux privés actuels existent. Les IDs sous-réseaux créés sont stockés dans des variables pour une utilisation ultérieure. Les valeurs `Name` correspondent aux valeurs affectées aux sous-réseaux créés à l'aide du modèle Amazon EKS VPC lors d'une étape précédente. Les noms ne sont pas obligatoires. Vous pouvez utiliser des noms différents.

      ```
      new_subnet_id_1=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_1 --cidr-block 192.168.1.0/27 \
          --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet01},{Key=kubernetes.io/role/internal-elb,Value=1}]' \
          --query Subnet.SubnetId --output text)
      new_subnet_id_2=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_2 --cidr-block 192.168.1.32/27 \
          --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet02},{Key=kubernetes.io/role/internal-elb,Value=1}]' \
          --query Subnet.SubnetId --output text)
      ```
**Important**  
Par défaut, vos nouveaux sous-réseaux sont implicitement associés à la [table de routage principale](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#RouteTables) de votre VPC. Cette table de routage permet la communication entre toutes les ressources déployées dans le VPC. Toutefois, elle n’autorise pas la communication avec des ressources dont les adresses IP se trouvent en dehors des blocs CIDR associés à votre VPC. Vous pouvez associer votre propre table de routage à vos sous-réseaux pour modifier ce comportement. Pour plus d'informations, consultez [Tables de routage de sous-réseau](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#subnet-route-tables) dans le Guide de l'utilisateur Amazon VPC.

   1. Affichez les sous-réseaux actuels dans votre VPC.

      ```
      aws ec2 describe-subnets --filters "Name=vpc-id,Values=$vpc_id" \
          --query 'Subnets[*].{SubnetId: SubnetId,AvailabilityZone: AvailabilityZone,CidrBlock: CidrBlock}' \
          --output table
      ```

      L'exemple qui suit illustre un résultat.

      ```
      ----------------------------------------------------------------------
      |                           DescribeSubnets                          |
      +------------------+--------------------+----------------------------+
      | AvailabilityZone |     CidrBlock      |         SubnetId           |
      +------------------+--------------------+----------------------------+
      |  us-west-2d      |  192.168.0.0/27    |     subnet-example1        |
      |  us-west-2a      |  192.168.0.32/27   |     subnet-example2        |
      |  us-west-2a      |  192.168.0.64/27   |     subnet-example3        |
      |  us-west-2d      |  192.168.0.96/27   |     subnet-example4        |
      |  us-west-2a      |  192.168.1.0/27    |     subnet-example5        |
      |  us-west-2d      |  192.168.1.32/27   |     subnet-example6        |
      +------------------+--------------------+----------------------------+
      ```

      Vous pouvez voir que les sous-réseaux se trouvant dans le bloc CIDR `192.168.1.0` que vous avez créé se trouvent dans les mêmes zones de disponibilité que les sous-réseaux dans le bloc d'adresse CIDR `192.168.0.0`.

## Étape 3 : configuration des ressources Kubernetes
<a name="custom-networking-configure-kubernetes"></a>

1. Définissez la variable d'`AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG`environnement sur `true` dans le `aws-node` DaemonSet.

   ```
   kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
   ```

1. Récupérez l'ID de votre [groupe de sécurité de cluster](sec-group-reqs.md) et stockez-le dans une variable pour une utilisation ultérieure. Amazon EKS crée automatiquement ce groupe de sécurité lorsque vous créez votre cluster.

   ```
   cluster_security_group_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query cluster.resourcesVpcConfig.clusterSecurityGroupId --output text)
   ```

1.  Créez une ressource personnalisée `ENIConfig` pour chaque sous-réseau dans lequel vous souhaitez déployer les pods.

   1. Créez un fichier unique pour chaque configuration d'interface réseau.

      Les commandes suivantes créent des fichiers `ENIConfig` distincts pour les deux sous-réseaux créés à l'étape précédente. La valeur pour `name` doit être unique. Le nom est le même que la zone de disponibilité dans laquelle se trouve le sous-réseau. Le groupe de sécurité de cluster est affecté au `ENIConfig`.

      ```
      cat >$az_1.yaml <<EOF
      apiVersion: crd.k8s.amazonaws.com/v1alpha1
      kind: ENIConfig
      metadata:
        name: $az_1
      spec:
        securityGroups:
          - $cluster_security_group_id
        subnet: $new_subnet_id_1
      EOF
      ```

      ```
      cat >$az_2.yaml <<EOF
      apiVersion: crd.k8s.amazonaws.com/v1alpha1
      kind: ENIConfig
      metadata:
        name: $az_2
      spec:
        securityGroups:
          - $cluster_security_group_id
        subnet: $new_subnet_id_2
      EOF
      ```

      Pour un cluster de production, vous pouvez apporter les modifications suivantes aux commandes précédentes :
      + Remplacez \$1cluster\$1security\$1group\$1id par l’ID d’un [groupe de sécurité](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) existant que vous souhaitez utiliser pour chaque `ENIConfig`.
      + Nous vous recommandons de nommer vos `ENIConfigs` de la même façon que la zone de disponibilité pour laquelle vous allez utiliser la `ENIConfig`, chaque fois que c’est possible. Vous devrez peut-être utiliser pour vos `ENIConfigs` des noms différents de ceux des zones de disponibilité pour diverses raisons. Par exemple, si vous avez plus de deux sous-réseaux dans la même zone de disponibilité et que vous souhaitez les utiliser tous les deux avec une mise en réseau personnalisée, vous avez besoin de plusieurs `ENIConfigs` pour la même zone de disponibilité. Puisque chaque `ENIConfig` nécessite un nom unique, vous ne pouvez nommer plus d’un de vos `ENIConfigs` en utilisant le nom de la zone de disponibilité.

        Si vos `ENIConfig` noms ne sont pas tous identiques à ceux des zones de disponibilité, remplacez \$1az\$11 et \$1az\$12 par vos propres noms dans les commandes précédentes et [annotez vos nœuds](#custom-networking-annotate-eniconfig) avec les derniers noms de ce didacticiel. ENIConfig
**Note**  
Si vous ne spécifiez pas de groupe de sécurité valide pour un cluster de production et que vous utilisez :
      + la version `1.8.0` ou ultérieure du plug-in Amazon VPC CNI pour Kubernetes, alors les groupes de sécurité associés à l’interface réseau Elastic principale du nœud sont utilisés.
      + une version antérieure à `1.8.0` du plug-in Amazon VPC CNI pour Kubernetes, alors le groupe de sécurité par défaut du VPC est attribué aux interfaces réseau secondaires.
**Important**  
 `AWS_VPC_K8S_CNI_EXTERNALSNAT=false` est un paramètre par défaut dans la configuration du plugin CNI Amazon VPC pour Kubernetes. Si vous utilisez les paramètres par défaut, le trafic destiné à des adresses IP situées en dehors des blocs CIDR associés à votre VPC utilisera les groupes de sécurité et les sous-réseaux de l’interface réseau primaire du nœud. Les sous-réseaux et groupes de sécurité définis dans votre `ENIConfigs`, qui servent à créer les interfaces réseau secondaires, ne sont pas utilisés pour ce trafic. Pour en savoir plus sur ce paramètre, consultez [Activer l’accès Internet sortant pour les Pods](external-snat.md).
Si vous utilisez également des groupes de sécurité pour les pods, le groupe de sécurité spécifié dans un `SecurityGroupPolicy` est utilisé à la place du groupe de sécurité défini dans `ENIConfigs`. Pour de plus amples informations, veuillez consulter [Attribution de groupes de sécurité à des pods individuels](security-groups-for-pods.md).

   1. Appliquez chaque fichier de ressource personnalisé que vous avez créé à votre cluster à l'aide des commandes suivantes.

      ```
      kubectl apply -f $az_1.yaml
      kubectl apply -f $az_2.yaml
      ```

1. Confirmez que vos `ENIConfigs` ont été créés.

   ```
   kubectl get ENIConfigs
   ```

   L'exemple qui suit illustre un résultat.

   ```
   NAME         AGE
   us-west-2a   117s
   us-west-2d   105s
   ```

1. Si vous activez le réseau personnalisé sur un cluster de production et que vous avez attribué un nom différent de celui de la zone de disponibilité à vos `ENIConfigs`, passez à l’[étape suivante](#custom-networking-deploy-nodes) pour déployer les nœuds Amazon EC2.

   Permettez à Kubernetes d'appliquer automatiquement le `ENIConfig` pour une zone de disponibilité pour tous les nouveaux nœuds Amazon EC2 créés dans votre cluster.

   1. Pour le cluster test de ce didacticiel, passez à l'[étape suivante](#custom-networking-automatically-apply-eniconfig).

      Pour un cluster de production, vérifiez si une annotation contenant la clé de la variable `k8s.amazonaws.com/eniConfig` d'` [ENI\$1CONFIG\$1ANNOTATION\$1DEF](https://github.com/aws/amazon-vpc-cni-k8s#eni_config_annotation_def) `environnement existe dans la spécification du conteneur pour le `aws-node` DaemonSet.

      ```
      kubectl describe daemonset aws-node -n kube-system | grep ENI_CONFIG_ANNOTATION_DEF
      ```

      Si la sortie est renvoyée, l'annotation existe. Si aucune sortie n'est renvoyée, la variable n'est pas définie. Pour un cluster de production, vous pouvez utiliser ce paramètre ou le paramètre de l'étape suivante. Si vous utilisez ce paramètre, il remplace le paramètre de l'étape suivante. Dans ce didacticiel, le paramètre de l'étape suivante est utilisé.

   1.  Mettez `aws-node` DaemonSet à jour votre `ENIConfig` pour appliquer automatiquement la zone de disponibilité à tous les nouveaux nœuds Amazon EC2 créés dans votre cluster.

      ```
      kubectl set env daemonset aws-node -n kube-system ENI_CONFIG_LABEL_DEF=topology.kubernetes.io/zone
      ```

## Étape 4 : déploiement de nœuds Amazon EC2
<a name="custom-networking-deploy-nodes"></a>

1. Créez un rôle IAM de nœud.

   1. Exécutez la commande suivante pour créer un fichier JSON de politique d'approbation IAM.

      ```
      {
        "Version":"2012-10-17",		 	 	 
        "Statement": [
          {
            "Effect": "Allow",
            "Principal": {
              "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
      ```

   1. Créez un rôle IAM et stockez son Amazon Resource Name (ARN) dans une variable pour une utilisation ultérieure.

      ```
      node_role_arn=$(aws iam create-role --role-name myCustomNetworkingNodeRole --assume-role-policy-document file://"node-role-trust-relationship.json" \
          --query Role.Arn --output text)
      ```

   1. Attachez trois politiques gérées IAM requises au rôle IAM.

      ```
      aws iam attach-role-policy \
        --policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodePolicy \
        --role-name myCustomNetworkingNodeRole
      aws iam attach-role-policy \
        --policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
        --role-name myCustomNetworkingNodeRole
      aws iam attach-role-policy \
          --policy-arn arn:aws: iam::aws:policy/AmazonEKS_CNI_Policy \
          --role-name myCustomNetworkingNodeRole
      ```
**Important**  
Pour simplifier ce tutoriel, la politique [AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html) est attachée au nœud du rôle IAM. Pour un cluster de production, il est recommandé d’attacher cette politique à un rôle IAM distinct, utilisé uniquement par le plug-in Amazon VPC CNI pour Kubernetes. Pour de plus amples informations, veuillez consulter [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md).

1. Créez l'un des types de groupes de nœuds suivants. Pour déterminer le type d'instance que vous souhaitez déployer, consultez [Choix du type d’instance Amazon EC2 optimal pour les nœuds](choosing-instance-type.md). Pour ce didacticiel, terminez l'option **Gérée**, **Sans modèle de lancement ou avec un modèle de lancement sans ID d'AMI spécifié**. Si vous prévoyez d’utiliser le groupe de nœuds pour des charges de travail de production, nous vous recommandons de vous familiariser avec toutes les options relatives aux [groupes de nœuds gérés](create-managed-node-group.md) et aux [groupes de nœuds autogérés](worker.md) avant de déployer le groupe de nœuds.
   +  **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é** : exécutez la commande suivante. Dans le cadre de ce didacticiel, utilisez les exemples de valeurs. Pour un groupe de nœuds de production, remplacez toutes les valeurs d’exemple par vos propres valeurs. Le nom du groupe de nœuds ne peut pas dépasser 63 caractères. Il doit commencer par une lettre ou un chiffre, mais peut également inclure des tirets et des traits de soulignement pour les autres caractères.

       ```
       aws eks create-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup \
           --subnets $subnet_id_1 $subnet_id_2 --instance-types t3.medium --node-role $node_role_arn
       ```
     +  **Avec un modèle de lancement avec un ID AMI spécifié** 

       1. Déterminez le nombre maximum de pods pour vos nœuds en fonction de votre type d'instance. Pour de plus amples informations, veuillez consulter [Comment est déterminé MaxPods](choosing-instance-type.md#max-pods-precedence). Notez la valeur à utiliser à l'étape suivante.

       1. 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 des arguments à la `NodeConfig` spécification. Pour plus d'informations NodeConfig, consultez la [référence de NodeConfig l'API](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfig). Vous pouvez remplacer `20` par la valeur de l'étape précédente (recommandé) ou par votre propre valeur.

          ```
          ---
          MIME-Version: 1.0
          Content-Type: multipart/mixed; boundary="BOUNDARY"
          --BOUNDARY
          Content-Type: application/node.eks.aws
          
          ---
          apiVersion: node.eks.aws/v1alpha1
          kind: NodeConfig
          spec:
            cluster:
              name: my-cluster
              ...
              kubelet:
                config:
                  maxPods: 20
          ```

          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.
   +  **Autogéré** 

     1. Déterminez le nombre maximum de pods pour vos nœuds en fonction de votre type d'instance. Pour de plus amples informations, veuillez consulter [Comment est déterminé MaxPods](choosing-instance-type.md#max-pods-precedence). Notez la valeur à utiliser à l'étape suivante.

     1. Déployez le groupe de nœuds à l'aide des instructions contenues dans [Créer des nœuds Amazon Linux autogérés](launch-workers.md).
**Note**  
Si vous souhaitez que les nœuds d'un cluster de production prennent en charge un nombre nettement plus élevé de pods, vous pouvez activer la délégation de préfixes. Par exemple, `110` est renvoyé pour un type d'instance `m5.large`. Pour obtenir des instructions sur la façon d'activer cette capacité, consultez [Attribution de davantage d’adresses IP aux nœuds Amazon EKS avec des préfixes](cni-increase-ip-addresses.md). Vous pouvez utiliser cette capacité avec une mise en réseau personnalisée.

1. La création d'un groupe de nœuds dure plusieurs minutes. Vous pouvez vérifier l'état de la création d'un groupe de nœuds géré à l'aide de la commande suivante.

   ```
   aws eks describe-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup --query nodegroup.status --output text
   ```

   Ne passez pas à l’étape suivante tant que le résultat renvoyé n’est pas `ACTIVE`.

1.  Pour le didacticiel, vous pouvez ignorer cette étape.

   Pour un cluster de production, si vous n’avez pas donné à vos `ENIConfigs` le même nom que la zone de disponibilité dans laquelle elles sont utilisées, vous devez annoter les nœuds avec le nom de l’`ENIConfig` devant leur être associé. Cette étape n’est pas nécessaire si vous avez un seul sous-réseau par zone de disponibilité et que vous avez nommé vos `ENIConfigs` avec les mêmes noms que vos zones de disponibilité. En effet, dans ce cas, le plug-in Amazon VPC CNI pour Kubernetes associe automatiquement la bonne `ENIConfig` au nœud, comme configuré lors d’une [étape précédente](#custom-networking-automatically-apply-eniconfig).

   1. Obtenez la liste des nœuds de votre cluster.

      ```
      kubectl get nodes
      ```

      L'exemple qui suit illustre un résultat.

      ```
      NAME                                          STATUS   ROLES    AGE     VERSION
      ip-192-168-0-126.us-west-2.compute.internal   Ready    <none>   8m49s   v1.22.9-eks-810597c
      ip-192-168-0-92.us-west-2.compute.internal    Ready    <none>   8m34s   v1.22.9-eks-810597c
      ```

   1. Déterminez dans quelle zone de disponibilité se trouve chaque nœud. Exécutez la commande suivante pour chaque nœud renvoyé précédemment, en remplaçant les adresses IP selon le résultat précédent.

      ```
      aws ec2 describe-instances --filters Name=network-interface.private-dns-name,Values=ip-192-168-0-126.us-west-2.compute.internal \
      --query 'Reservations[].Instances[].{AvailabilityZone: Placement.AvailabilityZone, SubnetId: SubnetId}'
      ```

      L'exemple qui suit illustre un résultat.

      ```
      [
          {
              "AvailabilityZone": "us-west-2d",
              "SubnetId": "subnet-Example5"
          }
      ]
      ```

   1. Annotez chaque nœud avec le `ENIConfig` que vous avez créé pour l'ID de sous-réseau et la zone de disponibilité. Vous ne pouvez annoter un nœud qu'avec un seul `ENIConfig`, bien que plusieurs nœuds puissent être annotés avec le même `ENIConfig`. Remplacez les exemples de valeurs par les vôtres.

      ```
      kubectl annotate node ip-192-168-0-126.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName1
      kubectl annotate node ip-192-168-0-92.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName2
      ```

1.  Si vous aviez déjà des nœuds exécutant des pods dans un cluster de production avant la bascule vers la fonctionnalité de réseau personnalisé, effectuez les actions suivantes :

   1. Assurez-vous que vous disposez de nœuds disponibles utilisant la fonctionnalité de mise en réseau personnalisée.

   1. Cordonnez et videz les nœuds pour arrêter les pods de manière contrôlée. Pour plus d'informations, consultez [Drainer un nœud en toute sécurité](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) dans la documentation Kubernetes.

   1. Mettez fin aux nœuds. Si les nœuds se trouvent dans un groupe de nœuds géré existant, vous pouvez supprimer le groupe de nœuds. Exécutez la commande suivante.

      ```
      aws eks delete-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup
      ```

   Seuls les nouveaux nœuds enregistrés auprès du label `k8s.amazonaws.com/eniConfig` utilisent la fonctionnalité de réseaux personnalisés.

1. Confirmez que les pods reçoivent bien une adresse IP appartenant à l’un des blocs CIDR associés aux sous-réseaux créés précédemment.

   ```
   kubectl get pods -A -o wide
   ```

   L'exemple qui suit illustre un résultat.

   ```
   NAMESPACE     NAME                       READY   STATUS    RESTARTS   AGE     IP              NODE                                          NOMINATED NODE   READINESS GATES
   kube-system   aws-node-2rkn4             1/1     Running   0          7m19s   192.168.0.92    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
   kube-system   aws-node-k96wp             1/1     Running   0          7m15s   192.168.0.126   ip-192-168-0-126.us-west-2.compute.internal   <none>           <none>
   kube-system   coredns-657694c6f4-smcgr   1/1     Running   0          56m     192.168.1.23    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
   kube-system   coredns-657694c6f4-stwv9   1/1     Running   0          56m     192.168.1.28    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
   kube-system   kube-proxy-jgshq           1/1     Running   0          7m19s   192.168.0.92    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
   kube-system   kube-proxy-wx9vk           1/1     Running   0          7m15s   192.168.0.126   ip-192-168-0-126.us-west-2.compute.internal   <none>           <none>
   ```

   Vous pouvez constater que les pods coredns reçoivent des adresses IP issues du bloc CIDR `192.168.1.0` que vous avez ajouté à votre VPC. Sans mise en réseau personnalisée, des adresses auraient été attribuées à partir du bloc CIDR `192.168.0.0`, car il s'agissait du seul bloc CIDR initialement associé au VPC.

   Si le champ `spec` d’un pod contient `hostNetwork=true`, cela signifie que le pod utilise l’adresse IP principale du nœud. Il ne reçoit pas d’adresse IP provenant des nouveaux sous-réseaux ajoutés. Par défaut, cette valeur indique `false`. Cette valeur est définie sur `true` pour le `kube-proxy` et pour les pods du plug-in Amazon VPC CNI pour Kubernetes (`aws-node`) exécutés sur votre cluster. C’est la raison pour laquelle le `kube-proxy` et les pods `aws-node` du plug-in ne reçoivent pas d’adresses de type 192.168.1.x dans le résultat affiché précédemment. Pour plus d'informations sur les `hostNetwork` paramètres d'un pod, consultez la section [PodSpec v1 core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#podspec-v1-core) dans la référence de l'API Kubernetes.

## Étape 5 : suppression des ressources du didacticiel
<a name="custom-network-delete-resources"></a>

Une fois le didacticiel terminé, nous vous recommandons de supprimer les ressources que vous avez créées. Vous pouvez ensuite ajuster les étapes pour activer la mise en réseau personnalisée pour un cluster de production.

1. Si le groupe de nœuds que vous avez créé n'était qu'à des fins de test, supprimez-le.

   ```
   aws eks delete-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup
   ```

1. Même une fois que la sortie de la AWS CLI indique que le cluster est supprimé, le processus de suppression peut ne pas être terminé. Le processus de suppression prend quelques minutes. Vérifiez qu’il est bien finalisé en exécutant la commande suivante.

   ```
   aws eks describe-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup --query nodegroup.status --output text
   ```

   Ne poursuivez pas tant que le résultat renvoyé n’est pas similaire à l’exemple ci-dessous.

   ```
   An error occurred (ResourceNotFoundException) when calling the DescribeNodegroup operation: No node group found for name: my-nodegroup.
   ```

1. Si le groupe de nœuds que vous avez créé n'était qu'à des fins de test, supprimez le rôle IAM du nœud.

   1. Détachez les politiques du rôle.

      ```
      aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodePolicy
      aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
      aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws: iam::aws:policy/AmazonEKS_CNI_Policy
      ```

   1. Supprimez le rôle.

      ```
      aws iam delete-role --role-name myCustomNetworkingNodeRole
      ```

1. Supprimez le cluster.

   ```
   aws eks delete-cluster --name my-custom-networking-cluster
   ```

   Vérifiez que le cluster est supprimé avec la commande suivante.

   ```
   aws eks describe-cluster --name my-custom-networking-cluster --query cluster.status --output text
   ```

   Lorsqu'une sortie similaire à la suivante est renvoyée, le cluster est correctement supprimé.

   ```
   An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: my-custom-networking-cluster.
   ```

1. Supprimez le rôle IAM de cluster.

   1. Détachez les politiques du rôle.

      ```
      aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSClusterRole --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy
      ```

   1. Supprimez le rôle.

      ```
      aws iam delete-role --role-name myCustomNetworkingAmazonEKSClusterRole
      ```

1. Supprimez les sous-réseaux que vous avez créés à l'étape précédente.

   ```
   aws ec2 delete-subnet --subnet-id $new_subnet_id_1
   aws ec2 delete-subnet --subnet-id $new_subnet_id_2
   ```

1. Supprimez le VPC que vous avez créé.

   ```
   aws cloudformation delete-stack --stack-name my-eks-custom-networking-vpc
   ```