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.
# Bonnes pratiques en matière de mise en réseau
**Astuce**
[Découvrez les](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) meilleures pratiques grâce aux ateliers Amazon EKS.
Il est essentiel de comprendre le réseau Kubernetes pour exploiter efficacement votre cluster et vos applications. Le réseau de pods, également appelé réseau de clusters, est au cœur du réseau Kubernetes. Kubernetes prend en charge les plug-ins CNI ([Container Network Interface](https://github.com/containernetworking/cni)) pour la mise en réseau des clusters.
Amazon EKS prend officiellement en charge le plugin [Amazon Virtual Private Cloud (VPC) CNI](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) pour implémenter le réseau Kubernetes Pod. Le VPC CNI fournit une intégration native avec AWS VPC et fonctionne en mode sous-couche. En mode sous-couche, les pods et les hôtes sont situés sur la même couche réseau et partagent l'espace de noms du réseau. L'adresse IP du Pod est cohérente du point de vue du cluster et du VPC.
Ce guide présente l'[interface réseau de conteneurs Amazon VPC](https://github.com/aws/amazon-vpc-cni-k8s) (VPC CNI) dans le contexte de la mise en réseau de clusters Kubernetes. Le VPC CNI est le plugin réseau par défaut pris en charge par EKS et constitue donc l'objet du guide. Le VPC CNI est hautement configurable pour prendre en charge différents cas d'utilisation. Ce guide comprend également des sections dédiées sur les différents cas d'utilisation du VPC CNI, les modes de fonctionnement, les sous-composants, suivies des recommandations.
Amazon EKS exécute Kubernetes en amont et est certifié conforme à Kubernetes. Bien que vous puissiez utiliser des plug-ins CNI alternatifs, ce guide ne fournit aucune recommandation pour la gestion des CNI alternatifs. Consultez la documentation [EKS Alternate CNI](https://docs.aws.amazon.com/eks/latest/userguide/alternate-cni-plugins.html) pour obtenir une liste des partenaires et des ressources permettant de gérer efficacement les CNI alternatifs.
## Modèle de réseau Kubernetes
Kubernetes définit les exigences suivantes en matière de mise en réseau de clusters :
+ Les pods planifiés sur le même nœud doivent pouvoir communiquer avec d'autres pods sans utiliser le NAT (Network Address Translation).
+ Tous les démons du système (processus d'arrière-plan, par exemple, [kubelet](https://kubernetes.io/docs/concepts/overview/components/)) exécutés sur un nœud particulier peuvent communiquer avec les pods exécutés sur le même nœud.
+ Les pods qui utilisent le [réseau hôte](https://docs.docker.com/network/host/) doivent pouvoir contacter tous les autres pods sur tous les autres nœuds sans utiliser le NAT.
Consultez [le modèle de réseau Kubernetes](https://kubernetes.io/docs/concepts/services-networking/#the-kubernetes-network-model) pour plus de détails sur ce que Kubernetes attend des implémentations réseau compatibles. La figure suivante illustre la relation entre les espaces de noms du réseau Pod et l'espace de noms du réseau hôte.
## Interface réseau de conteneurs (CNI)
Kubernetes prend en charge les spécifications CNI et les plugins pour implémenter le modèle de réseau Kubernetes. Un CNI se compose d'une [spécification](https://github.com/containernetworking/cni/blob/main/SPEC.md) (version actuelle 1.0.0) et de bibliothèques permettant d'écrire des plugins pour configurer les interfaces réseau dans des conteneurs, ainsi que d'un certain nombre de plugins pris en charge. Le CNI s'occupe uniquement de la connectivité réseau des conteneurs et de la suppression des ressources allouées lorsque le conteneur est supprimé.
Le plugin CNI est activé en passant à kubelet l'option de ligne de `--network-plugin=cni` commande. Kubelet lit un fichier depuis `--cni-conf-dir` (par défaut/etc/cni/net.d) et utilise la configuration CNI de ce fichier pour configurer le réseau de chaque Pod. Le fichier de configuration CNI doit correspondre à la spécification CNI (version 0.4.0 minimale) et tous les plugins CNI requis référencés par la configuration doivent être présents dans le `--cni-bin-dir` répertoire (par défaut//bin). opt/cni S'il existe plusieurs fichiers de configuration CNI dans le répertoire, le kubelet utilise le fichier de configuration qui vient en premier par nom dans l'ordre lexicographique.
## Amazon Virtual Private Cloud (VPC) CNI
Le AWS-provided VPC CNI est le module complémentaire réseau par défaut pour les clusters EKS. Le module complémentaire VPC CNI est installé par défaut lorsque vous provisionnez des clusters EKS. Le VPC CNI s'exécute sur les nœuds de travail Kubernetes. Le module complémentaire VPC CNI comprend le binaire CNI et le plug-in de gestion des adresses IP (ipamd). Le CNI attribue une adresse IP du réseau VPC à un Pod. L'ipamd gère les interfaces réseau élastiques (ENI) AWS vers chaque nœud Kubernetes et gère le pool d'adresses IP chaudes. Le VPC CNI fournit des options de configuration pour la préallocation des ENI et des adresses IP afin de réduire les temps de démarrage des Pod. Consultez [Amazon VPC CNI pour connaître les meilleures pratiques recommandées en](vpc-cni.md) matière de gestion des plug-ins.
Amazon EKS vous recommande de spécifier des sous-réseaux dans au moins deux zones de disponibilité lorsque vous créez un cluster. Amazon VPC CNI alloue des adresses IP aux pods à partir des sous-réseaux des nœuds. Nous vous recommandons vivement de vérifier les adresses IP disponibles dans les sous-réseaux. Veuillez prendre en compte les recommandations relatives aux [VPC et aux sous-réseaux](subnets.md) avant de déployer des clusters EKS.
Amazon VPC CNI alloue un pool chaud d'ENI et d'adresses IP secondaires à partir du sous-réseau attaché à l'ENI principal du nœud. Ce mode de VPC CNI est appelé mode IP [secondaire](vpc-cni.md). Le nombre d'adresses IP et donc le nombre de pods (densité de pods) est défini par le nombre d'ENI et par l'adresse IP par ENI (limites) telles que définies par le type d'instance. Le mode secondaire est le mode par défaut et fonctionne bien pour les petits clusters dotés de types d'instances plus petits. Veuillez envisager d'utiliser le [mode préfixe](prefix-mode-linux.md) si vous rencontrez des problèmes de densité de capsules. Vous pouvez également augmenter le nombre d'adresses IP disponibles sur le nœud pour les pods en attribuant des préfixes aux ENI.
Amazon VPC CNI s'intègre nativement à AWS VPC et permet aux utilisateurs d'appliquer les meilleures pratiques existantes en matière de mise en réseau et de sécurité des VPC AWS pour créer des clusters Kubernetes. Cela inclut la possibilité d'utiliser les journaux de flux VPC, les politiques de routage VPC et les groupes de sécurité pour isoler le trafic réseau. Par défaut, le CNI Amazon VPC applique le groupe de sécurité associé à l'ENI principal sur le nœud aux pods. Envisagez d'activer [les groupes de sécurité pour les pods](sgpp.md) lorsque vous souhaitez attribuer des règles réseau différentes à un pod.
Par défaut, le VPC CNI attribue des adresses IP aux pods à partir du sous-réseau attribué à l'ENI principal d'un nœud. Il est courant de rencontrer une pénurie d'adresses IPv4 lors de l'exécution de grands clusters avec des milliers de charges de travail. AWS VPC vous permet d'étendre les adresses IP disponibles en [attribuant un CIDR secondaire pour contourner l'épuisement des blocs d'adresse CIDR](https://docs.aws.amazon.com/vpc/latest/userguide/configure-your-vpc.html#add-cidr-block-restrictions) IPv4. AWS VPC CNI vous permet d'utiliser une plage d'adresses CIDR de sous-réseau différente pour les pods. [Cette fonctionnalité du VPC CNI est appelée mise en réseau personnalisée.](custom-networking.md) Vous pouvez envisager d'utiliser un réseau personnalisé `100.64.0.0/10` et des `198.19.0.0/16` CIDR (CG-NAT) avec EKS. Cela vous permet efficacement de créer un environnement dans lequel les pods ne consomment plus aucune adresse IP RFC1918 provenant de votre VPC.
La mise en réseau personnalisée est l'une des options permettant de résoudre le problème d'épuisement des adresses IPv4, mais elle nécessite une surcharge opérationnelle. Pour résoudre ce problème, nous recommandons l'utilisation de clusters IPv6 par le biais d'un réseau personnalisé. Plus précisément, nous vous recommandons de migrer vers des [clusters IPv6](ipv6.md) si vous avez complètement épuisé tout l'espace d'adressage IPv4 disponible pour votre VPC. Évaluez les plans de votre organisation en matière de prise en charge de l'IPv6 et déterminez si l'investissement dans l'IPv6 peut avoir une valeur à plus long terme.
Le support d'EKS pour IPv6 vise à résoudre le problème d'épuisement des adresses IP causé par un espace d'adressage IPv4 limité. En réponse aux problèmes des clients liés à l'épuisement du protocole IPv4, EKS a donné la priorité aux pods par rapport aux IPv6-only pods à double pile. En d'autres termes, les pods peuvent accéder aux ressources IPv4, mais aucune adresse IPv4 de la plage d'adresses CIDR VPC ne leur est attribuée. Le VPC CNI attribue des adresses IPv6 aux pods à partir du bloc d'adresse CIDR IPv6 VPC géré par AWS.
## Calculateur de sous-réseau
Ce projet inclut un [document Excel de calcul de sous-réseau](https://github.com/aws/aws-eks-best-practices/blob/master/latest/bpg/networking/subnet-calc/subnet-calc.xlsx). Ce document de calcul simule la consommation d'adresses IP d'une charge de travail spécifiée selon différentes options de configuration ENI, telles que `WARM_IP_TARGET` et`WARM_ENI_TARGET`. Le document comprend deux feuilles, une première pour le mode Warm ENI et une seconde pour le mode Warm IP. Consultez le [guide VPC CNI](vpc-cni.md) pour plus d'informations sur ces modes.
Entrées :
+ Taille CIDR du sous-réseau
+ Cible ENI chaude *ou* cible IP chaude
+ Liste des instances
+ type, nombre et nombre de pods de charge de travail planifiés par instance
Sorties :
+ Nombre total de pods hébergés
+ Nombre d'adresses IP de sous-réseau consommées
+ Nombre d'adresses IP de sous-réseau restantes
+ Détails au niveau de l'instance
+ Nombre de Warm IPs/ENIs par instance
+ Nombre d'actifs IPs/ENIs par instance