Sélectionner vos préférences de cookies

Nous utilisons des cookies essentiels et des outils similaires qui sont nécessaires au fonctionnement de notre site et à la fourniture de nos services. Nous utilisons des cookies de performance pour collecter des statistiques anonymes afin de comprendre comment les clients utilisent notre site et d’apporter des améliorations. Les cookies essentiels ne peuvent pas être désactivés, mais vous pouvez cliquer sur « Personnaliser » ou « Refuser » pour refuser les cookies de performance.

Si vous êtes d’accord, AWS et les tiers approuvés utiliseront également des cookies pour fournir des fonctionnalités utiles au site, mémoriser vos préférences et afficher du contenu pertinent, y compris des publicités pertinentes. Pour accepter ou refuser tous les cookies non essentiels, cliquez sur « Accepter » ou « Refuser ». Pour effectuer des choix plus détaillés, cliquez sur « Personnaliser ».

Bonnes pratiques en matière de mise en réseau - Amazon EKS

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.

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

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) pour la mise en réseau des clusters.

Amazon EKS prend officiellement en charge le plugin Amazon Virtual Private Cloud (VPC) CNI 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 (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 d'autres plug-ins CNI, ce guide ne fournit pas de recommandations pour gérer les plug-ins alternatifs CNIs. Consultez la documentation EKS Alternate CNI pour obtenir une liste des partenaires et des ressources permettant de gérer CNIs efficacement les alternatives.

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

illustration du réseau hôte et des espaces de noms du réseau à 2 modules

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 (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 (default /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 répertoire (). --cni-bin-dir default /opt/cni/bin 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 VPC CNI fourni par AWS 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 AWS Elastic (ENIs) vers chaque nœud Kubernetes et gère le pool de chaleur de. IPs Le VPC CNI fournit des options de configuration pour la pré-allocation ENIs et des adresses IP pour des temps de démarrage rapides des Pod. Consultez Amazon VPC CNI pour connaître les meilleures pratiques recommandées en 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 avant de déployer des clusters EKS.

Amazon VPC CNI alloue un pool chaud d'adresses IP secondaires à partir du ENIs sous-réseau attaché à l'ENI principal du nœud. Ce mode de VPC CNI est appelé mode IP secondaire. Le nombre d'adresses IP et donc le nombre de pods (densité de pods) est défini par le nombre ENIs et l'adresse IP par ENI (limites), tels que définis 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. Envisagez d'utiliser le mode préfixe 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 à. ENIs

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 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' IPv4 adresses lors de l'exécution de grands clusters avec des milliers de charges de travail. AWS VPC vous permet d'étendre la disponibilité IPs en affectant un secondaire CIDRs pour contourner l'épuisement des IPv4 blocs CIDR. 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. Vous pouvez envisager d'utiliser un réseau personnalisé pour utiliser 100.64.0.0/10 et 198.19.0.0/16 CIDRs (CG-NAT) avec EKS. Cela vous permet de créer un environnement dans lequel les pods ne consomment plus aucune RFC1918 adresse IP provenant de votre VPC.

La mise en réseau personnalisée est l'une des options permettant de IPv4 résoudre le problème de l'épuisement des adresses, mais elle implique une surcharge opérationnelle. Pour résoudre ce problème, nous recommandons d'utiliser des IPv6 clusters plutôt que des réseaux personnalisés. Plus précisément, nous vous recommandons de migrer vers des IPv6 clusters si vous avez complètement épuisé tout l'espace d' IPv4 adressage disponible pour votre VPC. Évaluez les plans de soutien IPv6 de votre organisation et déterminez si l'investissement dans ce domaine IPv6 peut avoir une plus grande valeur à long terme.

L'assistance d'EKS IPv6 est axée sur la résolution du problème d'épuisement des adresses IP causé par un espace d' IPv4 adressage limité. En réponse aux problèmes d' IPv4 épuisement des clients, EKS a privilégié les pods réservés IPv6 uniquement aux pods à double pile. En d'autres termes, les pods peuvent accéder aux IPv4 ressources, mais aucune adresse ne leur est attribuée dans la plage d' IPv4 adresses CIDR VPC. Le VPC CNI attribue des IPv6 adresses aux pods à partir du bloc d'adresse CIDR VPC géré par AWS. IPv6

Calculateur de sous-réseau

Ce projet inclut un document Excel de calcul de sous-réseau. 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 etWARM_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 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 de sous-réseaux consommés IPs

  • Nombre de sous-réseaux restants IPs

  • Détails au niveau de l'instance

    • Nombre de IPs Warm/ ENIs par instance

    • Nombre de IPs/actifs ENIs par instance

ConfidentialitéConditions d'utilisation du sitePréférences de cookies
© 2025, Amazon Web Services, Inc. ou ses affiliés. Tous droits réservés.