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.

CNI Amazon VPC

Amazon EKS implémente la mise en réseau des clusters via le plug-in Amazon VPC Container Network Interface, également connu sous le nom de VPC CNI. Le plugin CNI permet aux Kubernetes Pods d'avoir la même adresse IP que sur le réseau VPC. Plus précisément, tous les conteneurs du Pod partagent un espace de noms réseau et peuvent communiquer entre eux via des ports locaux.

Amazon VPC CNI comporte deux composants :

Lorsqu'une instance est créée, EC2 crée et associe un ENI principal associé à un sous-réseau principal. Le sous-réseau principal peut être public ou privé. Les pods qui s'exécutent en mode HostNetwork utilisent l'adresse IP principale attribuée à l'ENI principal du nœud et partagent le même espace de noms réseau que l'hôte.

Le plug-in CNI gère les interfaces réseau élastiques (ENI) sur le nœud. Lorsqu'un nœud est provisionné, le plug-in CNI alloue automatiquement un pool d'emplacements (adresses IP ou préfixes) du sous-réseau du nœud à l'ENI principal. Ce pool est appelé pool chaud et sa taille est déterminée par le type d'instance du nœud. Selon les paramètres CNI, un slot peut être une adresse IP ou un préfixe. Lorsqu'un emplacement sur une ENI a été attribué, le CNI peut associer des ENI supplémentaires avec un pool d'emplacements chauds aux nœuds. Ces ENI supplémentaires sont appelés ENI secondaires. Chaque ENI ne peut prendre en charge qu'un certain nombre d'emplacements, en fonction du type d'instance. Le CNI associe davantage d'ENI aux instances en fonction du nombre d'emplacements nécessaires, qui correspond généralement au nombre de pods. Ce processus se poursuit jusqu'à ce que le nœud ne puisse plus prendre en charge d'autres ENI. Le CNI préalloue également des ENI et des emplacements « chauds » pour un démarrage plus rapide du Pod. Notez que chaque type d'instance possède un nombre maximum d'ENI qui peuvent être attachés. Il s'agit d'une contrainte sur la densité des pods (nombre de pods par nœud), en plus des ressources de calcul.

Le nombre maximum d'interfaces réseau et le nombre maximum d'emplacements que vous pouvez utiliser varient en fonction du type d'instance EC2. Étant donné que chaque pod consomme une adresse IP sur un emplacement, le nombre de pods que vous pouvez exécuter sur une instance EC2 particulière dépend du nombre d'ENI qui peuvent y être attachés et du nombre d'emplacements pris en charge par chaque ENI. Nous vous suggérons de définir le nombre maximum de pods par guide de l'utilisateur EKS afin d'éviter l'épuisement des ressources du processeur et de la mémoire de l'instance. Les pods hostNetwork utilisés sont exclus de ce calcul. Pour plus d'informations, consultez la section Comment les MaxPods sont déterminés dans le guide de l'utilisateur Amazon EKS.

Présentation de

Le mode IP secondaire est le mode par défaut pour VPC CNI. Ce guide fournit une vue d'ensemble générique du comportement CNI du VPC lorsque le mode IP secondaire est activé. La fonctionnalité d'ipamd (allocation d'adresses IP) peut varier en fonction des paramètres de configuration du VPC CNI, tels queMode préfixe pour Linux, etGroupes de sécurité par pod. Réseau personnalisé

L'Amazon VPC CNI est déployé sous la forme d'un Daemonset Kubernetes nommé aws-node sur les nœuds de travail. Lorsqu'un nœud de travail est provisionné, un ENI par défaut, appelé ENI principal, lui est attaché. Le CNI alloue un pool chaud d'ENI et d'adresses IP secondaires à partir du sous-réseau attaché à l'ENI principal du nœud. Par défaut, ipamd tente d'allouer une ENI supplémentaire au nœud. L'IPAMD alloue un ENI supplémentaire lorsqu'un seul Pod est planifié et qu'une adresse IP secondaire lui est attribuée par l'ENI principal. Cet ENI « chaud » permet une mise en réseau plus rapide des Pod. Lorsque le pool d'adresses IP secondaires est épuisé, le CNI ajoute un autre ENI pour en attribuer d'autres.

Le nombre d'ENI et d'adresses IP d'un pool est configuré via des variables d'environnement appelées WARM_ENI_TARGET, WARM_IP_TARGET, MINIMUM_IP_TARGET. Le aws-node Daemonset vérifiera périodiquement qu'un nombre suffisant d'ENI sont connectés. Un nombre suffisant d'ENI sont attachés lorsque toutes WARM_ENI_TARGET les MINIMUM_IP_TARGET conditions ou WARM_IP_TARGET et sont remplies. S'il n'y a pas suffisamment d'ENI attachés, le CNI effectuera un appel d'API à EC2 pour en attacher davantage jusqu'à ce que la MAX_ENI limite soit atteinte.

Ce projet inclut un document Excel de calculateur 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.

Lorsque Kubelet reçoit une demande d'ajout de Pod, le binaire CNI demande à ipamd une adresse IP disponible, que ipamd fournit ensuite au Pod. Le binaire CNI connecte le réseau hôte et le réseau Pod.

Les pods déployés sur un nœud sont, par défaut, affectés aux mêmes groupes de sécurité que l'ENI principal. Les Pods peuvent également être configurés avec différents groupes de sécurité.

Lorsque le groupe d'adresses IP est épuisé, le plugin attache automatiquement une autre interface réseau Elastic à l'instance et alloue un autre ensemble d'adresses IP secondaires à cette interface. Ce processus se poursuit jusqu'à ce que le nœud ne puisse plus prendre en charge des interfaces réseau Elastic supplémentaires.

Lorsqu'un Pod est supprimé, VPC CNI place son adresse IP dans un cache de refroidissement de 30 secondes. Les adresses IP d'un cache de refroidissement ne sont pas attribuées aux nouveaux pods. Lorsque la période de refroidissement est terminée, le VPC CNI redéplace le Pod IP vers le bassin chaud. La période de refroidissement empêche le recyclage prématuré des adresses IP des pods et permet à kube-proxy de terminer la mise à jour des règles iptables sur tous les nœuds du cluster. Lorsque le nombre d'adresses IP ou d'ENI dépasse le nombre de paramètres du pool chaud, le plug-in ipamd renvoie les adresses IP et les ENI au VPC.

Comme décrit ci-dessus en mode IP secondaire, chaque Pod reçoit une adresse IP privée secondaire de l'un des ENI attachés à une instance. Étant donné que chaque pod utilise une adresse IP, le nombre de pods que vous pouvez exécuter sur une instance EC2 particulière dépend du nombre d'ENI qui peuvent y être attachés et du nombre d'adresses IP prises en charge. Le VPC CNI vérifie le fichier de limites pour savoir combien d'ENI et d'adresses IP sont autorisés pour chaque type d'instance.

Vous pouvez utiliser la formule suivante pour déterminer le nombre maximum de Pods que vous pouvez déployer sur un nœud.

(Number of network interfaces for the instance type * (the number of IP addresses per network interface - 1)) + 2

Le +2 indique les Pods qui nécessitent un réseau hôte, tels que kube-proxy et VPC CNI. Amazon EKS nécessite que kube-proxy et VPC CNI fonctionnent sur chaque nœud, et ces exigences sont prises en compte dans la valeur max-pods. Si vous souhaitez exécuter des pods réseau hôtes supplémentaires, pensez à mettre à jour la valeur max-pods. Vous pouvez les spécifier --kubelet-extra-args "—max-pods=110" en tant que données utilisateur dans le modèle de lancement.

Par exemple, sur un cluster comportant 3 nœuds c5.large (3 ENI et 10 adresses IP maximum par ENI), lorsque le cluster démarre et possède 2 pods CoreDNS, le CNI consomme 50 adresses IP et conserve 43 adresses IP dans le pool chaud. Le pool chaud permet de lancer plus rapidement le Pod lorsque l'application est déployée.

Nœud 1 (avec pod CoreDNS) : 2 ENI, 20 adresses IP attribuées

Nœud 2 (avec pod CoreDNS) : 2 ENI, 20 adresses IP attribuées

Nœud 3 (pas de pod) : 1 ENI. 10 adresses IP attribuées.

Pour le nœud 1 et le nœud 2 (configuration identique) :

Pour le nœud 3 :

Calcul du pool chaud total : - 17 (nœud 1) + 17 (nœud 2) + 9 (nœud 3) = 43 adresses IP

N'oubliez pas que les modules d'infrastructure, qui s'exécutent souvent comme des ensembles de démons, contribuent chacun au nombre maximum de modules. Ceux-ci peuvent inclure :

Nous vous suggérons de planifier votre infrastructure en combinant les capacités de ces Pods. Pour une liste du nombre maximum de pods pris en charge par chaque type d'instance, consultez le fichier eni-max-pods.txt sur GitHub.

Recommandations

Déploiement du cluster EKS avec le mode automatique

Lorsque vous utilisez le mode automatique EKS pour créer un cluster, AWS gère la configuration VPC Container Network Interface (CNI) pour votre cluster. Avec le mode automatique Amazon EKS, il n’est pas nécessaire d’installer ou de mettre à niveau de modules complémentaires de mise en réseau. Cependant, assurez-vous que vos charges de travail sont compatibles avec la configuration CNI du VPC géré.

Déploiement d'un VPC CNI Managed Add-On

Lorsque vous provisionnez un cluster, Amazon EKS installe automatiquement le VPC CNI. Amazon EKS prend néanmoins en charge des modules complémentaires gérés qui permettent au cluster d'interagir avec les ressources AWS sous-jacentes telles que l'informatique, le stockage et la mise en réseau. Nous vous recommandons vivement de déployer des clusters avec des modules complémentaires gérés, notamment VPC CNI.

Le module complémentaire géré Amazon EKS propose l'installation et la gestion de VPC CNI pour les clusters Amazon EKS. Les modules complémentaires Amazon EKS incluent les derniers correctifs de sécurité et corrections de bogues et sont validés par AWS pour fonctionner avec Amazon EKS. Le module complémentaire VPC CNI vous permet de garantir en permanence la sécurité et la stabilité de vos clusters Amazon EKS et de réduire les efforts nécessaires à l'installation, à la configuration et à la mise à jour des modules complémentaires. En outre, un module complémentaire géré peut être ajouté, mis à jour ou supprimé via l'API Amazon EKS, la console de gestion AWS, l'interface de ligne de commande AWS et eksctl.

Vous pouvez trouver les champs gérés de VPC CNI en utilisant --show-managed-fields flag avec la kubectl get commande.

kubectl get daemonset aws-node --show-managed-fields -n kube-system -o yaml

Les modules complémentaires gérés empêchent la dérive de configuration en remplaçant automatiquement les configurations toutes les 15 minutes. Cela signifie que toutes les modifications apportées aux modules complémentaires gérés via l'API Kubernetes après leur création seront remplacées par le processus automatisé de prévention des dérives et seront également définies par défaut lors du processus de mise à jour des modules complémentaires.

Les champs gérés par EKS sont répertoriés sous ManagedFields avec le gestionnaire EKS. Les champs gérés par EKS incluent le compte de service, l'image, l'URL de l'image, la sonde de vivacité, la sonde de préparation, les étiquettes, les volumes et les montages de volume.

Nous vous suggérons de tester le comportement des modules complémentaires dans vos clusters hors production pour une configuration spécifique avant de mettre à jour les clusters de production. En outre, suivez les étapes du guide de l'utilisateur EKS pour les configurations complémentaires.

Migrer vers Managed Add-On

Vous allez gérer la compatibilité des versions et mettre à jour les correctifs de sécurité du VPC CNI autogéré. Pour mettre à jour un module complémentaire autogéré, vous devez utiliser les API Kubernetes et les instructions décrites dans le guide de l'utilisateur d'EKS. Nous vous recommandons de migrer vers un module complémentaire géré pour les clusters EKS existants et nous vous recommandons vivement de créer une sauvegarde de vos paramètres CNI actuels avant la migration. Pour configurer des modules complémentaires gérés, vous pouvez utiliser l'API Amazon EKS, la console de gestion AWS ou l'interface de ligne de commande AWS.

kubectl apply view-last-applied daemonset aws-node -n kube-system  aws-k8s-cni-old.yaml

Amazon EKS remplacera les paramètres de configuration CNI si le champ est répertorié comme étant géré avec les paramètres par défaut. Nous vous déconseillons de modifier les champs gérés. Le module complémentaire ne réconcilie pas les champs de configuration tels que les variables d'environnement chaud et les modes CNI. Les pods et les applications continueront de fonctionner pendant la migration vers un CNI géré.

Sauvegarder les paramètres CNI avant la mise à jour

Le VPC CNI s'exécute sur le plan de données client (nœuds). Amazon EKS ne met donc pas automatiquement à jour le module complémentaire (géré et autogéré) lorsque de nouvelles versions sont publiées ou après la mise à jour de votre cluster vers une nouvelle version mineure de Kubernetes. Pour mettre à jour le module complémentaire pour un cluster existant, vous devez déclencher une mise à jour via l'API update-addon ou cliquer sur le lien Mettre à jour maintenant dans la console EKS pour les modules complémentaires. Si vous avez déployé un module complémentaire autogéré, suivez les étapes décrites dans la section Mise à jour du module complémentaire CNI VPC autogéré.

Nous vous recommandons vivement de mettre à jour une version mineure à la fois. Par exemple, si 1.9 est votre version mineure actuelle que vous souhaitez la mettre à jour vers 1.11, vous devez d'abord mettre à jour vers le dernier correctif et la dernière version de build de 1.10, puis vers le dernier correctif et la dernière version de build de 1.11.

Inspectez le Daemonset du nœud AWS avant de mettre à jour Amazon VPC CNI. Effectuez une sauvegarde des paramètres existants. Si vous utilisez un module complémentaire géré, vérifiez que vous n'avez mis à jour aucun paramètre susceptible d'être remplacé par Amazon EKS. Nous vous recommandons d'ajouter un hook de post-mise à jour dans votre flux de travail d'automatisation ou de procéder à une étape d'application manuelle après la mise à jour d'un module complémentaire.

kubectl apply view-last-applied daemonset aws-node -n kube-system  aws-k8s-cni-old.yaml

Dans le cas d'un module complémentaire autogéré, comparez la sauvegarde avec releases une version GitHub pour voir les versions disponibles et vous familiariser avec les modifications apportées à la version vers laquelle vous souhaitez effectuer la mise à jour. Nous vous recommandons d'utiliser Helm pour gérer les modules complémentaires autogérés et exploiter les fichiers de valeurs pour appliquer les paramètres. Toute opération de mise à jour impliquant la suppression de Daemonset entraînera une interruption de l'application et doit être évitée.

Comprendre le contexte de sécurité

Nous vous suggérons vivement de comprendre les contextes de sécurité configurés pour gérer efficacement le VPC CNI. Amazon VPC CNI comprend deux composants : CNI binary et ipamd (aws-node) Daemonset. Le CNI s'exécute en tant que binaire sur un nœud et a accès au système de fichiers racine du nœud. Il dispose également d'un accès privilégié car il traite les iptables au niveau du nœud. Le binaire CNI est invoqué par le kubelet lorsque des Pods sont ajoutés ou supprimés.

Le daemonset aws-node est un processus de longue haleine responsable de la gestion des adresses IP au niveau du nœud. Le nœud aws fonctionne en hostNetwork mode et permet l'accès au périphérique de bouclage et l'activité réseau des autres pods sur le même nœud. Le conteneur d'initialisation aws-node s'exécute en mode privilégié et monte le socket CRI permettant au Daemonset de surveiller l'utilisation de l'IP par les pods exécutés sur le nœud. Amazon EKS s'efforce de supprimer l'exigence de privilèges du conteneur d'initialisation aws-node. De plus, le nœud aws doit mettre à jour les entrées NAT et charger les modules iptables. Il fonctionne donc avec les privilèges NET_ADMIN.

Amazon EKS recommande de déployer les politiques de sécurité telles que définies par le manifeste aws-node pour la gestion des adresses IP des pods et des paramètres réseau. Pensez à passer à la dernière version de VPC CNI. En outre, pensez à ouvrir un GitHub dossier si vous avez des exigences de sécurité spécifiques.

Utiliser un rôle IAM distinct pour CNI

L'AWS VPC CNI nécessite des autorisations AWS Identity and Access Management (IAM). La politique CNI doit être configurée avant que le rôle IAM puisse être utilisé. Vous pouvez utiliser AmazonEKS_CNI_Policy, qui est une politique gérée par AWS pour les clusters IPv4. La politique gérée CNI d'Amazoneks ne dispose d'autorisations que pour les clusters IPv4. Vous devez créer une politique IAM distincte pour les clusters IPv6 avec les autorisations répertoriées ici.

Par défaut, VPC CNI hérite du rôle IAM du nœud Amazon EKS (groupes de nœuds gérés et autogérés).

Il est vivement recommandé de configurer un rôle IAM distinct avec les politiques pertinentes pour Amazon VPC CNI. Dans le cas contraire, les pods d'Amazon VPC CNI obtiennent l'autorisation attribuée au rôle IAM du nœud et ont accès au profil d'instance attribué au nœud.

Le plugin VPC CNI crée et configure un compte de service appelé aws-node. Par défaut, le compte de service est lié au rôle IAM du nœud Amazon EKS auquel est associée la politique CNI Amazon EKS. Pour utiliser le rôle IAM distinct, nous vous recommandons de créer un nouveau compte de service auquel est associée la politique CNI Amazon EKS. Pour utiliser un nouveau compte de service, vous devez redéployer les pods CNI. Envisagez de spécifier un module complémentaire géré --service-account-role-arn pour VPC CNI lors de la création de nouveaux clusters. Assurez-vous de supprimer la politique CNI Amazon EKS pour IPv4 et IPv6 du rôle de nœud Amazon EKS.

Il est conseillé de bloquer l'accès aux métadonnées des instances afin de minimiser le rayon d'action des failles de sécurité.

Gérer les défaillances des Liveness/Readiness sondes

Nous vous conseillons d'augmenter les valeurs de temps d'expiration de la sonde de disponibilité et de disponibilité (par défauttimeoutSeconds: 10) pour les clusters EKS 1.20 et versions ultérieures afin d'éviter que des défaillances de sonde n'entraînent le blocage du pod de votre application dans l'état ContainerCreating. Ce problème a été observé dans les clusters à forte intensité de données et de traitement par lots. Une utilisation élevée du processeur entraîne des problèmes de santé de la sonde aws-node, ce qui entraîne des demandes de processeur de pod non satisfaites. En plus de modifier le délai d'expiration de la sonde, assurez-vous que les demandes de ressources CPU (par défautCPU: 25m) pour aws-node sont correctement configurées. Nous vous déconseillons de mettre à jour les paramètres sauf si votre nœud rencontre des problèmes.

Nous vous encourageons vivement à exécuter sudo bash /opt/cni/bin/aws-cni-support.sh sur un nœud pendant que vous utilisez le support Amazon EKS. Le script vous aidera à évaluer les journaux de Kubelet et l'utilisation de la mémoire sur le nœud. Pensez à installer l'agent SSM sur les nœuds de travail Amazon EKS pour exécuter le script.

Configurer la politique de transfert d'IPTables sur les instances AMI optimisées non EKS

Si vous utilisez une AMI personnalisée, assurez-vous de définir la politique de transfert d'iptables sur ACCEPT sous https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2023/runtime/rootfs/etc/systemd/system/kubelet.service kubelet.service. De nombreux systèmes définissent la politique de transfert d'iptables sur DROP. Vous pouvez créer une AMI personnalisée à l'aide de HashiCorp Packer et d'une spécification de génération contenant des ressources et des scripts de configuration provenant du référentiel Amazon EKS AMI sur AWS GitHub. Vous pouvez mettre à jour le fichier kubelet.service et suivre les instructions spécifiées ici pour créer une AMI personnalisée.

Mettez régulièrement à niveau la version CNI

Le VPC CNI est rétrocompatible. La dernière version fonctionne avec toutes les versions de Kubernetes prises en charge par Amazon EKS. En outre, le VPC CNI est proposé en tant que module complémentaire EKS (voir « Deploy VPC CNI Managed Add-On » ci-dessus). Bien que les modules complémentaires EKS orchestrent les mises à niveau des modules complémentaires, ils ne mettent pas automatiquement à niveau les modules complémentaires tels que le CNI, car ils s'exécutent sur le plan de données. Vous êtes responsable de la mise à niveau du module complémentaire VPC CNI à la suite des mises à niveau des nœuds de travail gérés et autogérés.