**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.
# En savoir plus sur les modes et la configuration CNI Amazon VPC
Le plug-in CNI Amazon VPC pour Kubernetes fournit une mise en réseau pour les pods. Consultez le tableau suivant pour en savoir plus sur les fonctionnalités de mise en réseau disponibles.
| Fonctionnalité de mise en réseau | En savoir plus |
| --- | --- |
| Configurez votre cluster pour attribuer des adresses IPv6 aux clusters, pods et services | [En savoir plus sur IPv6 les adresses des clusters, des pods et des services](cni-ipv6.md) |
| Utilisez la traduction d’adresses réseau source IPv4 pour les pods | [Activer l’accès Internet sortant pour les Pods](external-snat.md) |
| Limitez le trafic réseau vers et depuis vos pods | [Restriction du trafic réseau des pods à l’aide des politiques réseau Kubernetes](cni-network-policy-configure.md) |
| Personnalisez l’interface réseau secondaire dans les nœuds | [Déploiement de pods dans des sous-réseaux alternatifs avec réseau personnalisé](cni-custom-network.md) |
| Augmentez le nombre d’adresses IP pour votre nœud | [Attribution de davantage d’adresses IP aux nœuds Amazon EKS avec des préfixes](cni-increase-ip-addresses.md) |
| Utilisez des groupes de sécurité pour le trafic réseau des pods | [Attribution de groupes de sécurité à des pods individuels](security-groups-for-pods.md) |
| Utilisez plusieurs interfaces réseau pour les pods | [Connecter plusieurs interfaces réseau à des pods](pod-multiple-network-interfaces.md) |
# En savoir plus sur IPv6 les adresses des clusters, des pods et des services
**S'applique à** : Pods avec EC2 instances Amazon et Fargate Pods
Par défaut, Kubernetes attribue des adresses `IPv4` à vos pods et services. Au lieu d’attribuer des adresses `IPv4` à vos pods et services, vous pouvez configurer votre cluster pour leur attribuer des adresses `IPv6`. Amazon EKS ne prend pas en charge les pods ou services double pile, bien que Kubernetes le permette. En conséquence, vous ne pouvez pas attribuer à la fois des adresses `IPv4` et des adresses `IPv6` aux pods et aux services.
Vous sélectionnez la famille IP que vous souhaitez utiliser pour votre cluster lorsque vous le créez. La famille d’adresses ne peut plus être modifiée après la création du cluster.
Pour un tutoriel sur le déploiement d’un cluster `IPv6` Amazon EKS, consultez[Déploiement d’un cluster Amazon EKS `IPv6` et de nœuds Amazon Linux gérés](deploy-ipv6-cluster.md).
Tenez compte des points suivants pour utiliser cette fonctionnalité :
## Prise en charge des fonctionnalités `IPv6`
+ **Absence de prise en charge Windows** : les pods et services Windows ne sont pas pris en charge.
+ ** EC2 Nœuds basés sur Nitro requis : vous ne pouvez les utiliser qu'`IPv6`avec des nœuds** AWS Amazon ou EC2 Fargate basés sur Nitro.
+ **EC2 et nœuds Fargate pris en charge : vous pouvez les utiliser `IPv6` [Attribution de groupes de sécurité à des pods individuels](security-groups-for-pods.md) avec les nœuds** Amazon et les EC2 nœuds Fargate.
+ **Outposts non pris en charge** : vous ne pouvez pas les utiliser `IPv6` avec [Déployez Amazon EKS sur site avec AWS Outposts](eks-outposts.md).
+ **FSx car Lustre n'est pas pris en charge** : Le n'[Utilisez un stockage d’applications haute performance avec Amazon FSx pour Lustre](fsx-csi.md)est pas pris en charge.
+ **Réseau personnalisé non pris en charge** : si vous utilisiez auparavant [Déploiement de pods dans des sous-réseaux alternatifs avec réseau personnalisé](cni-custom-network.md) pour atténuer l’épuisement des adresses IP, vous pouvez utiliser `IPv6` à la place. Vous ne pouvez pas utiliser `IPv6` avec un réseau personnalisé. Si vous utilisez un réseau personnalisé pour l'isolation du réseau, vous devrez peut-être continuer à utiliser un réseau personnalisé et la famille `IPv4` pour vos clusters.
## Attribution des adresses IP
+ **Services Kubernetes** : seules des adresses `IPv6` sont attribuées aux services Kubernetes. Aucune IPv4 adresse ne leur est attribuée.
+ **Pods** : une IPv6 adresse et une adresse locale de l'hôte IPv4 sont attribuées aux pods. L' IPv4 adresse locale de l'hôte est attribuée à l'aide d'un plug-in CNI local lié à un VPC CNI et l'adresse n'est pas signalée au plan de contrôle Kubernetes. Il n'est utilisé que lorsqu'un pod doit communiquer avec une IPv4 ressource externe dans un autre Amazon VPC ou sur Internet. L' IPv4 adresse locale de l'hôte accède SNATed (par VPC CNI) à l' IPv4 adresse principale de l'ENI principal du nœud de travail.
+ **Pods et services** : les pods et services reçoivent uniquement des adresses `IPv6`, jamais des adresses `IPv4`. Lorsque les pods doivent communiquer avec des points de terminaison `IPv4` externes, ils utilisent la NAT directement sur le nœud. Cette fonctionnalité NAT intégrée élimine le besoin de [DNS64 et NAT64](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-nat64-dns64). Pour le trafic nécessitant un accès à Internet public, le trafic du pod est soumis à une conversion d’adresse réseau source vers une adresse IP publique.
+ **Adresses de routage** : lorsqu’un pod communique en dehors du VPC, son adresse `IPv6` d’origine est préservée (elle n’est pas convertie en adresse `IPv6` du nœud.). Ce trafic est routé directement via une passerelle Internet ou une passerelle Internet sortante uniquement.
+ **Nœuds** : tous les nœuds reçoivent une adresse `IPv4` ainsi qu’une adresse `IPv6`.
+ **Pods Fargate** : chaque pod Fargate reçoit une adresse `IPv6` à partir du CIDR spécifié pour le sous-réseau dans lequel il est déployé. L'unité matérielle sous-jacente qui exécute les Fargate Pods obtient une adresse `IPv6` et une adresse `IPv4` uniques attribuées CIDRs au sous-réseau dans lequel l'unité matérielle est déployée.
## Utilisation de `IPv6` avec Amazon EKS
+ **Création d’un nouveau cluster** : vous devez créer un nouveau cluster et spécifier l’utilisation de la famille `IPv6` pour ce cluster. Vous ne pouvez pas activer la famille `IPv6` pour un cluster que vous avez mis à jour à partir d’une version précédente. Pour obtenir des instructions sur la création d’un nouveau cluster, consultez la section Considérations.
+ **Utilisation d’une version récente de VPC CNI** : déployez la version `1.10.1` ou ultérieure du module complémentaire Amazon VPC CNI. Cette version ou une version ultérieure est déployée par défaut. Après avoir déployé le module complémentaire, vous ne pouvez pas rétrograder votre module complémentaire Amazon VPC CNI vers une version inférieure à `1.10.1` sans supprimer au préalable tous les nœuds de tous les groupes de nœuds de votre cluster.
+ **Configurer le VPC CNI pour `IPv6`** : Si vous utilisez des EC2 nœuds Amazon, vous devez configurer le module complémentaire Amazon VPC CNI avec délégation de préfixe IP et. `IPv6` Si vous choisissez la famille `IPv6` lors de la création de votre cluster, la version `1.10.1` du module complémentaire correspond par défaut à cette configuration. C'est le cas pour un module complémentaire auto-géré ou Amazon EKS. Pour de plus amples informations sur la délégation de préfixes IP, veuillez consulter [Attribution de davantage d’adresses IP aux nœuds Amazon EKS avec des préfixes](cni-increase-ip-addresses.md).
+ **Configuration des adresses `IPv4` et `IPv6`** : lorsque vous créez un cluster, le VPC et les sous-réseaux que vous spécifiez doivent disposer d’un bloc CIDR `IPv6` attribué au VPC et aux sous-réseaux que vous spécifiez. Ils doivent également avoir un bloc d'adresse CIDR `IPv4` qui leur est affecté. En effet, même si vous souhaitez uniquement utiliser `IPv6`, un VPC nécessite toujours un bloc d'adresse CIDR `IPv4` pour fonctionner. Pour plus d'informations, consultez [Associer un bloc IPv6 CIDR à votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#vpc-associate-ipv6-cidr) dans le guide de l'utilisateur Amazon VPC.
+ **Attribuer automatiquement IPv6 des adresses aux nœuds :** Lorsque vous créez vos nœuds, vous devez spécifier des sous-réseaux configurés pour attribuer automatiquement `IPv6` des adresses. Sinon, le déploiement des nœuds échouera. Par défaut, cette configuration est désactivée. Pour plus d'informations, consultez [Modifier l'attribut d' IPv6 adressage de votre sous-réseau](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-ipv6) dans le guide de l'utilisateur Amazon VPC.
+ **Configuration des tables de routage pour utilise `IPv6` ** : les tables de routage attribuées à vos sous-réseaux contenir des routes pour les adresses `IPv6`. Pour de plus amples informations, veuillez consulter la section [Migrer vers IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) du Guide de l'utilisateur Amazon VPC.
+ **Configuration des groupes de sécurité pour`IPv6`** : vos groupes de sécurité doivent autoriser les adresses `IPv6`. Pour de plus amples informations, veuillez consulter la section [Migrer vers IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) du Guide de l'utilisateur Amazon VPC.
+ **Configurer l'équilibreur de charge** : utilisez la version `2.3.1` ou une version ultérieure du AWS Load Balancer Controller pour équilibrer la charge des applications HTTP à l'aide [Routage du trafic des applications et du trafic HTTP avec des équilibreurs de charge Application Load Balancer](alb-ingress.md) du ou du trafic réseau utilisant les deux pods, [Acheminer le trafic TCP et UDP avec des Network Load Balancers](network-load-balancing.md) l'`IPv6`un des équilibreurs de charge étant en mode IP, mais pas en mode instance. Pour de plus amples informations, veuillez consulter [Acheminez le trafic Internet avec le AWS Load Balancer Controller](aws-load-balancer-controller.md).
+ **Ajout de la politique IAM `IPv6`** : vous devez attacher une politique IAM `IPv6` au rôle IAM du nœud ou au rôle IAM du plug-in CNI. Entre les deux, nous vous recommandons de le rattacher à un rôle CNI IAM. Pour plus d’informations, consultez [Créer une politique IAM pour les clusters qui utilisent la famille `IPv6`](cni-iam-role.md#cni-iam-role-create-ipv6-policy) et [Étape 1 : créer le rôle IAM du plug-in Amazon VPC CNI pour Kubernetes](cni-iam-role.md#cni-iam-role-create-role).
+ **Évaluez tous les composants** : effectuez une évaluation approfondie de vos applications, des modules complémentaires Amazon EKS et AWS des services auxquels vous intégrez avant de déployer `IPv6` des clusters. Cela permet de s'assurer que tout fonctionne comme prévu avec `IPv6`.
# Déploiement d’un cluster Amazon EKS `IPv6` et de nœuds Amazon Linux gérés
Dans ce didacticiel, vous allez déployer un `IPv6` Amazon VPC, un cluster Amazon EKS appartenant à la `IPv6` famille et un groupe de nœuds géré avec des nœuds EC2 Amazon Linux. Vous ne pouvez pas déployer de nœuds Amazon EC2 Windows dans un `IPv6` cluster. Vous pouvez également déployer des nœuds Fargate dans votre cluster, mais ces instructions ne sont pas fournies dans cette rubrique pour des raisons de simplicité.
## Conditions préalables
Avant de commencer le tutoriel, veuillez effectuer les opérations suivantes :
Installez et configurez les outils et ressources suivants dont vous aurez besoin pour créer et gérer un cluster Amazon EKS.
+ Nous vous recommandons de vous familiariser avec tous les paramètres et de déployer un cluster avec les paramètres qui répondent à vos besoins. Pour plus d’informations, consultez [Création d’un cluster Amazon EKS](create-cluster.md), [Simplifiez le cycle de vie des nœuds avec des groupes de nœuds gérés](managed-node-groups.md), et les [considérations](cni-ipv6.md) relatives à ce sujet. Vous ne pouvez activer certains paramètres que lors de la création de votre cluster.
+ L'outil de ligne de commande `kubectl` est installé sur votre appareil ou AWS CloudShell. La version peut correspondre à celle utilisée par votre cluster Kubernetes, ou différer d’au plus une version mineure, qu’elle soit antérieure ou plus récente. Par exemple, si la version de votre cluster est `1.29`, vous pouvez utiliser la version `kubectl` `1.28`, `1.29` ou `1.30`. Pour installer ou mettre à niveau `kubectl`, veuillez consulter [Configuration de `kubectl` et `eksctl`](install-kubectl.md).
+ Le principal de sécurité IAM que vous utilisez doit être autorisé à utiliser les rôles IAM Amazon EKS, les rôles liés à un service AWS CloudFormation, un VPC et les ressources associées. Pour plus d’informations, consultez les sections [Actions](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html) et [Utilisation des rôles liés aux services](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) dans le Guide de l’utilisateur IAM.
+ Si vous utilisez eksctl, installez la version `0.215.0` ou une version ultérieure sur votre ordinateur. Pour l'installer ou le mettre à jour, veuillez consulter [Installation](https://eksctl.io/installation) dans la documentation de `eksctl`.
+ 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` Homebrew pour macOS ont souvent plusieurs versions de retard sur la dernière version de la AWS CLI. `apt-get` 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*. Si vous utilisez le AWS CloudShell, vous devrez peut-être [installer la version 2.12.3 ou ultérieure ou 1.27.160 ou ultérieure de la CLI, car la version de la AWSAWS CLI](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) par défaut installée dans le AWS CloudShell peut être une version antérieure.
Vous pouvez utiliser eksctl ou CLI pour déployer un cluster `IPv6`.
## Déployer un IPv6 cluster avec eksctl
1. Créez le fichier `ipv6-cluster.yaml`. Copiez la commande qui suit sur votre appareil. Si nécessaire, apportez les modifications suivantes à la commande, puis exécutez la commande modifiée :
+ Remplacez *my-cluster* par un nom pour votre cluster. Un nom ne peut contenir que des caractères alphanumériques (sensibles à la casse) et des traits d'union. Il doit commencer par un caractère alphanumérique et ne peut pas dépasser 100 caractères. Le nom doit être unique dans la AWS région et le AWS compte dans lesquels vous créez le cluster.
+ Remplacez *region-code* par n'importe quelle AWS région prise en charge par Amazon EKS. Pour obtenir la liste des AWS régions, consultez la section [Points de terminaison et quotas Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) dans le guide de référence AWS général.
+ La valeur de `version` correspond à la version de votre cluster. Pour plus d’informations, consultez les [versions prises en charge par Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ Remplacer *my-nodegroup* avec un nom pour votre groupe de nœuds. 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.
+ Remplacez *t3.medium* par tout [type d'instance du système AWS Nitro](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances).
```
cat >ipv6-cluster.yaml <
aws-node-t74jh 1/1 Running 0 5m32s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-cw7w2 1/1 Running 0 56m 2600:1f13:b66:8203:34e5:: ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-tx6n8 1/1 Running 0 56m 2600:1f13:b66:8203:34e5::1 ip-192-168-253-70.region-code.compute.internal
kube-proxy-btpbk 1/1 Running 0 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
kube-proxy-jjk2g 1/1 Running 0 5m33s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
```
1. Vérifiez que les adresses `IPv6` sont attribuées aux services par défaut.
```
kubectl get services -n kube-system -o wide
```
L'exemple qui suit illustre un résultat.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kube-dns ClusterIP fd30:3087:b6c2::a 53/UDP,53/TCP 57m k8s-app=kube-dns
```
1. (Facultatif) [Déployez un exemple d’application](sample-deployment.md) ou déployez le [Contrôleur d’équilibreur de charge AWS](aws-load-balancer-controller.md) et un exemple d’application pour équilibrer la charge des applications HTTP avec [Routage du trafic des applications et du trafic HTTP avec des équilibreurs de charge Application Load Balancer](alb-ingress.md) ou le trafic réseau vers les pods [Acheminer le trafic TCP et UDP avec des Network Load Balancers](network-load-balancing.md) ou `IPv6`.
1. Une fois que vous avez terminé avec le cluster et les nœuds que vous avez créés pour ce tutoriel, vous devez nettoyer les ressources que vous avez créées avec la commande suivante.
```
eksctl delete cluster my-cluster
```
## Déployer un IPv6 cluster avec une AWS CLI
**Important**
Vous devez effectuer toutes les étapes de cette procédure avec le même utilisateur. Exécutez la commande suivante pour vérifier l'utilisateur actuel :
```
aws sts get-caller-identity
```
Vous devez effectuer toutes les étapes de cette procédure dans le même shell. Plusieurs étapes utilisent des variables définies dans les étapes précédentes. Les étapes qui utilisent des variables ne fonctionneront pas correctement si les valeurs de ces variables sont définies dans un autre shell. Si vous utilisez le [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html)pour effectuer la procédure suivante, n'oubliez pas que si vous n'interagissez pas avec le clavier ou le pointeur pendant environ 20 à 30 minutes, votre session shell se termine. Les processus en cours d'exécution ne sont pas considérés comme des interactions.
Les instructions sont écrites pour le shell Bash et peuvent nécessiter des ajustements dans d'autres shells.
Remplacez toutes les valeurs d'exemple dans les étapes de cette procédure par vos propres valeurs.
1. Exécutez les commandes suivantes pour définir certaines variables utilisées dans les étapes suivantes. Remplacez *region-code* par la AWS région dans laquelle vous souhaitez déployer vos ressources. La valeur peut être n'importe quelle AWS région prise en charge par Amazon EKS. Pour obtenir la liste des AWS régions, consultez la section [Points de terminaison et quotas Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) dans le guide de référence AWS général. Remplacez *my-cluster* par un nom pour votre cluster. Un nom ne peut contenir que des caractères alphanumériques (sensibles à la casse) et des traits d'union. Il doit commencer par un caractère alphanumérique et ne peut pas dépasser 100 caractères. Le nom doit être unique dans la AWS région et le AWS compte dans lesquels vous créez le cluster. Remplacer *my-nodegroup* avec un nom pour votre groupe de nœuds. 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. Remplacez *111122223333* par votre ID de compte.
```
export region_code=region-code
export cluster_name=my-cluster
export nodegroup_name=my-nodegroup
export account_id=111122223333
```
1. Créez un Amazon VPC avec des sous-réseaux publics et privés qui répondent aux exigences Amazon EKS et `IPv6`.
1. Exécutez la commande suivante pour définir une variable pour le nom de votre AWS CloudFormation pile. Vous pouvez remplacer *my-eks-ipv6-vpc* par n'importe quel nom que vous choisissez.
```
export vpc_stack_name=my-eks-ipv6-vpc
```
1. Créez un `IPv6` VPC à l'aide d'un AWS CloudFormation modèle.
```
aws cloudformation create-stack --region $region_code --stack-name $vpc_stack_name \
--template-url https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-ipv6-vpc-public-private-subnets.yaml
```
La création de la pile prend quelques minutes. Exécutez la commande suivante. Ne passez pas à l’étape suivante tant que le résultat de la commande n’est pas `CREATE_COMPLETE`.
```
aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name --query Stacks[].StackStatus --output text
```
1. Récupérez IDs les sous-réseaux publics qui ont été créés.
```
aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPublic`].OutputValue' --output text
```
L'exemple qui suit illustre un résultat.
```
subnet-0a1a56c486EXAMPLE,subnet-099e6ca77aEXAMPLE
```
1. Activez l'option d'attribution automatique d'adresses `IPv6` pour les sous-réseaux publics qui ont été créés.
```
aws ec2 modify-subnet-attribute --region $region_code --subnet-id subnet-0a1a56c486EXAMPLE --assign-ipv6-address-on-creation
aws ec2 modify-subnet-attribute --region $region_code --subnet-id subnet-099e6ca77aEXAMPLE --assign-ipv6-address-on-creation
```
1. Récupérez les noms des sous-réseaux et des groupes de sécurité créés par le modèle à partir de la AWS CloudFormation pile déployée et stockez-les dans des variables pour une utilisation ultérieure.
```
security_groups=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SecurityGroups`].OutputValue' --output text)
public_subnets=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPublic`].OutputValue' --output text)
private_subnets=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPrivate`].OutputValue' --output text)
subnets=${public_subnets},${private_subnets}
```
1. Créez un rôle IAM de cluster et attachez-y la politique gérée par Amazon EKS IAM requise. Les clusters Kubernetes gérés par Amazon EKS appellent d'autres AWS services en votre nom afin de gérer les ressources que vous utilisez avec le service.
1. Exécutez la commande suivante pour créer un fichier `eks-cluster-role-trust-policy.json` :
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Exécutez la commande suivante pour définir une variable pour votre nom de rôle. Vous pouvez remplacer *myAmazonEKSClusterRole* par n'importe quel nom que vous choisissez.
```
export cluster_role_name=myAmazonEKSClusterRole
```
1. Créez le rôle.
```
aws iam create-role --role-name $cluster_role_name --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. Récupérez l'ARN du rôle IAM et le stockez dans une variable pour une étape ultérieure.
```
CLUSTER_IAM_ROLE=$(aws iam get-role --role-name $cluster_role_name --query="Role.Arn" --output text)
```
1. Attachez la politique IAM gérée par Amazon EKS au rôle.
```
aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy --role-name $cluster_role_name
```
1. Créer votre cluster.
```
aws eks create-cluster --region $region_code --name $cluster_name --kubernetes-version 1.XX \
--role-arn $CLUSTER_IAM_ROLE --resources-vpc-config subnetIds=$subnets,securityGroupIds=$security_groups \
--kubernetes-network-config ipFamily=ipv6
```
1. REMARQUE : 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).
La création du cluster prend quelques minutes. Exécutez la commande suivante. Ne passez pas à l’étape suivante tant que la sortie de la commande n’est pas `ACTIVE`.
```
aws eks describe-cluster --region $region_code --name $cluster_name --query cluster.status
```
1. Créez ou mettez à jour un fichier `kubeconfig` pour votre cluster afin de pouvoir communiquer avec votre cluster.
```
aws eks update-kubeconfig --region $region_code --name $cluster_name
```
Par défaut, le fichier `config` est créé dans `~/.kube` ou la configuration du nouveau cluster est ajoutée à un fichier `config` existant dans `~/.kube`.
1. Créez un rôle IAM de nœud.
1. Exécutez la commande suivante pour créer un fichier `vpc-cni-ipv6-policy.json` :
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssignIpv6Addresses",
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeInstanceTypes"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
1. Créez la politique IAM.
```
aws iam create-policy --policy-name AmazonEKS_CNI_IPv6_Policy --policy-document file://vpc-cni-ipv6-policy.json
```
1. Exécutez la commande suivante pour créer un fichier `node-role-trust-relationship.json` :
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Exécutez la commande suivante pour définir une variable pour votre nom de rôle. Vous pouvez remplacer *AmazonEKSNodeRole* par n'importe quel nom que vous choisissez.
```
export node_role_name=AmazonEKSNodeRole
```
1. Créez le rôle IAM.
```
aws iam create-role --role-name $node_role_name --assume-role-policy-document file://"node-role-trust-relationship.json"
```
1. Attachez la politique IAM au rôle IAM.
```
aws iam attach-role-policy --policy-arn arn:aws: iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy \
--role-name $node_role_name
```
**Important**
Pour simplifier ce tutoriel, la politique est attachée à ce rôle IAM. Toutefois, dans un cluster de production, nous recommandons de rattacher la politique à un rôle IAM distinct. Pour de plus amples informations, veuillez consulter [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md).
1. Attachez deux 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 $node_role_name
aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
--role-name $node_role_name
```
1. Récupérez l'ARN du rôle IAM et le stockez dans une variable pour une étape ultérieure.
```
node_iam_role=$(aws iam get-role --role-name $node_role_name --query="Role.Arn" --output text)
```
1. Créez un groupe de nœuds gérés.
1. Affichez les IDs sous-réseaux que vous avez créés à l'étape précédente.
```
echo $subnets
```
L'exemple qui suit illustre un résultat.
```
subnet-0a1a56c486EXAMPLE,subnet-099e6ca77aEXAMPLE,subnet-0377963d69EXAMPLE,subnet-0c05f819d5EXAMPLE
```
1. Créez le groupe de nœuds. Remplacez *0a1a56c486EXAMPLE*, *099e6ca77aEXAMPLE*, *0377963d69EXAMPLE*, et *0c05f819d5EXAMPLE* par les valeurs renvoyées dans la sortie de l'étape précédente. Assurez-vous de supprimer les virgules entre les sous-réseaux IDs de la sortie précédente dans la commande suivante. Vous pouvez remplacer *t3.medium* par tout [type d'instance du système AWS Nitro](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances).
```
aws eks create-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name \
--subnets subnet-0a1a56c486EXAMPLE subnet-099e6ca77aEXAMPLE subnet-0377963d69EXAMPLE subnet-0c05f819d5EXAMPLE \
--instance-types t3.medium --node-role $node_iam_role
```
La création du groupe de nœuds prend quelques minutes. Exécutez la commande suivante. Ne passez pas à l’étape suivante tant que le résultat renvoyé n’est pas `ACTIVE`.
```
aws eks describe-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name \
--query nodegroup.status --output text
```
1. Vérifiez que les pods par défaut se voient attribuer des adresses `IPv6` dans la colonne `IP`.
```
kubectl get pods -n kube-system -o wide
```
L'exemple qui suit illustre un résultat.
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
aws-node-rslts 1/1 Running 1 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
aws-node-t74jh 1/1 Running 0 5m32s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-cw7w2 1/1 Running 0 56m 2600:1f13:b66:8203:34e5:: ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-tx6n8 1/1 Running 0 56m 2600:1f13:b66:8203:34e5::1 ip-192-168-253-70.region-code.compute.internal
kube-proxy-btpbk 1/1 Running 0 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
kube-proxy-jjk2g 1/1 Running 0 5m33s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
```
1. Vérifiez que les adresses `IPv6` sont attribuées aux services par défaut dans la colonne `IP`.
```
kubectl get services -n kube-system -o wide
```
L'exemple qui suit illustre un résultat.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kube-dns ClusterIP fd30:3087:b6c2::a 53/UDP,53/TCP 57m k8s-app=kube-dns
```
1. (Facultatif) [Déployez un exemple d’application](sample-deployment.md) ou déployez le [Contrôleur d’équilibreur de charge AWS](aws-load-balancer-controller.md) et un exemple d’application pour équilibrer la charge des applications HTTP avec [Routage du trafic des applications et du trafic HTTP avec des équilibreurs de charge Application Load Balancer](alb-ingress.md) ou le trafic réseau vers les pods [Acheminer le trafic TCP et UDP avec des Network Load Balancers](network-load-balancing.md) ou `IPv6`.
1. Une fois que vous avez terminé avec le cluster et les nœuds que vous avez créés pour ce tutoriel, vous devez nettoyer les ressources que vous avez créées avec les commandes suivantes. Assurez-vous que vous n’utilisez aucune des ressources en dehors de ce tutoriel avant de les supprimer.
1. Si vous effectuez cette étape dans un shell différent de celui dans lequel vous avez effectué les étapes précédentes, définissez les valeurs de toutes les variables utilisées dans les étapes précédentes, en remplaçant les valeurs d’exemple par les valeurs que vous avez spécifiées lorsque vous avez effectué les étapes précédentes. Si vous effectuez cette étape dans le même shell que celui dans lequel vous avez effectué les étapes précédentes, passez à l’étape suivante.
```
export region_code=region-code
export vpc_stack_name=my-eks-ipv6-vpc
export cluster_name=my-cluster
export nodegroup_name=my-nodegroup
export account_id=111122223333
export node_role_name=AmazonEKSNodeRole
export cluster_role_name=myAmazonEKSClusterRole
```
1. Supprimez votre groupe de nœuds.
```
aws eks delete-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name
```
La suppression prend quelques minutes. Exécutez la commande suivante. Ne pas passer à l’étape suivante si une sortie est retournée.
```
aws eks list-nodegroups --region $region_code --cluster-name $cluster_name --query nodegroups --output text
```
1. Supprimez le cluster.
```
aws eks delete-cluster --region $region_code --name $cluster_name
```
La suppression du cluster prend quelques minutes. Avant de continuer, assurez-vous que le cluster est supprimé avec la commande suivante.
```
aws eks describe-cluster --region $region_code --name $cluster_name
```
Ne passez pas à l’étape suivante tant que votre résultat n’est pas similaire au résultat suivant.
```
An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: my-cluster.
```
1. Supprimez les ressources IAM que vous avez créées. Remplacez *AmazonEKS\$1CNI\$1IPv6\$1Policy* par le nom que vous avez choisi, si vous avez choisi un nom différent de celui utilisé dans les étapes précédentes.
```
aws iam detach-role-policy --role-name $cluster_role_name --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodePolicy
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws: iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy
aws iam delete-policy --policy-arn arn:aws: iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy
aws iam delete-role --role-name $cluster_role_name
aws iam delete-role --role-name $node_role_name
```
1. Supprimez la AWS CloudFormation pile qui a créé le VPC.
```
aws cloudformation delete-stack --region $region_code --stack-name $vpc_stack_name
```
# Activer l’accès Internet sortant pour les Pods
**S’applique à** : nœuds Linux `IPv4` Fargate, nœuds Linux avec instances Amazon EC2
Si vous avez déployé votre cluster à l’aide de la famille `IPv6`, les informations de cette rubrique ne s’appliquent pas à votre cluster, car les adresses `IPv6` ne sont pas traduites en réseau. Pour plus d'informations sur l'utilisation des adresses `IPv6` avec votre cluster, veuillez consulter [En savoir plus sur IPv6 les adresses des clusters, des pods et des services](cni-ipv6.md).
Par défaut, chaque pod de votre cluster se voit attribuer une adresse `IPv4` [privée](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-private-addresses) provenant d’un bloc CIDR (Classless Inter-Domain Routing) associé au VPC dans lequel le pod est déployé. Les pods du même VPC communiquent ensemble via l’adresse IP privée. Lorsqu’un pod communique avec une adresse `IPv4` qui ne se trouve pas dans un bloc CIDR associé à votre VPC, le plug-in Amazon VPC CNI (pour [Linux](https://github.com/aws/amazon-vpc-cni-k8s#amazon-vpc-cni-k8s) ou [Windows](https://github.com/aws/amazon-vpc-cni-plugins/tree/master/plugins/vpc-bridge)) traduit l’adresse `IPv4` du pod en adresse `IPv4` privée principale de [l’interface réseau Elastic](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#eni-basics) principale du nœud sur lequel le pod est exécuté, par défaut [\$1](#snat-exception).
**Note**
Pour les nœuds Windows, il y a des détails supplémentaires à prendre en compte. Par défaut, le [plug-in CNI VPC pour Windows](https://github.com/aws/amazon-vpc-cni-plugins/tree/master/plugins/vpc-bridge) est défini avec une configuration réseau dans laquelle le trafic vers une destination au sein du même VPC est exclu pour la SNAT. Cela signifie que la SNAT est désactivée pour la communication interne du VPC et que l’adresse IP attribuée à un pod est acheminable au sein du VPC. Mais le trafic vers une destination en dehors du VPC a l’adresse IP source du pod SNAT vers l’adresse IP principale de l’ENI de l’instance. Cette configuration par défaut pour Windows garantit que le pod peut accéder à des réseaux extérieurs à votre VPC de la même manière que l’instance hôte.
Compte tenu de ce comportement :
+ Vos pods ne peuvent communiquer avec des ressources Internet que si le nœud sur lequel ils s’exécutent dispose d’une adresse IP [publique](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-public-addresses) ou [Elastic](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-eips.html) qui lui est attribuée et se trouve dans un [sous-réseau public](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-basics). Une [table de routage](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) associée d’un sous-réseau public comporte une route vers une passerelle Internet. Nous recommandons de déployer les nœuds dans des sous-réseaux privés, dans la mesure du possible.
+ [Pour les versions du plugin antérieures`1.8.0`, les ressources qui se trouvent dans des réseaux ou VPCs qui sont connectées à votre VPC de cluster via le [peering VPC, un VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) de transit ou Direct [AWS Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) ne peuvent pas établir de communication avec vos Pods via des interfaces réseau élastiques secondaires.](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html) Cependant, vos pods peuvent initier une communication avec ces ressources et recevoir des réponses de leur part.
Si l'une des affirmations suivantes est vraie dans votre environnement, modifiez la configuration par défaut à l'aide de la commande suivante.
+ [Vous disposez de ressources situées dans des réseaux ou VPCs connectées à votre VPC de cluster via le [peering VPC, un VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) de transit ou Direct [AWS Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) qui doivent établir une communication avec vos pods à l'aide d'une `IPv4` adresse et la version de votre plugin est antérieure à.](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html) `1.8.0`
+ Vos pods se trouvent dans un [sous-réseau privé](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-basics) et doivent communiquer en sortie vers Internet. Le sous-réseau dispose d'une route vers une [passerelle NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html).
```
kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_EXTERNALSNAT=true
```
**Note**
Les variables de configuration `AWS_VPC_K8S_CNI_EXTERNALSNAT` et `AWS_VPC_K8S_CNI_EXCLUDE_SNAT_CIDRS` CNI ne s’appliquent pas aux nœuds Windows. La désactivation de la SNAT n’est pas prise en charge pour Windows. Quant à l'exclusion d'une liste `IPv4` CIDRs de du SNAT, vous pouvez la définir en spécifiant le `ExcludedSnatCIDRs` paramètre dans le script de démarrage Windows. Pour plus d'informations sur ce paramètre, veuillez consulter la rubrique [Paramètres de configuration du script d'amorçage](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
## Mise en réseau de l’hôte
\$1 Si les spécifications d’un pod contiennent `hostNetwork=true` (la valeur par défaut est `false`), son adresse IP n’est pas traduite en une autre adresse. C’est le cas, par défaut, du plug-in `kube-proxy` et Amazon VPC CNI pour les pods Kubernetes qui s’exécutent sur votre cluster. Pour ces pods, l’adresse IP est la même que l’adresse IP principale du nœud, donc l’adresse IP du pod n’est pas traduite. 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.
# Limitation du trafic des pods à l’aide des politiques réseau Kubernetes
## Présentation de
Par défaut, Kubernetes n’impose aucune restriction concernant les adresses IP, les ports ou les connexions entre les pods d’un même cluster, ni entre vos pods et des ressources situées dans d’autres réseaux. Vous pouvez utiliser une *politique réseau* Kubernetes pour limiter le trafic réseau vers et depuis vos pods. Pour plus d’informations, consultez [Politiques réseau](https://kubernetes.io/docs/concepts/services-networking/network-policies/) dans la documentation Kubernetes.
## Politique réseau standard
Vous pouvez utiliser la norme `NetworkPolicy` pour segmenter le pod-to-pod trafic dans le cluster. Ces politiques réseau s'appliquent aux couches 3 et 4 du modèle de réseau OSI, ce qui vous permet de contrôler le flux de trafic au niveau de l'adresse IP ou du port au sein de votre cluster Amazon EKS. Les politiques réseau standard sont limitées au niveau de l'espace de noms.
### Cas d’utilisation
+ Segmentez le trafic réseau entre les charges de travail afin de garantir que seules les applications associées puissent communiquer entre elles.
+ Isolez les locataires au niveau de l'espace de noms à l'aide de politiques visant à appliquer la séparation des réseaux.
### Exemple
Dans la politique ci-dessous, le trafic sortant des pods d'*applications Web* dans l'espace de noms *Sun* est restreint.
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: webapp-egress-policy
namespace: sun
spec:
podSelector:
matchLabels:
role: webapp
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
name: moon
podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 8080
- to:
- namespaceSelector:
matchLabels:
name: stars
podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 8080
```
La politique s'applique aux modules dont l'étiquette figure `role: webapp` dans l'espace de `sun` noms.
+ Trafic autorisé : pods dont l'étiquette figure `role: frontend` dans l'espace de `moon` noms du port TCP `8080`
+ Trafic autorisé : Pods portant le label role : frontend dans l'espace de `stars` noms du port TCP `8080`
+ Trafic bloqué : tout autre trafic sortant provenant `webapp` des pods est implicitement refusé
## Politique réseau de l'administrateur (ou du cluster)
![\[illustration de l'ordre d'évaluation des politiques réseau dans EKS\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/evaluation-order.png)
Vous pouvez utiliser le `ClusterNetworkPolicy` pour appliquer une norme de sécurité réseau qui s'applique à l'ensemble du cluster. Au lieu de définir et de gérer de manière répétitive une politique distincte pour chaque espace de noms, vous pouvez utiliser une seule stratégie pour gérer de manière centralisée les contrôles d'accès au réseau pour les différentes charges de travail du cluster, quel que soit leur espace de noms.
### Cas d’utilisation
+ Gérez de manière centralisée les contrôles d'accès au réseau pour toutes les charges de travail (ou un sous-ensemble de celles-ci) de votre cluster EKS.
+ Définissez une posture de sécurité réseau par défaut sur l'ensemble du cluster.
+ Étendez les normes de sécurité organisationnelles au périmètre du cluster de manière plus efficace sur le plan opérationnel.
### Exemple
Dans la politique ci-dessous, vous pouvez explicitement bloquer le trafic du cluster en provenance d'autres espaces de noms afin d'empêcher l'accès réseau à un espace de noms de charge de travail sensible.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## Remarques importantes
Les politiques réseau du plug-in Amazon VPC CNI pour Kubernetes sont prises en charge dans les configurations répertoriées ci-dessous.
+ Version 1.21.0 (ou ultérieure) du plugin Amazon VPC CNI pour les politiques réseau standard et d'administration.
+ Cluster configuré pour les adresses `IPv4` ou `IPv6`.
+ Vous pouvez utiliser les politiques réseau avec des [groupes de sécurité pour les pods](security-groups-for-pods.md). Grâce aux stratégies réseau, vous pouvez contrôler toutes les communications au sein du cluster. Avec les groupes de sécurité pour Pods, vous pouvez contrôler l'accès aux AWS services depuis les applications d'un Pod.
+ Vous pouvez utiliser les stratégies réseau avec *mise en réseau personnalisée* et *délégation de préfixes*.
## Considérations
**Architecture**
+ Lorsque vous appliquez les politiques réseau du plug-in Amazon VPC CNI pour Kubernetes à votre cluster à l'aide du plug-in Amazon VPC CNI pour Kubernetes, vous pouvez appliquer les politiques aux nœuds Amazon Linux uniquement. EC2 Il n’est pas possible d’appliquer ces politiques aux nœuds Fargate ni aux nœuds Windows.
+ Les politiques réseau ne s’appliquent qu’à une seule famille d’adresses IP, soit `IPv4`, soit `IPv6`, mais pas aux deux en même temps. Dans un cluster `IPv4`, le plug-in VPC CNI attribue des adresses `IPv4` aux pods et applique les politiques `IPv4` correspondantes. Dans un cluster `IPv6`, le plug-in VPC CNI attribue des adresses `IPv6` aux pods et applique les politiques `IPv6` correspondantes. Toute règle de politique réseau `IPv4` appliquée à un cluster `IPv6` est ignorée. Toute règle de politique réseau `IPv6` appliquée à un cluster `IPv4` est ignorée.
**Politiques réseau**
+ Les politiques réseau s’appliquent uniquement aux pods faisant partie d’un déploiement. Les pods autonomes qui n’ont pas de `metadata.ownerReferences` définies ne peuvent pas se voir appliquer de politique réseau.
+ Il est possible d’appliquer plusieurs politiques réseau à un même pod. Lorsque plusieurs politiques ciblent le même pod, toutes les politiques sont appliquées simultanément.
+ Le nombre maximal de combinaisons de ports et de protocoles pour une même plage d’adresses IP (CIDR) est de 24, toutes politiques réseau confondues. Des sélecteurs tels que `namespaceSelector` Resolve to a un ou plusieurs CIDRs. Si plusieurs sélecteurs aboutissent à la même plage CIDR ou si une même plage CIDR directe est spécifiée plusieurs fois, dans une ou plusieurs politiques réseau, chacune de ces occurrences compte dans cette limite.
+ Pour tous les services Kubernetes, le port du service doit être identique au port du conteneur. Si vous utilisez des ports nommés, vous devez employer le même nom dans la spécification du service.
**Politiques du réseau d'administration**
1. **Politiques du niveau administrateur (évaluées en premier)** : toutes les politiques du niveau administrateur ClusterNetworkPolicies sont évaluées avant les autres politiques. Au niveau administrateur, les politiques sont traitées par ordre de priorité (le numéro de priorité le plus bas en premier). Le type d'action détermine ce qui se passe ensuite.
+ **Refuser l'action (priorité la plus élevée)** : lorsqu'une politique d'administration associée à une action de refus correspond au trafic, ce trafic est immédiatement bloqué, quelles que soient les autres politiques. Aucune autre ClusterNetworkPolicy NetworkPolicy règle n'est traitée. Cela garantit que les contrôles de sécurité à l'échelle de l'organisation ne peuvent pas être remplacés par des politiques au niveau de l'espace de noms.
+ **Autoriser l'action** : une fois les règles de refus évaluées, les politiques d'administration comportant des actions d'autorisation sont traitées par ordre de priorité (le numéro de priorité le plus bas en premier). Lorsqu'une action Autoriser correspond, le trafic est accepté et aucune autre évaluation de politique n'est effectuée. Ces politiques peuvent accorder l'accès à plusieurs espaces de noms en fonction de sélecteurs d'étiquettes, offrant ainsi un contrôle centralisé des charges de travail pouvant accéder à des ressources spécifiques.
+ **Action de transfert** : les actions de transfert prévues dans les politiques du niveau administrateur délèguent la prise de décision aux niveaux inférieurs. Lorsque le trafic correspond à une règle Pass, l'évaluation ignore toutes les règles de niveau administrateur restantes pour ce trafic et passe directement au NetworkPolicy niveau. Cela permet aux administrateurs de déléguer explicitement le contrôle de certains modèles de trafic aux équipes d'application. Par exemple, vous pouvez utiliser les règles Pass pour déléguer la gestion du trafic intra-espace à des administrateurs d'espaces de noms tout en maintenant des contrôles stricts sur l'accès externe.
1. **Niveau de politique réseau** : si aucune politique de niveau administrateur ne correspond à Deny ou Allow, ou si une action Pass correspond, les NetworkPolicy ressources délimitées par un espace de noms sont ensuite évaluées. Ces politiques fournissent un contrôle précis au sein des espaces de noms individuels et sont gérées par les équipes d'application. Les politiques étendues à l'espace de noms ne peuvent être que plus restrictives que les politiques d'administration. Ils ne peuvent pas annuler la décision de refus d'une politique d'administration, mais ils peuvent restreindre davantage le trafic autorisé ou approuvé par les politiques d'administration.
1. **Politiques d'administration du niveau de référence** : si aucune politique d'administration ou limitée à un espace de noms ne correspond au trafic, le niveau de référence est évalué. ClusterNetworkPolicies Ils fournissent des postures de sécurité par défaut qui peuvent être remplacées par des politiques délimitées par des espaces de noms, permettant aux administrateurs de définir des valeurs par défaut à l'échelle de l'organisation tout en donnant aux équipes la flexibilité de les personnaliser selon les besoins. Les politiques de base sont évaluées par ordre de priorité (le numéro de priorité le plus bas en premier).
1. **Refus par défaut (si aucune politique ne correspond)** : ce deny-by-default comportement garantit que seules les connexions explicitement autorisées sont autorisées, garantissant ainsi un niveau de sécurité élevé.
**Migration**
+ Si votre cluster utilise actuellement une solution tierce pour gérer les politiques réseau Kubernetes, vous pouvez réutiliser ces mêmes politiques avec le plug-in Amazon VPC CNI pour Kubernetes. Cependant, vous devez supprimer la solution existante afin d’éviter qu’elle ne gère les mêmes politiques en parallèle.
**Avertissement**
Il est recommandé, après avoir supprimé la solution de politique réseau, de remplacer tous les nœuds sur lesquels cette solution était appliquée. Cette mesure permet d’éviter que des règles de trafic résiduelles laissées par un pod de la solution, notamment si celui-ci s’arrête brusquement, ne restent actives sur les nœuds.
**Installation**
+ La fonctionnalité de stratégie réseau crée et nécessite une définition de ressource personnalisée (CRD) de `PolicyEndpoint` appelée `policyendpoints.networking.k8s.aws`. Les objets du `PolicyEndpoint` de la ressource personnalisée sont gérés par Amazon EKS. Vous ne devez ni modifier ni supprimer ces ressources.
+ Si vous exécutez des pods qui utilisent les informations d'identification IAM du rôle d'instance ou si vous vous connectez à l' EC2 IMDS, veillez à vérifier les politiques réseau susceptibles de bloquer l'accès à l' EC2 IMDS. Vous devrez peut-être ajouter une politique réseau pour autoriser l'accès à l' EC2 IMDS. Pour plus d'informations, consultez la section [Métadonnées de l'instance et données utilisateur](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) dans le guide de EC2 l'utilisateur Amazon.
Les pods qui utilisent des *rôles IAM pour les comptes de service* ou *EKS Pod Identity* n'accèdent pas à EC2 IMDS.
+ Le plug-in Amazon VPC CNI pour Kubernetes n’applique pas les politiques réseau aux interfaces réseau supplémentaires pour chaque pod, mais uniquement à l’interface principale de chaque pod (`eth0`). Cela concerne les architectures suivantes :
+ `IPv6` pods dont la variable `ENABLE_V4_EGRESS` est définie sur `true`. Cette variable permet à la fonction de `IPv4` sortie de connecter les IPv6 pods à des `IPv4` points de terminaison tels que ceux situés en dehors du cluster. La fonction de `IPv4` sortie fonctionne en créant une interface réseau supplémentaire avec une adresse de boucle locale. IPv4
+ Lorsque vous utilisez des plugins réseau chaînés tels que Multus. Comme ces plug-ins ajoutent des interfaces réseau à chaque pod, les politiques réseau ne sont pas appliquées aux plug-ins réseau chaînés.
# Restriction du trafic réseau des pods à l’aide des politiques réseau Kubernetes
Les politiques réseau Kubernetes permettent de restreindre le trafic réseau entrant et sortant de vos pods. Pour plus d’informations, consultez [Politiques réseau](https://kubernetes.io/docs/concepts/services-networking/network-policies/) dans la documentation Kubernetes.
Pour utiliser cette fonctionnalité, vous devez effectuer les configurations suivantes :
1. Configurez l’application des politiques au démarrage du pod. Cette opération s’effectue dans le conteneur `aws-node` du `DaemonSet` VPC CNI.
1. Activez le paramètre de politique réseau pour le module complémentaire.
1. Configuration de votre cluster pour qu’il utilise la politique réseau Kubernetes
Avant de commencer, consultez les points à prendre en compte. Pour de plus amples informations, veuillez consulter [Considérations](cni-network-policy.md#cni-network-policy-considerations).
## Conditions préalables
Prérequis pour l’utilisation de cette fonctionnalité :
### Version minimale du cluster
Un cluster Amazon EKS existant. Pour en déployer un, consultez [Mise en route avec Amazon EKS](getting-started.md). Le cluster doit exécuter l'une des versions de Kubernetes et de la plateforme répertoriées dans le tableau suivant. Toute version de Kubernetes et de la plateforme ultérieure à celles indiquées est également prise en charge. Vous pouvez vérifier votre version actuelle de Kubernetes *my-cluster* en remplaçant la commande suivante par le nom de votre cluster, puis en exécutant la commande modifiée :
```
aws eks describe-cluster --name my-cluster --query cluster.version --output text
```
| Version de Kubernetes | Version de la plateforme |
| --- | --- |
| `1.27.4` | `eks.5` |
| `1.26.7` | `eks.6` |
### Version minimale du VPC CNI
Pour créer à la fois des politiques réseau Kubernetes standard et des politiques réseau d'administration, vous devez exécuter `1.21` la version du plugin VPC CNI. Vous pouvez voir la version que vous utilisez actuellement à l'aide de la commande suivante.
```
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
```
Si votre version est antérieure à `1.21`, consultez la section [Mettre à jour le CNI Amazon VPC (module complémentaire Amazon EKS)](vpc-add-on-update.md) pour mettre à jour vers la version `1.21` ou ultérieure.
### Version minimale du noyau Linux
Vos nœuds doivent avoir la version du noyau Linux `5.10` ou ultérieure. Vous pouvez vérifier votre version du noyau avec `uname -r`. Si vous utilisez les dernières versions d'Amazon Linux optimisé pour Amazon EKS, d'Amazon Linux accéléré optimisé pour Amazon EKS et de Bottlerocket AMIs, ils disposent déjà de la version de noyau requise. AMIs
La version `v20231116` ou ultérieure de l'AMI Amazon Linux accélérée et optimisée pour Amazon EKS dispose de la version `5.10` du noyau.
## Étape 1 : configurer l’application des politiques au démarrage du pod
Le plug-in Amazon VPC CNI pour Kubernetes configure les politiques réseau pour les pods en parallèle du processus de provisionnement des pods. Tant que toutes les politiques ne sont pas appliquées au nouveau pod, les conteneurs de ce pod démarrent avec une *politique d’autorisation par défaut*. Ce mode de fonctionnement est appelé *mode standard*. Une politique d’autorisation par défaut signifie que tout le trafic entrant et sortant est autorisé vers et depuis les nouveaux pods. Par exemple, aucune règle de pare-feu ne sera appliquée aux pods (tout le trafic est autorisé) tant que le nouveau pod ne sera pas mis à jour avec les politiques actives.
Lorsque la variable `NETWORK_POLICY_ENFORCING_MODE` est définie sur `strict`, les pods qui utilisent le plug-in VPC CNI commencent *par une politique de refus par défaut*, puis les politiques sont configurées. Ce mode de fonctionnement est appelé *mode strict*. En mode strict, vous devez définir une politique réseau pour chaque point de terminaison auquel vos pods doivent accéder dans le cluster. Cette exigence s’applique également aux pods CoreDNS. La politique de refus par défaut n’est pas configurée pour les pods disposant d’un réseau hôte.
Vous pouvez modifier la politique réseau par défaut en définissant la variable d’environnement `NETWORK_POLICY_ENFORCING_MODE` sur `strict` dans le conteneur `aws-node` du `DaemonSet` VPC CNI.
```
env:
- name: NETWORK_POLICY_ENFORCING_MODE
value: "strict"
```
## Étape 2∘: activer le paramètre de politique réseau pour le module complémentaire
La fonctionnalité de politique réseau utilise le port `8162` du nœud pour les métriques par défaut. En outre, la fonctionnalité utilise le port `8163` pour les sondes de santé. Si vous exécutez une autre application sur les nœuds ou dans les pods qui doivent utiliser ces ports, l'application ne s'exécutera pas. À partir de la version VPC CNI `v1.14.1` ou ultérieure, vous pouvez modifier ces ports.
Suivez la procédure ci-dessous pour activer le paramètre de politique réseau du module complémentaire.
### AWS Management Console
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le panneau de navigation de gauche, sélectionnez **Clusters**, puis sélectionnez le nom du cluster pour lequel vous souhaitez configurer le module complémentaire Amazon VPC CNI.
1. Choisissez l’onglet **Modules complémentaires**.
1. Cochez la case en haut à droite de la zone du module complémentaire, puis sélectionnez **Edit** (Modifier).
1. Sur la page **Configurer `Amazon VPC CNI`** :
1. Sélectionnez une version `v1.14.0-eksbuild.3` ou ultérieure dans la liste **Version**.
1. Sélectionnez **Paramètres de configuration facultatifs**.
1. Saisissez la clé JSON `"enableNetworkPolicy":` et valeur `"true"` dans **Valeurs de configuration**. Le texte obtenu doit être un objet JSON valide. Si cette clé et cette valeur sont les seules données de la zone de texte, entourez-les d'accolades `{ }`.
L’exemple suivant présente une configuration où la fonctionnalité de politique réseau est activée, et où les sondes de surveillance et métriques utilisent les numéros de port par défaut :
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"healthProbeBindAddr": "8163",
"metricsBindAddr": "8162"
}
}
```
### Helm
Si vous avez installé le plug-in Amazon VPC CNI pour Kubernetes via `helm`, vous pouvez mettre à jour la configuration pour modifier les ports.
1. Exécutez la commande suivante pour modifier les ports. Définissez le numéro de port dans la valeur de la clé `nodeAgent.metricsBindAddr` ou de la clé `nodeAgent.healthProbeBindAddr`.
```
helm upgrade --set nodeAgent.metricsBindAddr=8162 --set nodeAgent.healthProbeBindAddr=8163 aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
### kubectl
1. Ouvrez le `aws-node` `DaemonSet` dans votre éditeur.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Remplacez les numéros de port dans les arguments de commande suivants pour le `args:` du conteneur `aws-network-policy-agent` dans le manifeste daemonset `aws-node` du VPC CNI.
```
- args:
- --metrics-bind-addr=:8162
- --health-probe-bind-addr=:8163
```
## Étape 3 : configurer votre cluster pour qu’il utilise la politique réseau Kubernetes
Cette configuration peut être appliquée à un module complémentaire Amazon EKS ou à un module complémentaire autogéré.
### Module complémentaire d'Amazon EKS
À l'aide de la AWS CLI, vous pouvez configurer le cluster pour utiliser les politiques réseau Kubernetes en exécutant la commande suivante. Remplacez `my-cluster` par le nom de votre cluster et l'ARN du rôle IAM par le rôle que vous utilisez.
```
aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
--service-account-role-arn arn:aws: iam::123456789012:role/AmazonEKSVPCCNIRole \
--resolve-conflicts PRESERVE --configuration-values '{"enableNetworkPolicy": "true"}'
```
Pour le configurer à l'aide AWS de la console de gestion, suivez les étapes ci-dessous :
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le panneau de navigation de gauche, sélectionnez **Clusters**, puis sélectionnez le nom du cluster pour lequel vous souhaitez configurer le module complémentaire Amazon VPC CNI.
1. Choisissez l’onglet **Modules complémentaires**.
1. Cochez la case en haut à droite de la zone du module complémentaire, puis sélectionnez **Edit** (Modifier).
1. Sur la page **Configurer `Amazon VPC CNI`** :
1. Sélectionnez une version `v1.14.0-eksbuild.3` ou ultérieure dans la liste **Version**.
1. Sélectionnez **Paramètres de configuration facultatifs**.
1. Saisissez la clé JSON `"enableNetworkPolicy":` et valeur `"true"` dans **Valeurs de configuration**. Le texte obtenu doit être un objet JSON valide. Si cette clé et cette valeur sont les seules données de la zone de texte, entourez-les d'accolades `{ }`. L’exemple suivant montre que la politique réseau est activée :
```
{ "enableNetworkPolicy": "true" }
```
La capture d'écran suivante montre un exemple de ce scénario.
![\[ affichant le module complémentaire VPC CNI avec la politique réseau activée dans la configuration facultative.\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/console-cni-config-network-policy.png)
### Module complémentaire autogéré
Si vous avez installé le plug-in Amazon VPC CNI pour Kubernetes via `helm`, vous pouvez mettre à jour la configuration afin d’activer la politique réseau.
1. Exécutez la commande suivante pour activer la stratégie réseau.
```
helm upgrade --set enableNetworkPolicy=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
1. Ouvrez le `amazon-vpc-cni` `ConfigMap` dans votre éditeur.
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. Ajoutez la ligne suivante dans les `data` de `ConfigMap`.
```
enable-network-policy-controller: "true"
```
Une fois la ligne ajoutée, votre `ConfigMap` doit ressembler à l’exemple ci-dessous.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. Ouvrez le `aws-node` `DaemonSet` dans votre éditeur.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Remplacez `false` par `true` dans l'argument de commande `--enable-network-policy=false` pour le `args:` du conteneur `aws-network-policy-agent` dans le manifeste daemonset du `aws-node` VPC CNI.
```
- args:
- --enable-network-policy=true
```
## Étape 4 : Étapes suivantes
Après avoir terminé la configuration, vérifiez que les pods `aws-node` sont en cours d’exécution dans votre cluster.
```
kubectl get pods -n kube-system | grep 'aws-node\|amazon'
```
L'exemple qui suit illustre un résultat.
```
aws-node-gmqp7 2/2 Running 1 (24h ago) 24h
aws-node-prnsh 2/2 Running 1 (24h ago) 24h
```
Les pods `aws-node` comportent deux conteneurs à partir des versions `1.14` et ultérieures. Dans les versions précédentes et si la stratégie réseau est désactivée, il n'y a qu'un seul conteneur dans les pods du `aws-node`.
Vous pouvez maintenant déployer des politiques réseau Kubernetes dans votre cluster.
Pour implémenter les politiques réseau Kubernetes, vous pouvez créer des Kubernetes `NetworkPolicy` ou des `ClusterNetworkPolicy` objets et les déployer sur votre cluster. `NetworkPolicy`les objets sont limités à un espace de noms, tandis que les `ClusterNetworkPolicy` objets peuvent être étendus à l'ensemble du cluster ou à plusieurs espaces de noms. Vous mettez en œuvre des politiques pour autoriser ou refuser le trafic entre les pods en fonction des sélecteurs d’étiquettes, des espaces de noms et des plages d’adresses IP. Pour plus d’informations sur la création des objets `NetworkPolicy`, consultez [Politiques réseau](https://kubernetes.io/docs/concepts/services-networking/network-policies/#networkpolicy-resource) dans la documentation Kubernetes.
L’application des objets `NetworkPolicy` Kubernetes repose sur l’Extended Berkeley Packet Filter (eBPF). Concernant les implémentations basées sur les `iptables`, il offre des caractéristiques de latence et de performance plus faibles, notamment une utilisation réduite du processeur et l'évitement des recherches séquentielles. De plus, les sondes eBPF fournissent des données contextuelles détaillées permettant de déboguer les problèmes complexes au niveau du noyau et d’améliorer l’observabilité. Amazon EKS prend en charge un exportateur basé sur eBPF qui exploite ces sondes pour enregistrer les résultats des politiques sur chaque nœud et exporter les données vers des collecteurs de journaux externes afin de faciliter le débogage. Pour plus d’informations, consultez [documentation eBPF](https://ebpf.io/what-is-ebpf/#what-is-ebpf).
# Désactiver les politiques réseau Kubernetes pour le trafic réseau des pods Amazon EKS
Désactiver les politiques réseau Kubernetes pour ne plus restreindre le trafic réseau des pods Amazon EKS
1. Répertoriez toutes les politiques réseau Kubernetes.
```
kubectl get netpol -A
```
1. Supprimez chaque politique réseau Kubernetes. Vous devez supprimer toutes les politiques réseau avant de les désactiver.
```
kubectl delete netpol
```
1. Ouvrez le DaemonSet aws-node dans votre éditeur.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Remplacez `true` par `false` dans l'argument de commande `--enable-network-policy=true` pour le `args:` du conteneur `aws-network-policy-agent` dans le manifeste daemonset du `aws-node` VPC CNI.
```
- args:
- --enable-network-policy=true
```
# Dépannage des politiques réseau Kubernetes pour Amazon EKS
Ce guide de dépannage concerne la fonctionnalité de politique réseau d’Amazon VPC CNI.
Ce guide couvre les points suivants :
+ Informations d’installation, autorisations CRD et RBAC [Nouveaux CRD et autorisations `policyendpoints`](#network-policies-troubleshooting-permissions)
+ Journaliser les journaux lors du diagnostic des problèmes de politique réseau [Journaux de stratégie réseau](#network-policies-troubleshooting-flowlogs)
+ Exécution de la collection d’outils du kit SDK eBPF pour le dépannage
+ Problèmes connus et solutions [Problèmes connus et solutions](#network-policies-troubleshooting-known-issues)
**Note**
Veuillez noter que les politiques réseau ne s’appliquent qu’aux pods créés par les *déploiements* Kubernetes. Pour plus d’informations sur les limitations des politiques réseau dans le CNI VPC, consultez [Considérations](cni-network-policy.md#cni-network-policy-considerations).
Vous pouvez dépanner et analyser les connexions réseau qui utilisent des politiques réseau en lisant les [journaux des politiques réseau](#network-policies-troubleshooting-flowlogs) et en exécutant les outils du [kit SDK eBPF](#network-policies-ebpf-sdk).
## Nouveaux CRD et autorisations `policyendpoints`
+ CRD : `policyendpoints.networking.k8s.aws`
+ API Kubernetes : `apiservice` appelé `v1.networking.k8s.io`
+ Ressource Kubernetes : `Kind: NetworkPolicy`
+ RBAC : `ClusterRole` appelé `aws-node` (CNI VPC), `ClusterRole` appelé `eks:network-policy-controller` (contrôleur de politique réseau dans le plan de contrôle du cluster EKS)
Pour la politique réseau, le CNI VPC crée une nouvelle `CustomResourceDefinition` (CRD) appelée `policyendpoints.networking.k8s.aws`. Le CNI du VPC doit être autorisé à créer le CRD et à créer CustomResources (CR) celui-ci et l'autre CRD installé par le VPC CNI (). `eniconfigs.crd.k8s.amazonaws.com` Les deux CRDs sont disponibles dans le [`crds.yaml`fichier](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/charts/aws-vpc-cni/crds/customresourcedefinition.yaml) sur GitHub. Plus précisément, le CNI VPC doit disposer des autorisations « get », « list » et « watch » pour `policyendpoints`.
La *politique réseau* Kubernetes fait partie du `apiservice` appelé `v1.networking.k8s.io`, et il s’agit de `apiversion: networking.k8s.io/v1` dans vos fichiers YAML de politique. Le `DaemonSet` CNI VPC doit disposer des autorisations nécessaires pour utiliser cette partie de l’API Kubernetes.
Les autorisations CNI VPC se trouvent dans un `ClusterRole` appelé `aws-node`. Veuillez noter que les objets `ClusterRole` ne sont pas regroupés dans des espaces de noms. Voici l’`aws-node` d’un cluster :
```
kubectl get clusterrole aws-node -o yaml
```
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/instance: aws-vpc-cni
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: aws-node
app.kubernetes.io/version: v1.19.4
helm.sh/chart: aws-vpc-cni-1.19.4
k8s-app: aws-node
name: aws-node
rules:
- apiGroups:
- crd.k8s.amazonaws.com
resources:
- eniconfigs
verbs:
- list
- watch
- get
- apiGroups:
- ""
resources:
- namespaces
verbs:
- list
- watch
- get
- apiGroups:
- ""
resources:
- pods
verbs:
- list
- watch
- get
- apiGroups:
- ""
resources:
- nodes
verbs:
- list
- watch
- get
- apiGroups:
- ""
- events.k8s.io
resources:
- events
verbs:
- create
- patch
- list
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints
verbs:
- get
- list
- watch
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints/status
verbs:
- get
- apiGroups:
- vpcresources.k8s.aws
resources:
- cninodes
verbs:
- get
- list
- watch
- patch
```
De plus, un nouveau contrôleur s’exécute dans le plan de contrôle de chaque cluster EKS. Le contrôleur utilise les autorisations du `ClusterRole` appelé `eks:network-policy-controller`. Voici l’`eks:network-policy-controller` d’un cluster :
```
kubectl get clusterrole eks:network-policy-controller -o yaml
```
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/name: amazon-network-policy-controller-k8s
name: eks:network-policy-controller
rules:
- apiGroups:
- ""
resources:
- namespaces
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- services
verbs:
- get
- list
- watch
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints
verbs:
- create
- delete
- get
- list
- patch
- update
- watch
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints/finalizers
verbs:
- update
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints/status
verbs:
- get
- patch
- update
- apiGroups:
- networking.k8s.io
resources:
- networkpolicies
verbs:
- get
- list
- patch
- update
- watch
```
## Journaux de stratégie réseau
Chaque décision prise par le VPC CNI concernant l’autorisation ou le refus des connexions par les politiques réseau est journalisée dans les *journaux de flux*. Les journaux de stratégie réseau de chaque nœud incluent les journaux de flux pour chaque pod doté d'une stratégie réseau. Les journaux de stratégie réseau sont stockés sur `/var/log/aws-routed-eni/network-policy-agent.log`. L'exemple suivant est extrait d'un fichier `network-policy-agent.log` :
```
{"level":"info","timestamp":"2023-05-30T16:05:32.573Z","logger":"ebpf-client","msg":"Flow Info: ","Src
IP":"192.168.87.155","Src Port":38971,"Dest IP":"64.6.160","Dest
Port":53,"Proto":"UDP","Verdict":"ACCEPT"}
```
Les journaux de politique réseau sont désactivés par défaut. Pour activer les journaux de stratégie réseau, procédez comme suit :
**Note**
Les journaux de politique réseau nécessitent 1 vCPU supplémentaire pour le conteneur `aws-network-policy-agent` dans le manifeste `aws-node` `DaemonSet` du CNI Amazon VPC.
### Module complémentaire d'Amazon EKS
** AWS Management Console **
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le panneau de navigation de gauche, sélectionnez **Clusters**, puis sélectionnez le nom du cluster pour lequel vous souhaitez configurer le module complémentaire Amazon VPC CNI.
1. Choisissez l’onglet **Modules complémentaires**.
1. Cochez la case en haut à droite de la zone du module complémentaire, puis sélectionnez **Edit** (Modifier).
1. Sur la page **Configurer *Amazon VPC CNI*** :
1. Sélectionnez une version `v1.14.0-eksbuild.3` ou ultérieure dans la liste déroulante **Version**.
1. Sélectionnez **Paramètres de configuration facultatifs**.
1. Saisissez la clé JSON de niveau supérieur de l'`"nodeAgent":` et la valeur est un objet avec une clé `"enablePolicyEventLogs":` et une valeur de `"true"` dans**Valeurs de configuration**. Le texte obtenu doit être un objet JSON valide. L'exemple suivant montre la politique réseau et les journaux de stratégie réseau sont activés, et les journaux de stratégie réseau sont envoyés à CloudWatch Logs :
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"enablePolicyEventLogs": "true"
}
}
```
La capture d'écran suivante montre un exemple de ce scénario.
![\[montrant le module complémentaire VPC CNI avec la politique réseau et les CloudWatch journaux dans la configuration optionnelle.\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/console-cni-config-network-policy-logs.png)
AWS CLI
1. Exécutez la commande AWS CLI suivante. Remplacez `my-cluster` par le nom de votre cluster et l'ARN du rôle IAM par le rôle que vous utilisez.
```
aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
--service-account-role-arn arn:aws: iam::123456789012:role/AmazonEKSVPCCNIRole \
--resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true"}}'
```
### Module complémentaire autogéré
Helm
Si vous avez installé le plug-in CNI Amazon VPC pour Kubernetes via `helm`, vous pouvez mettre à jour la configuration pour écrire les journaux de politique réseau.
1. Exécutez la commande suivante pour activer la stratégie réseau.
```
helm upgrade --set nodeAgent.enablePolicyEventLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
kubectl
Si vous avez installé le plug-in CNI Amazon VPC pour Kubernetes via `kubectl`, vous pouvez mettre à jour la configuration pour écrire les journaux de politique réseau.
1. Ouvrez le `aws-node` `DaemonSet` dans votre éditeur.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Remplacez `false` par `true` dans l’argument de commande `--enable-policy-event-logs=false` pour le `args:` du conteneur `aws-network-policy-agent` dans le manifeste CNI VPC `aws-node` `DaemonSet`.
```
- args:
- --enable-policy-event-logs=true
```
### Envoyer des journaux de politique réseau à Amazon CloudWatch Logs
Vous pouvez surveiller les journaux de politique réseau à l'aide de services tels qu'Amazon CloudWatch Logs. Vous pouvez utiliser les méthodes suivantes pour envoyer les journaux de politique réseau à CloudWatch Logs.
Pour les clusters EKS, les journaux de politique seront situés sous `/aws/eks/cluster-name/cluster/` et pour les clusters K8S autogérés, les journaux seront placés sous `/aws/k8s-cluster/cluster/`.
#### Envoyer les journaux de politique réseau avec le plug-in CNI Amazon VPC pour Kubernetes
Si vous activez la stratégie réseau, un deuxième conteneur est ajouté aux pods du `aws-node` pour un*agent de nœud*. Cet agent de nœud peut envoyer les journaux de politique réseau à CloudWatch Logs.
**Note**
Seuls les journaux de stratégie réseau sont envoyés par l'agent de nœud. Les autres journaux créés par le CNI Amazon VPC ne sont pas inclus.
##### Conditions préalables
+ Ajoutez les autorisations suivantes sous forme de strophe ou de stratégie distincte au rôle IAM que vous utilisez pour le VPC CNI.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
```
##### Module complémentaire d'Amazon EKS
** AWS Management Console **
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dans le panneau de navigation de gauche, sélectionnez **Clusters**, puis sélectionnez le nom du cluster pour lequel vous souhaitez configurer le module complémentaire Amazon VPC CNI.
1. Choisissez l’onglet **Modules complémentaires**.
1. Cochez la case en haut à droite de la zone du module complémentaire, puis sélectionnez **Edit** (Modifier).
1. Sur la page **Configurer *Amazon VPC CNI*** :
1. Sélectionnez une version `v1.14.0-eksbuild.3` ou ultérieure dans la liste déroulante **Version**.
1. Sélectionnez **Paramètres de configuration facultatifs**.
1. Saisissez la clé JSON de niveau supérieur de l'`"nodeAgent":` et la valeur est un objet avec une clé `"enableCloudWatchLogs":` et une valeur de `"true"` dans**Valeurs de configuration**. Le texte obtenu doit être un objet JSON valide. L'exemple suivant montre la politique réseau, les journaux de stratégie réseau sont activés et les journaux sont envoyés à CloudWatch Logs :
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"enablePolicyEventLogs": "true",
"enableCloudWatchLogs": "true",
}
}
```
La capture d'écran suivante montre un exemple de ce scénario.
![\[montrant le module complémentaire VPC CNI avec la politique réseau et les CloudWatch journaux dans la configuration optionnelle.\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/console-cni-config-network-policy-logs-cwl.png)
** AWS CLI**
1. Exécutez la commande AWS CLI suivante. Remplacez `my-cluster` par le nom de votre cluster et l'ARN du rôle IAM par le rôle que vous utilisez.
```
aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
--service-account-role-arn arn:aws: iam::123456789012:role/AmazonEKSVPCCNIRole \
--resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true", "enableCloudWatchLogs": "true"}}'
```
##### Module complémentaire autogéré
**Casque**
Si vous avez installé le plug-in Amazon VPC CNI pour Kubernetes via`helm`, vous pouvez mettre à jour la configuration pour envoyer les journaux de politique réseau à Logs. CloudWatch
1. Exécutez la commande suivante pour activer les journaux de politique réseau et les envoyer à CloudWatch Logs.
```
helm upgrade --set nodeAgent.enablePolicyEventLogs=true --set nodeAgent.enableCloudWatchLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
**kubectl**
1. Ouvrez le `aws-node` `DaemonSet` dans votre éditeur.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Remplacez `false` par `true` dans les deux arguments de commande `--enable-policy-event-logs=false` et `--enable-cloudwatch-logs=false` dans `args:` dans le conteneur `aws-network-policy-agent` du manifeste `aws-node` `DaemonSet` de VPC CNI.
```
- args:
- --enable-policy-event-logs=true
- --enable-cloudwatch-logs=true
```
#### Envoyer les journaux de politique réseau avec un `DaemonSet` Fluent Bit
Si vous utilisez Fluent Bit dans un `DaemonSet` pour envoyer des journaux depuis vos nœuds, vous pouvez ajouter une configuration pour inclure les journaux de politique réseau provenant des politiques réseau. Vous pouvez utiliser l'exemple de configuration suivant :
```
[INPUT]
Name tail
Tag eksnp.*
Path /var/log/aws-routed-eni/network-policy-agent*.log
Parser json
DB /var/log/aws-routed-eni/flb_npagent.db
Mem_Buf_Limit 5MB
Skip_Long_Lines On
Refresh_Interval 10
```
## Kit SDK eBPF inclus
Le plug-in CNI Amazon VPC pour Kubernetes installe la collection d’outils du kit SDK eBPF sur les nœuds. Vous pouvez utiliser les outils du kit SDK eBPF pour identifier les problèmes liés aux politiques réseau. Par exemple, la commande suivante répertorie les programmes qui s'exécutent sur le nœud.
```
sudo /opt/cni/bin/aws-eks-na-cli ebpf progs
```
Pour exécuter cette commande, vous pouvez utiliser n'importe quelle méthode pour vous connecter au nœud.
## Problèmes connus et solutions
Les sections suivantes décrivent les problèmes connus liés à la fonctionnalité de politique réseau du CNI Amazon VPC et leurs solutions.
### Journaux de politique réseau générés même si la valeur enable-policy-event-logs est définie sur false
**Problème** : le CNI VPC EKS génère des journaux de politique réseau même lorsque le paramètre `enable-policy-event-logs` est défini sur `false`.
**Solution** : le paramètre `enable-policy-event-logs` désactive uniquement les journaux de « décision » de politique, mais il ne désactive pas tous les journaux de l’agent de politique réseau. Ce comportement est documenté dans le [aws-network-policy-agent fichier README](https://github.com/aws/aws-network-policy-agent/) sur GitHub. Pour désactiver complètement la journalisation, vous devrez peut-être ajuster d’autres configurations de journalisation.
### Problèmes liés au nettoyage du mappage des politiques réseau
**Problème** : des problèmes liés au `policyendpoint` réseau persistent et ne sont pas résolus après la suppression des pods.
**Solution** : ce problème était dû à un dysfonctionnement du module complémentaire CNI Amazon VPC version 1.19.3-eksbuild.1. Veuillez mettre à jour le module complémentaire CNI Amazon VPC vers une version plus récente pour résoudre ce problème.
### Les politiques réseau ne sont pas appliquées
**Problème** : la fonctionnalité de politique réseau est activée dans le module complémentaire CNI Amazon VPC, mais les politiques réseau ne sont pas appliquées correctement.
Si vous créez une politique réseau `kind: NetworkPolicy` et qu’elle n’a aucun effet sur le pod, vérifiez que l’objet policyendpoint a été créé dans le même espace de noms que le pod. S’il n’y a pas d’objets `policyendpoint` dans les espaces de noms, le contrôleur de politique réseau (qui fait partie du cluster EKS) n’a pas pu créer de règles de politique réseau à appliquer par l’agent de politique réseau (qui fait partie du VPC CNI).
**Solution** : la solution consiste à corriger les autorisations du CNI VPC (`ClusterRole` : `aws-node`) et du contrôleur de politique réseau (`ClusterRole` : `eks:network-policy-controller`) et à autoriser ces actions dans tout outil d’application de politique tel que Kyverno. Assurez-vous que les politiques Kyverno ne bloquent pas la création d’objets `policyendpoint`. Consultez la section précédente pour connaître les autorisations nécessaires dans [Nouveaux CRD et autorisations `policyendpoints`](#network-policies-troubleshooting-permissions).
### Les pods ne reviennent pas à l’état de refus par défaut après la suppression de la politique en mode strict
**Problème** : lorsque les politiques réseau sont activées en mode strict, les pods démarrent avec une politique de refus par défaut. Une fois les politiques appliquées, le trafic est autorisé vers les points de terminaison spécifiés. Cependant, lorsque les politiques sont supprimées, le pod ne revient pas à l’état de refus par défaut, mais passe à un état d’autorisation par défaut.
**Solution** : ce problème a été corrigé dans la version 1.19.3 du CNI VPC, qui incluait la version 1.2.0 de l’agent de politique réseau. Après la correction, lorsque le mode strict est activé, une fois les politiques supprimées, le pod revient à l’état de refus par défaut comme prévu.
### Latence de démarrage des groupes de sécurité pour les pods
**Problème** : lorsque vous utilisez la fonctionnalité Groupes de sécurité pour les pods dans EKS, la latence de démarrage des pods augmente.
**Solution** : La latence est due à la limitation du débit dans le contrôleur de ressources due à la limitation de l'`CreateNetworkInterface`API, que le contrôleur de ressources VPC utilise pour créer une branche ENIs pour les pods. Veuillez vérifier les limites API de votre compte pour cette opération et envisager de demander une augmentation de la limite si nécessaire.
### FailedScheduling en raison d'une insuffisance de vpc.amazonaws.com/pod-eni
**Problème** : les pods ne parviennent pas à se planifier et l’erreur suivante s’affiche : `FailedScheduling 2m53s (x28 over 137m) default-scheduler 0/5 nodes are available: 5 Insufficient vpc.amazonaws.com/pod-eni. preemption: 0/5 nodes are available: 5 No preemption victims found for incoming pod.`
**Solution** : comme pour le problème précédent, l’attribution de groupes de sécurité aux pods augmente la latence de planification des pods et peut dépasser le seuil CNI pour le temps nécessaire à l’ajout de chaque ENI, ce qui entraîne des échecs au démarrage des pods. Il s’agit d’un comportement normal lorsque vous utilisez des groupes de sécurité pour les pods. Tenez compte des implications en matière de planification lorsque vous concevez l’architecture de votre charge de travail.
### Problèmes de connectivité IPAM et erreurs de segmentation
**Problème** : plusieurs erreurs se produisent, notamment des problèmes de connectivité IPAM, des demandes de limitation et des erreurs de segmentation :
+ `Checking for IPAM connectivity …`
+ `Throttling request took 1.047064274s`
+ `Retrying waiting for IPAM-D`
+ `panic: runtime error: invalid memory address or nil pointer dereference`
**Solution** : Ce problème se produit si vous installez `systemd-udev` le fichier AL2 023, car le fichier est réécrit avec une politique d'interruption. Cela peut se produire lors de la mise à jour vers une autre `releasever` qui dispose d’un package mis à jour ou lors de la mise à jour manuelle du package lui-même. Évitez d'installer ou de mettre à jour `systemd-udev` sur les nœuds AL2 023.
### Erreur : impossible de trouver le dispositif par son nom
**Problème** : message d’erreur : `{"level":"error","ts":"2025-02-05T20:27:18.669Z","caller":"ebpf/bpf_client.go:578","msg":"failed to find device by name eni9ea69618bf0: %!w(netlink.LinkNotFoundError={0xc000115310})"}`
**Solution** : les dernières versions de l’agent de politique réseau CNI Amazon VPC (v1.2.0) identifient et corrigent ce problème. Veuillez mettre à jour vers la dernière version du CNI VPC pour résoudre ce problème.
### Vulnérabilités CVE dans l’image CNI Multus
**Problème** : le rapport EKS ImageScan CVE amélioré identifie des vulnérabilités dans la version v4.1.4-eksbuild.2\$1thick de l'image Multus CNI.
**Solution** : veuillez mettre à jour vers la nouvelle version de l’image CNI Multus et la nouvelle image du contrôleur de politique réseau, qui ne présentent aucune vulnérabilité. Vous pouvez mettre à jour l’analyseur pour corriger les vulnérabilités détectées dans la version précédente.
### Verdicts DENY des informations de flux dans les journaux
**Problème** : les journaux de politique réseau affichent des verdicts DENY : `{"level":"info","ts":"2024-11-25T13:34:24.808Z","logger":"ebpf-client","caller":"events/events.go:193","msg":"Flow Info: ","Src IP":"","Src Port":9096,"Dest IP":"","Dest Port":56830,"Proto":"TCP","Verdict":"DENY"}`
**Solution** : le problème a été résolu dans la nouvelle version du contrôleur de politique réseau. Veuillez mettre à jour vers la dernière version de plateforme EKS pour résoudre les problèmes de journalisation.
### Pod-to-pod problèmes de communication après la migration depuis Calico
**Problème** : Après la mise à niveau d'un cluster EKS vers la version 1.30 et le passage de Calico à Amazon VPC CNI pour la politique réseau, la pod-to-pod communication échoue lorsque les politiques réseau sont appliquées. La communication est rétablie lorsque les politiques réseau sont supprimées.
**Solution** : l’agent de politique réseau dans le CNI VPC ne peut pas avoir autant de ports spécifiés que Calico. Utilisez plutôt des plages de ports dans les politiques réseau. Le nombre maximal de combinaisons uniques de ports pour chaque protocole dans chaque sélecteur `ingress:` ou `egress:` d’une politique réseau est de 24. Utilisez des plages de ports pour réduire le nombre de ports uniques et éviter cette limitation.
### L’agent de politique réseau ne prend pas en charge les pods autonomes
**Problème** : les politiques réseau appliquées à des pods autonomes peuvent avoir un comportement incohérent.
**Solution** : l’agent de politique réseau ne prend actuellement en charge que les pods déployés dans le cadre d’un déploiement/réplicaset. Si des politiques réseau sont appliquées à des pods autonomes, leur comportement peut présenter certaines incohérences. Ceci est documenté en haut de cette page, dans le [Considérations](cni-network-policy.md#cni-network-policy-considerations) numéro et dans le [aws-network-policy-agent GitHub numéro \$1327](https://github.com/aws/aws-network-policy-agent/issues/327) sur GitHub. Déployez les pods dans le cadre d’un déploiement ou d’un réplicaset pour garantir un comportement cohérent des politiques réseau.
# Démonstration des politiques réseau pour Amazon EKS
Cette démonstration permet de créer un service client, un service frontal et un service backend sur votre cluster Amazon EKS. La démonstration crée également une interface utilisateur graphique de gestion qui affiche les chemins d'entrée et de sortie disponibles entre chaque service. Nous vous recommandons d’effectuer la démonstration sur un cluster sur lequel vous n’exécutez pas de charges de travail de production.
Avant de créer des politiques réseau, tous les services peuvent communiquer de façon bidirectionnelle. Une fois que vous avez appliqué les politiques réseau, vous constatez que le client peut uniquement communiquer avec le service frontend et que le service backend n'accepte que le trafic du frontend.
1. Appliquez les services frontal, backend et d'interface utilisateur de gestion :
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml
```
1. Affichez tous les pods du cluster.
```
kubectl get pods -A
```
L'exemple qui suit illustre un résultat.
Dans votre sortie, vous devriez voir des pods dans les espaces de noms affichés dans la sortie suivante. Les *NOMS* de vos pods et le nombre de pods dans la colonne `READY` sont différents de ceux de la sortie suivante. Ne continuez pas tant que vous ne voyez pas des pods avec des noms similaires et que tous ont la mention `Running` dans la colonne `STATUS`.
```
NAMESPACE NAME READY STATUS RESTARTS AGE
[...]
client client-xlffc 1/1 Running 0 5m19s
[...]
management-ui management-ui-qrb2g 1/1 Running 0 5m24s
stars backend-sz87q 1/1 Running 0 5m23s
stars frontend-cscnf 1/1 Running 0 5m21s
[...]
```
1. Pour vous connecter à l'interface utilisateur de gestion, connectez-vous à l'`EXTERNAL-IP` du service qui s'exécute sur votre cluster :
```
kubectl get service/management-ui -n management-ui
```
1. Ouvrez le navigateur à l'emplacement indiqué à l'étape précédente. Vous devez voir l'interface utilisateur de gestion. Le nœud **C** est le service client, le nœud **F** est le service frontal et le nœud **B** est le service backend. Chaque nœud a un accès en communication complet à tous les autres nœuds, comme indiqué par les lignes colorées en gras.
![\[Politique réseau ouvert\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/stars-default.png)
1. Appliquez les stratégies réseau suivantes tant dans les espaces de noms `stars` que `client` pour isoler les services les uns des autres :
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: default-deny
spec:
podSelector:
matchLabels: {}
```
Vous pouvez utiliser les commandes suivantes pour appliquer la stratégie aux deux espaces de noms :
```
kubectl apply -n stars -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml
kubectl apply -n client -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml
```
1. Actualisez votre navigateur. Vous constatez que l’interface utilisateur de gestion ne peut plus atteindre aucun des nœuds, qui n’apparaissent donc pas dans l’interface utilisateur.
1. Appliquez les stratégies réseau différentes suivantes pour permettre à l'interface utilisateur de gestion d'accéder aux services. Appliquez cette stratégie pour autoriser l'interface utilisateur :
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: allow-ui
spec:
podSelector:
matchLabels: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
role: management-ui
```
Appliquez cette stratégie pour autoriser le client :
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: client
name: allow-ui
spec:
podSelector:
matchLabels: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
role: management-ui
```
Vous pouvez utiliser les commandes suivantes pour appliquer les deux stratégies :
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui-client.yaml
```
1. Actualisez votre navigateur. Vous pouvez alors constater que l'interface utilisateur graphique de gestion peut à nouveau atteindre les nœuds, mais que les nœuds ne peuvent pas communiquer entre eux.
![\[Politique réseau d'accès à l'interface utilisateur\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/stars-no-traffic.png)
1. Appliquez la politique réseau suivante pour autoriser le trafic du service frontal au service backend :
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: backend-policy
spec:
podSelector:
matchLabels:
role: backend
ingress:
- from:
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
```
1. Actualisez votre navigateur. Vous voyez que le frontend peut communiquer avec le backend.
![\[Politique frontend vers backend\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/stars-front-end-back-end.png)
1. Appliquez la stratégie réseau suivante pour autoriser le trafic du client vers le service frontend :
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: frontend-policy
spec:
podSelector:
matchLabels:
role: frontend
ingress:
- from:
- namespaceSelector:
matchLabels:
role: client
ports:
- protocol: TCP
port: 80
```
1. Actualisez votre navigateur. Vous voyez que le client peut communiquer avec le service frontend. Le service frontend peut toujours communiquer avec le service backend.
![\[Politique réseau finale\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/stars-final.png)
1. (Facultatif) Une fois que vous avez terminé avec la démonstration, vous pouvez supprimer ses ressources.
```
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml
```
Même après la suppression des ressources, il peut toujours y avoir des points de terminaison de stratégie réseau sur les nœuds qui peuvent interférer de manière inattendue avec la mise en réseau dans votre cluster. La seule façon sûre de supprimer ces règles est de redémarrer les nœuds ou de terminer tous les nœuds et de les recycler. Pour mettre fin à tous les nœuds, définissez le nombre souhaité du groupe Auto Scaling sur 0, puis sauvegardez jusqu'au nombre souhaité, ou terminez simplement les nœuds.
# Déploiement de pods dans des sous-réseaux alternatifs avec réseau personnalisé
**S’applique à** : nœuds Linux `IPv4` Fargate, nœuds Linux avec instances Amazon EC2
![\[Schéma d’un nœud avec plusieurs interfaces réseau\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/cn-image.png)
Par défaut, lorsque le plug-in Amazon VPC CNI pour Kubernetes crée des [interfaces réseau Elastic](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) (interfaces réseau) secondaires pour votre nœud Amazon EC2, il les crée dans le même sous-réseau que l’interface réseau principale du nœud. Il associe également les mêmes groupes de sécurité à l'interface réseau secondaire, qui sont associés à l'interface réseau principale. Pour une ou plusieurs des raisons suivantes, vous voudrez peut-être que le plugin crée des interfaces réseau secondaires dans un sous-réseau différent ou associe différents groupes de sécurité aux interfaces réseau secondaires, ou les deux :
+ Le nombre d’adresses `IPv4` disponibles dans ce sous-réseau est limité, ce qui peut réduire le nombre de pods pouvant être créés dans ce sous-réseau. Cela peut limiter le nombre de pods que vous pouvez créer dans le sous-réseau. En utilisant un sous-réseau différent pour les interfaces réseau secondaires, vous pouvez augmenter le nombre d’adresses `IPv4` disponibles pour les pods.
+ Pour des raisons de sécurité, vos pods doivent utiliser d’autres groupes de sécurité ou sous-réseaux que l’interface réseau principale du nœud.
+ Les nœuds sont configurés dans des sous-réseaux publics et vous souhaitez placer les pods dans des sous-réseaux privés. La table de routage associée à un sous-réseau public comprend une route vers une passerelle Internet. La table de routage associée à un sous-réseau privé ne comprend pas une route vers une passerelle Internet.
**Astuce**
Vous pouvez également ajouter un sous-réseau, nouveau ou existant, directement à votre cluster Amazon EKS sans utiliser le réseau personnalisé. Pour de plus amples informations, consultez [Ajouter un sous-réseau VPC existant à un cluster Amazon EKS à partir de la console de gestion](eks-networking.md#add-existing-subnet).
## Considérations
Tenez compte des points suivants pour utiliser cette fonctionnalité.
+ Avec le réseau personnalisé activé, aucune adresse IP attribuée à l’interface réseau principale n’est attribuée aux pods. Seules les adresses IP provenant des interfaces réseau secondaires sont attribuées aux pods.
+ Si votre cluster utilise la famille `IPv6`, vous ne pouvez pas utiliser le réseau personnalisé.
+ Si vous prévoyez d'utiliser une mise en réseau personnalisée uniquement pour pallier à l'épuisement des adresses `IPv4`, vous pouvez plutôt créer un cluster à l'aide de la famille `IPv6`. Pour de plus amples informations, consultez [En savoir plus sur IPv6 les adresses des clusters, des pods et des services](cni-ipv6.md).
+ Même si les pods déployés dans des sous-réseaux définis pour les interfaces réseau secondaires peuvent utiliser un sous-réseau et des groupes de sécurité différents de ceux de l’interface réseau principale du nœud, ces sous-réseaux et groupes de sécurité doivent se trouver dans le même VPC que le nœud.
+ Pour Fargate, les sous-réseaux sont contrôlés via le profil Fargate. Pour de plus amples informations, consultez [Définissez quels pods utilisent AWS Fargate lors de leur lancement](fargate-profile.md).
# Personnalisation de l’interface réseau secondaire sur les nœuds Amazon EKS
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` Homebrew pour macOS ont souvent plusieurs versions de retard sur la dernière version de la AWS CLI. `apt-get` 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
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
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
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 <$az_2.yaml <
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 maximal de pods recommandé par Amazon EKS pour vos nœuds. Suivez les instructions de la section , en ajoutant `--cni-custom-networking-enabled` à l’étape 3 de ce guide. Notez la sortie pour l'utiliser lors de 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 maximal de pods recommandé par Amazon EKS pour vos nœuds. Suivez les instructions de la section , en ajoutant `--cni-custom-networking-enabled` à l'étape 3 de cette rubrique. Notez la sortie pour l'utiliser lors de 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 de pods nettement plus élevé, exécutez de nouveau le script mentionné dans . Ajoutez également l'option `--cni-prefix-delegation-enabled` à la commande. 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 8m49s v1.22.9-eks-810597c
ip-192-168-0-92.us-west-2.compute.internal Ready 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
kube-system aws-node-k96wp 1/1 Running 0 7m15s 192.168.0.126 ip-192-168-0-126.us-west-2.compute.internal
kube-system coredns-657694c6f4-smcgr 1/1 Running 0 56m 192.168.1.23 ip-192-168-0-92.us-west-2.compute.internal
kube-system coredns-657694c6f4-stwv9 1/1 Running 0 56m 192.168.1.28 ip-192-168-0-92.us-west-2.compute.internal
kube-system kube-proxy-jgshq 1/1 Running 0 7m19s 192.168.0.92 ip-192-168-0-92.us-west-2.compute.internal
kube-system kube-proxy-wx9vk 1/1 Running 0 7m15s 192.168.0.126 ip-192-168-0-126.us-west-2.compute.internal
```
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
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
```
# 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.
# Attribution de groupes de sécurité à des pods individuels
**S'applique à** : nœuds Linux dotés d' EC2 instances Amazon
**S’applique à** : sous-réseaux privés
Les groupes de sécurité pour Pods intègrent les groupes EC2 de sécurité Amazon aux Pods Kubernetes. Vous pouvez utiliser les groupes EC2 de sécurité Amazon pour définir des règles qui autorisent le trafic réseau entrant et sortant vers et depuis les pods que vous déployez vers des nœuds exécutés sur de nombreux types d' EC2 instances Amazon et sur Fargate. Pour une explication détaillée de cette fonctionnalité, consultez l’article de blog [Introducing security groups for Pods](https://aws.amazon.com/blogs/containers/introducing-security-groups-for-pods).
## Compatibilité avec les fonctionnalités du module complémentaire plug-in Amazon VPC CNI pour Kubernetes
Vous pouvez utiliser les groupes de sécurité pour les pods avec les fonctionnalités suivantes :
+ IPv4 Traduction de l'adresse réseau source - Pour plus d'informations, consultez[Activer l’accès Internet sortant pour les Pods](external-snat.md).
+ IPv6 adresses vers les clusters, les pods et les 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).
## Considérations
Avant de déployer des groupes de sécurité pour les pods, veuillez tenir compte des limitations et conditions suivantes :
+ Les groupes de sécurité pour les pods ne peuvent pas être utilisés avec les nœuds Windows ou le mode automatique EKS.
+ Les groupes de sécurité pour Pods peuvent être utilisés avec des clusters configurés pour la `IPv6` famille contenant des EC2 nœuds Amazon à l'aide de la version 1.16.0 ou ultérieure du plugin Amazon VPC CNI. Vous pouvez utiliser des groupes de sécurité pour les pods avec des clusters configurés pour la famille `IPv6` qui contiennent uniquement des nœuds Fargate à l’aide de la version 1.7.7 ou ultérieure du plug-in CNI Amazon VPC. Pour de plus amples informations, consultez [En savoir plus sur IPv6 les adresses des clusters, des pods et des services](cni-ipv6.md).
+ Les groupes de sécurité pour Pods sont pris en charge par la plupart des familles d' EC2 instances Amazon [basées sur Nitro](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances), mais pas par toutes les générations d'une famille. Par exemple, les familles et générations d’instances `m5`, `c5`, `r5`, `m6g`, `c6g` et `r6g` sont prises en charge. Aucun type d'instance de la famille `t` n'est pris en charge. Pour obtenir la liste complète des types d'instances pris en charge, consultez le fichier [limits.go sur.](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/v1.5.0/pkg/aws/vpc/limits.go) GitHub Vos nœuds doivent être l'un des types d'instance répertoriés qui ont `IsTrunkingCompatible: true` dans ce fichier.
+ Si vous utilisez conjointement un réseau personnalisé et des groupes de sécurité pour les pods, le groupe de sécurité spécifié par les groupes de sécurité pour les pods est utilisé à la place du groupe de sécurité spécifié dans `ENIConfig`.
+ Si vous utilisez la version `1.10.2` ou antérieure du plug-in CNI Amazon VPC et que vous incluez le paramètre `terminationGracePeriodSeconds` dans votre spécification de pod, la valeur de ce paramètre ne peut pas être zéro.
+ Si vous utilisez la version `1.10` ou antérieure du plug-in CNI Amazon VPC, ou la version `1.11` avec `POD_SECURITY_GROUP_ENFORCING_MODE`=`strict`, qui est le paramètre par défaut, les services Kubernetes de type `NodePort` et `LoadBalancer` utilisant des cibles d’instance avec une `externalTrafficPolicy` définie sur `Local` ne sont pas pris en charge avec les pods auxquels vous attribuez des groupes de sécurité. Pour plus d'informations sur l'utilisation d'un équilibreur de charge avec des cibles d'instance, consultez [Acheminer le trafic TCP et UDP avec des Network Load Balancers](network-load-balancing.md).
+ Si vous utilisez la version `1.10` ou antérieure du plug-in CNI Amazon VPC ou la version `1.11` avec `POD_SECURITY_GROUP_ENFORCING_MODE`=`strict`, qui est le paramètre par défaut, le NAT source est désactivé pour le trafic sortant des pods auxquels des groupes de sécurité sont attribués, afin que les règles de groupe de sécurité sortantes soient appliquées. Pour accéder à Internet, les pods auxquels des groupes de sécurité sont attribués doivent être lancés sur des nœuds déployés dans un sous-réseau privé configuré avec une passerelle ou une instance NAT. Les pods avec des groupes de sécurité affectés déployés sur des sous-réseaux publics ne sont pas en mesure d'accéder à Internet.
Si vous utilisez la version `1.11` ou ultérieure du plug-in avec `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard`, le trafic des pods destiné à l’extérieur du VPC est traduit en adresse IP de l’interface réseau principale de l’instance. Pour ce trafic, les règles des groupes de sécurité de l’interface réseau principale sont utilisées, plutôt que celles des groupes de sécurité des pods.
+ Pour utiliser la politique réseau Calico avec des pods associés à des groupes de sécurité, vous devez utiliser la version `1.11.0` ou ultérieure du plug-in CNI Amazon VPC et définir `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard`. Dans le cas contraire, le flux de trafic à destination et en provenance des pods associés aux groupes de sécurité n'est pas soumis à l'application de la politique réseau de Calico et est limité à l'application des groupes EC2 de sécurité Amazon uniquement. Pour mettre à jour la version de votre plug-in CNI Amazon VPC, consultez [Attribuer IPs à des pods avec l'Amazon VPC CNI](managing-vpc-cni.md)
+ Les pods exécutés sur des EC2 nœuds Amazon qui utilisent des groupes de sécurité dans des clusters qui [NodeLocal DNSCache](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/)les utilisent ne sont pris en charge qu'avec la version `1.11.0` ou une version ultérieure du plugin Amazon VPC CNI et avec =. `POD_SECURITY_GROUP_ENFORCING_MODE` `standard` Pour mettre à jour la version de votre plug-in CNI Amazon VPC, consultez [Attribuer IPs à des pods avec l'Amazon VPC CNI](managing-vpc-cni.md)
+ Les groupes de sécurité pour les pods peuvent entraîner une latence de start-up plus élevée pour les pods à forte rotation. Cela est dû à la limitation du débit dans le contrôleur de ressources.
+ L'étendue du groupe EC2 de sécurité est au niveau du POD. Pour plus d'informations, consultez la section Groupe [de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html).
Si vous définissez `POD_SECURITY_GROUP_ENFORCING_MODE=standard` et `AWS_VPC_K8S_CNI_EXTERNALSNAT=false`, le trafic destiné aux points de terminaison en dehors du VPC utilise les groupes de sécurité du nœud, et non ceux du pod.
# Configurez le plug-in CNI Amazon VPC pour Kubernetes pour les groupes de sécurité des pods Amazon EKS
Si vous utilisez des pods avec des instances Amazon EC2, vous devez configurer le plug-in CNI Amazon VPC pour Kubernetes pour les groupes de sécurité
Si vous utilisez uniquement des pods Fargate et que vous n’avez aucun nœud Amazon EC2 dans votre cluster, consultez [Utiliser une politique de groupe de sécurité pour un pod Amazon EKS](sg-pods-example-deployment.md).
1. Vérifiez la version actuelle de votre plug-in CNI Amazon VPC pour Kubernetes à l’aide de la commande suivante :
```
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
```
L'exemple qui suit illustre un résultat.
```
v1.7.6
```
Si la version de votre plug-in CNI Amazon VPC pour Kubernetes est antérieure à `1.7.7`, veuillez mettre à jour le plug-in vers la version `1.7.7` ou une version ultérieure. Pour plus d’informations, consultez [Attribuer IPs à des pods avec l'Amazon VPC CNI](managing-vpc-cni.md).
1. Ajoutez la politique IAM gérée [AmazonEKSVPCResourceController](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonEKSVPCResourceController) au [rôle de cluster](cluster-iam-role.md#create-service-role) associé à votre cluster Amazon EKS. La politique permet au rôle de gérer les interfaces réseau, leurs adresses IP privées, leur attachement et leur détachement vers et depuis les instances réseau.
1. Récupérez le nom de votre rôle IAM de cluster et stockez-le dans une variable. Remplacez *my-cluster* par le nom de votre cluster.
```
cluster_role=$(aws eks describe-cluster --name my-cluster --query cluster.roleArn --output text | cut -d / -f 2)
```
1. Attachez la stratégie au rôle.
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController --role-name $cluster_role
```
1. Activez le module complémentaire CNI Amazon VPC pour gérer les interfaces réseau des pods en définissant la variable `ENABLE_POD_ENI` sur `true` dans le DaemonSet `aws-node`. Une fois ce paramètre défini sur `true`, le module complémentaire crée une ressource personnalisée `cninode` pour chaque nœud du cluster. Le contrôleur de ressources VPC crée et attache une interface réseau spéciale appelée *interface réseau de tronc* avec la description `aws-k8s-trunk-eni`.
```
kubectl set env daemonset aws-node -n kube-system ENABLE_POD_ENI=true
```
**Note**
L'interface réseau de tronc est incluse dans le nombre maximal d'interfaces réseau prises en charge par le type d'instance. Pour obtenir la liste du nombre maximal d’interfaces réseau prises en charge par chaque type d’instance, consultez [Adresses IP par interface réseau par type d’instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI) dans le *Guide de l’utilisateur Amazon EC2*. Si votre nœud a déjà le nombre maximal d'interfaces réseau standard qui lui sont attachées, le contrôleur de ressources VPC réservera un espace. Vous devrez réduire verticalement vos pods en cours d’exécution suffisamment pour que le contrôleur puisse détacher et supprimer une interface réseau standard, créer l’interface réseau trunk et la connecter à l’instance.
1. Vous pouvez voir quels nœuds ont une ressource personnalisée `CNINode` avec la commande suivante. Si le message `No resources found` est renvoyé, attendez plusieurs secondes et réessayez. L’étape précédente nécessite de redémarrer le plug-in CNI Amazon VPC pour les pods Kubernetes, ce qui prend plusieurs secondes.
```
kubectl get cninode -A
NAME FEATURES
ip-192-168-64-141.us-west-2.compute.internal [{"name":"SecurityGroupsForPods"}]
ip-192-168-7-203.us-west-2.compute.internal [{"name":"SecurityGroupsForPods"}]
```
Si vous utilisez des versions CNI VPC antérieures à `1.15`, les étiquettes de nœud ont été utilisées à la place de la ressource personnalisée `CNINode`. Vous pouvez voir quels nœuds ont le label de nœud `aws-k8s-trunk-eni` défini sur `true` à l’aide de la commande suivante. Si le message `No resources found` est renvoyé, attendez plusieurs secondes et réessayez. L’étape précédente nécessite de redémarrer le plug-in CNI Amazon VPC pour les pods Kubernetes, ce qui prend plusieurs secondes.
```
kubectl get nodes -o wide -l vpc.amazonaws.com/has-trunk-attached=true
```
Une fois l’interface réseau trunk créée, les pods se voient attribuer des adresses IP secondaires à partir des interfaces réseau trunk ou standard. L'interface de tronc est automatiquement supprimée si le nœud est supprimé.
Lorsque vous déployez un groupe de sécurité pour un pod dans une étape ultérieure, le contrôleur de ressources VPC crée une interface réseau spéciale appelée *interface réseau de branche* avec une description `aws-k8s-branch-eni` et y associe les groupes de sécurité. Les interfaces réseau de branche sont créées en plus des interfaces réseau standard et de tronc attachées au nœud.
Si vous utilisez des sondes de vivacité ou de disponibilité, vous devez également désactiver *TCP early demux*, afin que le `kubelet` puisse se connecter aux pods sur les interfaces réseau de branche à l’aide de TCP. Pour désactiver le *TCP early demux*, exécutez la commande suivante :
```
kubectl patch daemonset aws-node -n kube-system \
-p '{"spec": {"template": {"spec": {"initContainers": [{"env":[{"name":"DISABLE_TCP_EARLY_DEMUX","value":"true"}],"name":"aws-vpc-cni-init"}]}}}}'
```
**Note**
Si vous utilisez la version `1.11.0` ou ultérieure du plug-in CNI Amazon VPC pour le module complémentaire Kubernetes et que vous définissez `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard`, comme décrit à l’étape suivante, vous n’avez pas besoin d’exécuter la commande précédente.
1. Si votre cluster utilise `NodeLocal DNSCache`, ou si vous voulez utiliser la politique réseau Calico avec vos pods qui ont leurs propres groupes de sécurité, ou si vous disposez de services Kubernetes de type `NodePort` et `LoadBalancer` utilisant des cibles d’instance avec une `externalTrafficPolicy` définie sur `Local` pour les pods que vous voulez attribuer des groupes de sécurité, vous devez utiliser la version `1.11.0` ou ultérieure du module complémentaire Plug-in CNI Amazon VPC pour Kubernetes et activer le paramètre suivant :
```
kubectl set env daemonset aws-node -n kube-system POD_SECURITY_GROUP_ENFORCING_MODE=standard
```
IMPORTANT : ** Les règles de groupe de sécurité des pods ne s’appliquent pas au trafic entre les pods ou entre les pods et les services, tels que `kubelet` ou `nodeLocalDNS`, qui se trouvent sur le même nœud. Les pods utilisant différents groupes de sécurité sur le même nœud ne peuvent pas communiquer car ils sont configurés dans des sous-réseaux différents et le routage est désactivé entre ces sous-réseaux.** Le trafic sortant des pods vers des adresses en dehors du VPC est soumis à une traduction d’adresses réseau vers l’adresse IP de l’interface réseau principale de l’instance (sauf si vous avez également défini `AWS_VPC_K8S_CNI_EXTERNALSNAT=true`). Pour ce trafic, les règles des groupes de sécurité de l’interface réseau principale sont utilisées, plutôt que celles des groupes de sécurité des pods. \$1\$1 Pour que ce paramètre s’applique aux pods existants, vous devez redémarrer les pods ou les nœuds sur lesquels les pods s’exécutent.
1. Pour savoir comment utiliser une stratégie de groupe de sécurité pour votre pod, consultez [Utiliser une politique de groupe de sécurité pour un pod Amazon EKS](sg-pods-example-deployment.md).
# Utiliser une politique de groupe de sécurité pour un pod Amazon EKS
Pour utiliser des groupes de sécurité pour les pods, vous devez disposer d’un groupe de sécurité existant. Les étapes suivantes vous montrent comment utiliser la politique de groupe de sécurité pour un pod. Sauf indication contraire, effectuez toutes les étapes à partir du même terminal, car les étapes suivantes utilisent des variables qui ne persistent pas d’un terminal à l’autre.
Si vous disposez d’un pod avec des instances Amazon EC2, vous devez configurer le plug-in avant d’utiliser cette procédure. Pour de plus amples informations, veuillez consulter [Configurez le plug-in CNI Amazon VPC pour Kubernetes pour les groupes de sécurité des pods Amazon EKS](security-groups-pods-deployment.md).
1. Créez un espace de noms Kubernetes vers lequel déployer les ressources . Vous pouvez le *my-namespace* remplacer par le nom de l'espace de noms que vous souhaitez utiliser.
```
kubectl create namespace my-namespace
```
1. Déployez une politique `SecurityGroupPolicy` Amazon EKS sur votre cluster.
1. Copiez les contenus suivants sur votre appareil. Vous pouvez les *podSelector* remplacer par `serviceAccountSelector` si vous préférez sélectionner des pods en fonction des étiquettes des comptes de service. Vous devez spécifier un sélecteur ou l'autre. Un `podSelector` vide (exemple : `podSelector: {}`) sélectionne tous les pods de l’espace de noms. Vous pouvez *my-role* modifier le nom de votre rôle. Un `serviceAccountSelector` vide sélectionne tous les comptes de service dans l'espace de noms. Vous pouvez le *my-security-group-policy* remplacer par un nom pour votre nom `SecurityGroupPolicy` et *my-namespace* par l'espace de noms `SecurityGroupPolicy` dans lequel vous souhaitez le créer.
Vous devez le *my\$1pod\$1security\$1group\$1id* remplacer par l'ID d'un groupe de sécurité existant. Si vous ne disposez pas d’un groupe de sécurité existant, vous devez en créer un. Pour plus d'informations, veuillez consulter la section [Amazon EC2 security groups for Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) (français non garanti) dans le [Guide de l'utilisateur Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/). Vous pouvez spécifier un groupe IDs de sécurité de 1 à 5. Si vous spécifiez plusieurs ID, la combinaison de toutes les règles de tous les groupes de sécurité s’applique aux pods sélectionnés.
```
cat >my-security-group-policy.yaml <sample-application.yaml <
my-deployment-5df6f7687b-j9fl4 1/1 Running 0 7m51s 192.168.70.145 ip-192-168-92-33.region-code.compute.internal
my-deployment-5df6f7687b-rjxcz 1/1 Running 0 7m51s 192.168.73.207 ip-192-168-92-33.region-code.compute.internal
my-deployment-5df6f7687b-zmb42 1/1 Running 0 7m51s 192.168.63.27 ip-192-168-33-28.region-code.compute.internal
```
**Note**
Suivez ces conseils si des pods sont bloqués.
Si des pods sont bloqués dans l’état `Waiting`, exécutez `kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace `. Si vous voyez `Insufficient permissions: Unable to create Elastic Network Interface.`, vérifiez que vous avez ajouté la politique IAM au rôle de cluster IAM dans une étape précédente.
Si des pods sont bloqués dans l’état `Pending`, vérifiez que votre type d’instance de nœud est répertorié dans [limits.go](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/pkg/aws/vpc/limits.go) et que le produit du nombre maximal d’interfaces réseau de branche prises en charge par le type d’instance multiplié par le nombre de nœuds dans votre groupe de nœuds n’a pas déjà été atteint. Par exemple, une instance `m5.large` prend en charge neuf interfaces réseau de branche. Si votre groupe de nœuds comporte cinq nœuds, un maximum de 45 interfaces réseau de branche peut être créé pour le groupe de nœuds. Le 46e pod que vous essayez de déployer restera dans l’état `Pending` jusqu’à ce qu’un autre pod associé à des groupes de sécurité soit supprimé.
Si vous exécutez `kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace ` et recevez un message similaire au message suivant, il peut être ignoré en toute sécurité. Ce message peut apparaître lorsque le plug-in CNI Amazon VPC pour Kubernetes tente de configurer le réseau hôte et échoue pendant la création de l’interface réseau. Le plugin journalise cet événement jusqu'à ce que l'interface réseau soit créée.
```
Failed to create Pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "e24268322e55c8185721f52df6493684f6c2c3bf4fd59c9c121fd4cdc894579f" network for Pod "my-deployment-5df6f7687b-4fbjm": networkPlugin
cni failed to set up Pod "my-deployment-5df6f7687b-4fbjm-c89wx_my-namespace" network: add cmd: failed to assign an IP address to container
```
Vous ne pouvez pas dépasser le nombre maximal de pods pouvant être exécutés sur le type d’instance. Pour obtenir la liste du nombre maximal de pods que vous pouvez exécuter sur chaque type d'instance, consultez [eni-max-pods.txt](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/misc/eni-max-pods.txt) on GitHub. Lorsque vous supprimez un pod associé à des groupes de sécurité ou que vous supprimez le nœud sur lequel le pod est exécuté, le contrôleur de ressources VPC supprime l’interface réseau de la branche. Si vous supprimez un cluster avec des pods utilisant des pods pour les groupes de sécurité, le contrôleur ne supprime pas les interfaces réseau de la branche. Vous devrez donc les supprimer vous-même. Pour plus d’informations sur la suppression des interfaces réseau, consultez [Supprimer une interface réseau](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#delete_eni) dans le Guide de l’utilisateur Amazon EC2.
1. Dans un terminal séparé, connectez-vous à l’un des pods. Pour le reste de ce sujet, ce terminal est appelé `TerminalB`. *5df6f7687b-4fbjm*Remplacez-le par l'ID de l'un des pods renvoyés dans votre sortie de l'étape précédente.
```
kubectl exec -it -n my-namespace my-deployment-5df6f7687b-4fbjm -- /bin/bash
```
1. À partir du shell dans `TerminalB`, confirmez que l'exemple d'application fonctionne.
```
curl my-app
```
L'exemple qui suit illustre un résultat.
```
Welcome to nginx!
[...]
```
Vous avez reçu cette sortie car tous les pods exécutant l’application sont associés au groupe de sécurité que vous avez créé. Ce groupe contient une règle qui autorise tout le trafic entre tous les pods associés au groupe de sécurité. Le trafic DNS est autorisé à partir de ce groupe de sécurité vers le groupe de sécurité du cluster associé à vos nœuds. Les nœuds exécutent les pods CoreDNS, vers lesquels vos pods ont effectué une recherche de nom.
1. À partir du `TerminalA`, supprimez les règles de groupe de sécurité qui autorisent la communication DNS au groupe de sécurité du cluster de votre groupe de sécurité. Si vous n'avez pas ajouté les règles DNS au groupe de sécurité du cluster lors d'une étape précédente, *\$1my\$1cluster\$1security\$1group\$1id* remplacez-les par l'ID du groupe de sécurité dans lequel vous avez créé les règles.
```
aws ec2 revoke-security-group-ingress --group-id $my_cluster_security_group_id --security-group-rule-ids $my_tcp_rule_id
aws ec2 revoke-security-group-ingress --group-id $my_cluster_security_group_id --security-group-rule-ids $my_udp_rule_id
```
1. À partir du `TerminalB`, essayez de nouveau d'accéder à l'application.
```
curl my-app
```
L'exemple qui suit illustre un résultat.
```
curl: (6) Could not resolve host: my-app
```
La tentative échoue car le pod ne peut plus accéder aux pods CoreDNS, qui sont associés au groupe de sécurité du cluster. Le groupe de sécurité du cluster ne dispose plus des règles de groupe de sécurité qui autorisent la communication DNS à partir du groupe de sécurité associé à votre pod.
Si vous essayez d’accéder à l’application à l’aide des adresses IP renvoyées pour l’un des pods lors d’une étape précédente, vous recevez toujours une réponse, car tous les ports sont autorisés entre les pods associés au groupe de sécurité et aucune recherche de nom n’est requise.
1. Une fois votre expérience terminée, vous pouvez supprimer l’exemple de politique de groupe de sécurité, l’application et le groupe de sécurité que vous avez créés. Exécutez les commandes suivantes à partir du `TerminalA`.
```
kubectl delete namespace my-namespace
aws ec2 revoke-security-group-ingress --group-id $my_pod_security_group_id --security-group-rule-ids $my_inbound_self_rule_id
wait
sleep 45s
aws ec2 delete-security-group --group-id $my_pod_security_group_id
```
# Connecter plusieurs interfaces réseau à des pods
Par défaut, le plug-in CNI Amazon VPC attribue une adresse IP à chaque pod. Cette adresse IP est associée à une *interface réseau Elastic* qui gère tout le trafic entrant et sortant du pod. Pour augmenter la bande passante et le débit de paquets par seconde, vous pouvez utiliser la *fonctionnalité multi-NIC* de CNI VPC pour configurer un pod multi-homed. Un pod multi-homed est un pod Kubernetes unique qui utilise plusieurs interfaces réseau (et plusieurs adresses IP). En exécutant un pod multi-homed, vous pouvez répartir le trafic de son application sur plusieurs interfaces réseau à l’aide de connexions simultanées. Cela est particulièrement utile pour les cas d’utilisation de l’intelligence artificielle (IA), de machine learning (ML) et du calcul haute performance (HPC).
Le schéma suivant montre un module multi-hébergement exécuté sur un nœud de travail avec plusieurs cartes d'interface réseau (NICs) utilisées.
![\[Un pod multi-homed avec deux interfaces réseau connectées : une interface réseau avec ENA et une interface réseau avec ENA et EFA\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/multi-homed-pod.png)
## Contexte
Sur Amazon EC2, une *interface réseau élastique* est un composant réseau logique d'un VPC qui représente une carte réseau virtuelle. Pour de nombreux types d' EC2 instances, les interfaces réseau partagent une seule carte d'interface réseau (NIC) matérielle. Cette carte réseau unique dispose d’une bande passante maximale et d’un débit maximal de paquets par seconde.
Si la fonctionnalité multi-NIC est activée, le CNI VPC n’attribue pas d’adresses IP en masse, comme il le fait par défaut. Au lieu de cela, le CNI VPC attribue une adresse IP à une interface réseau sur chaque carte réseau à la demande lorsqu’un nouveau pod démarre. Ce comportement réduit le taux d’épuisement des adresses IP, qui est augmenté par l’utilisation de pods multi-homed. Étant donné que le CNI VPC attribue des adresses IP à la demande, le démarrage des pods peut prendre plus de temps sur les instances où la fonctionnalité multi-NIC est activée.
## Considérations
+ Veuillez vous assurer que votre cluster Kubernetes exécute la version `1.20.0` ou ultérieure du CNI VPC. La fonctionnalité multi-NIC n’est disponible que dans la version `1.20.0` ou ultérieure du CNI VPC.
+ Activez la variable d’environnement `ENABLE_MULTI_NIC` dans le plug-in CNI Amazon VPC. Vous pouvez exécuter la commande suivante pour définir la variable et démarrer le déploiement du DaemonSet.
+ `kubectl set env daemonset aws-node -n kube-system ENABLE_MULTI_NIC=true`
+ Assurez-vous de créer des nœuds de travail dotés de plusieurs cartes d'interface réseau (NICs). Pour obtenir la liste des EC2 instances dotées de plusieurs cartes d'interface réseau, consultez la section [Cartes réseau](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#network-cards) du **guide de EC2 l'utilisateur Amazon**.
+ Si la fonctionnalité multi-NIC est activée, le CNI VPC n’attribue pas d’adresses IP en masse, comme il le fait par défaut. Étant donné que le CNI VPC attribue des adresses IP à la demande, le démarrage des pods peut prendre plus de temps sur les instances où la fonctionnalité multi-NIC est activée. Pour de plus amples informations, veuillez consulter la section précédente [Contexte](#pod-multi-nic-background).
+ Lorsque la fonctionnalité multi-NIC est activée, les pods ne disposent pas de plusieurs interfaces réseau par défaut. Vous devez configurer chaque charge de travail pour utiliser la fonctionnalité multi-NIC. Ajoutez l’annotation `k8s.amazonaws.com/nicConfig: multi-nic-attachment` aux charges de travail qui doivent disposer de plusieurs interfaces réseau.
### Considérations relatives à `IPv6`
+ **Politique IAM personnalisée** : pour les clusters `IPv6`, créez et utilisez la politique IAM personnalisée suivante pour le CNI VPC. Cette politique est spécifique à la fonctionnalité multi-NIC. Pour plus d’informations générales sur l’utilisation du CNI VPC avec les clusters `IPv6`, consultez [En savoir plus sur IPv6 les adresses des clusters, des pods et des services](cni-ipv6.md).
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AmazonEKSCNIPolicyIPv6MultiNIC",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DescribeInstances",
"ec2:AssignIpv6Addresses",
"ec2:DetachNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeTags",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:DeleteNetworkInterface",
"ec2:DescribeInstanceTypes",
"ec2:UnassignIpv6Addresses",
"ec2:AttachNetworkInterface",
"ec2:DescribeSubnets"
],
"Resource": "*"
},
{
"Sid": "AmazonEKSCNIPolicyENITagIPv6MultiNIC",
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:*:*:network-interface/*"
}
]
}
```
+ **Mécanisme de transition `IPv6` non disponible** : si vous utilisez la fonctionnalité multi-NIC, le CNI VPC n’attribue pas d’adresse `IPv4` aux pods d’un cluster `IPv6`. Sinon, le CNI Amazon VPC attribue une adresse `IPv4` locale à chaque pod afin que celui-ci puisse communiquer avec des ressources `IPv4` externes dans un autre Amazon VPC ou sur Internet.
## Usage
Une fois la fonctionnalité multi-NIC activée dans le CNI Amazon VPC et les pods `aws-node` redémarrés, vous pouvez configurer chaque charge de travail pour qu’elle soit multi-homed. Voici un exemple de configuration YAML avec l’annotation requise :
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders-deployment
namespace: ecommerce
labels:
app: orders
spec:
replicas: 3
selector:
matchLabels:
app: orders
template:
metadata:
annotations:
k8s.amazonaws.com/nicConfig: multi-nic-attachment
labels:
app: orders
spec:
...
```
## Questions fréquentes (FAQ)
### **1. Qu’est-ce qu’une carte d’interface réseau (NIC) ?**
Une carte d’interface réseau (NIC), également appelée simplement carte réseau, est un périphérique physique qui permet la connectivité réseau pour le matériel informatique cloud sous-jacent. Dans EC2 les serveurs modernes, cela fait référence à la carte réseau Nitro. Une interface réseau Elastic (ENI) est une représentation virtuelle de cette carte réseau sous-jacente.
Certains types d' EC2 instances en ont plusieurs NICs pour améliorer les performances en termes de bande passante et de débit de paquets. Dans de tels cas, vous pouvez attribuer des cartes réseau secondaires ENIs aux cartes réseau supplémentaires. Par exemple, l’ENI n° 1 peut fonctionner comme interface pour la carte NIC connectée à l’index de carte réseau 0, tandis que l’ENI n° 2 peut fonctionner comme interface pour la carte NIC connectée à un index de carte réseau distinct.
### **2. Qu’est-ce qu’un pod multi-homed ?**
Un pod multi-homed est un pod Kubernetes unique doté de plusieurs interfaces réseau (et donc de plusieurs adresses IP). Chaque interface réseau du pod est associée à une [interface réseau élastique (ENI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html), et il s' ENIs agit de représentations logiques distinctes NICs sur le nœud de travail sous-jacent. Grâce à ses multiples interfaces réseau, un pod multi-homed dispose d’une capacité de transfert de données supplémentaire, ce qui augmente également son débit de transfert de données.
**Important**
Le VPC CNI peut uniquement configurer des pods multi-hôtes sur des types d'instances qui en ont plusieurs. NICs
### **3. Pourquoi utiliser cette fonctionnalité ?**
Si vous devez adapter les performances réseau de vos charges de travail basées sur Kubernetes, vous pouvez utiliser la fonctionnalité multi-cartes réseau pour exécuter des pods multi-hôtes qui s'interfacent avec tous les composants sous-jacents NICs auxquels un périphérique ENA est connecté. L’utilisation de cartes réseau supplémentaires augmente la capacité de bande passante et les performances en termes de débit de paquets dans vos applications en répartissant le trafic des applications sur plusieurs connexions simultanées. Cela est particulièrement utile pour les cas d’utilisation de l’intelligence artificielle (IA), de machine learning (ML) et du calcul haute performance (HPC).
### **4. Comment utiliser cette fonctionnalité ?**
1. Tout d’abord, vous devez vous assurer que votre cluster Kubernetes utilise la version 1.20 ou ultérieure de CNI VPC. Pour connaître les étapes de mise à jour de CNI VPC en tant que module complémentaire EKS, consultez [Mettre à jour le CNI Amazon VPC (module complémentaire Amazon EKS)](vpc-add-on-update.md).
1. Ensuite, vous devez activer la prise en charge multi-NIC dans le CNI Amazon VPC à l’aide de la variable d’environnement `ENABLE_MULTI_NIC`.
1. Enfin, vous devez vous assurer de créer et de rejoindre des nœuds disposant de plusieurs cartes réseau. Pour obtenir la liste des types d' EC2 instances dotés de plusieurs cartes réseau, consultez la section [Cartes réseau](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#network-cards) du *guide de EC2 l'utilisateur Amazon*.
1. Enfin, vous devez configurer chaque charge de travail pour qu’elle utilise soit plusieurs interfaces réseau (pods multi-homed), soit une seule interface réseau.
### **5. Comment configurer mes charges de travail pour en utiliser plusieurs NICs sur un nœud de travail pris en charge ?**
Pour utiliser des pods multi-homed, vous devez ajouter l’annotation suivante : `k8s.amazonaws.com/nicConfig: multi-nic-attachment`. Cela associera un ENI de chaque carte réseau de l'instance sous-jacente au pod (un ou plusieurs mappages entre un pod et le NICs).
Si cette annotation est manquante, le CNI VPC suppose que votre pod ne nécessite qu’une seule interface réseau et lui attribue une adresse IP provenant d’une ENI sur n’importe quelle carte réseau disponible.
### **6. Quels adaptateurs d’interface réseau sont pris en charge avec cette fonctionnalité ?**
Vous pouvez utiliser n’importe quel adaptateur d’interface réseau si vous disposez d’au moins un ENA connecté à la carte réseau sous-jacente pour le trafic IP. Pour plus d'informations sur l'ENA, consultez [Elastic Network Adapter (ENA)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html) dans le *guide de EC2 l'utilisateur Amazon*.
Configurations de périphériques réseau prises en charge :
+ les interfaces **ENA** fournissent toutes les fonctionnalités de réseau et de routage IP traditionnelles requises pour prendre en charge le réseau IP d’un VPC. Pour plus d'informations, consultez [Activer la mise en réseau améliorée avec ENA sur vos EC2 instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html).
+ Les interfaces **EFA** **(EFA** **avec ENA)** fournissent à la fois le périphérique ENA pour la mise en réseau IP et le périphérique EFA pour une communication à faible latence et haut débit.
**Important**
Si une carte réseau ne dispose que d’un adaptateur **EFA uniquement** attaché, le CNI VPC l’ignorera lors de la fourniture d’une connectivité réseau pour un pod multi-hébergé. Toutefois, si vous combinez un adaptateur **EFA uniquement** avec un adaptateur **ENA** sur une carte réseau, le VPC CNI s'en chargera également sur cet appareil. ENIs Pour utiliser des interfaces EFA uniquement avec des clusters EKS, consultez [Exécuter un entraînement de machine learning sur Amazon EKS avec Elastic Fabric Adapter](node-efa.md).
### **7. Puis-je voir si un nœud de mon cluster prend en charge ENA ?**
Oui, vous pouvez utiliser la AWS CLI ou EC2 l'API pour récupérer des informations réseau concernant une EC2 instance de votre cluster. Cela vous permettra de savoir si l’instance prend en charge ENA. Dans l'exemple suivant, remplacez `` par l'ID d' EC2 instance d'un nœud.
AWS Exemple de CLI :
```
aws ec2 describe-instances --instance-ids --query "Reservations[].Instances[].EnaSupport"
```
Exemple de sortie :
```
[ true ]
```
### **8. Puis-je voir les différentes adresses IP associées à un pod ?**
Non, pas facilement. Cependant, vous pouvez utiliser `nsenter` à partir du nœud pour exécuter des outils réseau courants tels que `ip route show` et voir les adresses IP et les interfaces supplémentaires.
### **9. Puis-je contrôler le nombre d’interfaces réseau pour mes pods ?**
Non Lorsque votre charge de travail est configurée pour en utiliser plusieurs NICs sur une instance prise en charge, un seul pod possède automatiquement une adresse IP provenant de chaque carte réseau de l'instance. Sinon, les pods à connexion unique disposeront d’une interface réseau connectée à une carte réseau sur l’instance.
**Important**
Les cartes réseau auxquelles *seul* un périphérique **EFA uniquement** est connecté sont ignorées par le CNI VPC.
### **10. Puis-je configurer mes pods pour qu’ils utilisent une carte réseau spécifique ?**
Non, cela n’est pas pris en charge. Si un pod dispose de l’annotation appropriée, le CNI VPC le configure automatiquement pour utiliser toutes les cartes réseau avec un adaptateur ENA sur le composant master.
### **11. Cette fonctionnalité est-elle compatible avec les autres fonctionnalités réseau du CNI VPC ?**
Oui, la fonctionnalité multi-cartes réseau du CNI VPC est compatible avec le *réseau personnalisé* et la *détection améliorée des sous-réseaux*. Cependant, les pods multi-homed n’utilisent pas les sous-réseaux personnalisés ni les groupes de sécurité. Au lieu de cela, le CNI VPC attribue des adresses IP et des interfaces réseau aux pods multi-homed avec la même configuration de sous-réseau et de groupe de sécurité que le nœud. Pour plus d’informations sur la mise en réseau personnalisée, consultez [Déploiement de pods dans des sous-réseaux alternatifs avec réseau personnalisé](cni-custom-network.md).
La fonctionnalité multi-NIC du CNI VPC ne fonctionne pas avec les *groupes de sécurité pour les pods* et ne peut pas être combinée avec ceux-ci.
### **12. Puis-je utiliser des politiques réseau avec cette fonctionnalité ?**
Oui, vous pouvez utiliser les politiques réseau Kubernetes avec plusieurs cartes réseau. Les politiques réseau Kubernetes limitent le trafic réseau vers et depuis vos pods. Pour plus d’informations sur l’application des politiques réseau avec le CNI VPC EKS, consultez [Limitation du trafic des pods à l’aide des politiques réseau Kubernetes](cni-network-policy.md).
### **13. La prise en charge de plusieurs cartes réseau est-elle activée dans le mode automatique EKS ?**
Plusieurs cartes réseau ne sont pas prises en charge pour les clusters du mode automatique EKS.