**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. # Découvrez comment fonctionne le mode automatique EKS Ce chapitre explique le fonctionnement des composants des clusters du mode automatique Amazon EKS. **Topics** + [Informations sur les instances gérées par le mode automatique Amazon EKS](automode-learn-instances.md) + [Informations sur les identités et l’accès dans le mode automatique EKS](auto-learn-iam.md) + [Informations sur le réseau VPC et l’équilibrage de charge dans le mode automatique EKS](auto-networking.md) # Informations sur les instances gérées par le mode automatique Amazon EKS Cette rubrique explique comment le mode automatique Amazon EKS gère les EC2 instances Amazon dans votre cluster EKS. Lorsque vous activez le mode automatique EKS, les ressources de calcul de votre cluster sont automatiquement provisionnées et gérées par EKS, ce qui modifie la façon dont vous interagissez avec les EC2 instances qui servent de nœuds dans votre cluster. Il est essentiel de comprendre comment le mode automatique Amazon EKS gère les instances afin de bien planifier votre stratégie de déploiement des charges de travail et vos procédures opérationnelles. Contrairement aux EC2 instances traditionnelles ou aux groupes de nœuds gérés, ces instances suivent un modèle de cycle de vie différent dans lequel EKS assume la responsabilité de nombreux aspects opérationnels, tout en limitant certains types d'accès et de personnalisation. Le mode automatique Amazon EKS automatise les tâches de routine pour créer de nouvelles EC2 instances et les attache en tant que nœuds à votre cluster EKS. Le mode automatique EKS détecte lorsqu'une charge de travail ne peut pas s'adapter aux nœuds existants et crée une nouvelle EC2 instance. Le mode automatique Amazon EKS est chargé de créer, de supprimer et d'appliquer des correctifs aux EC2 instances. Vous restez responsable des conteneurs et des pods déployés sur ces instances. EC2 Les instances créées par le mode automatique d'EKS sont différentes des autres EC2 instances, ce sont des instances gérées. Ces instances gérées sont détenues par EKS et présentent des restrictions supplémentaires. Vous ne pouvez ni accéder directement aux instances gérées par le mode automatique EKS, ni y installer de logiciels. AWS suggère d'exécuter le mode automatique EKS ou Karpenter autogéré. Vous pouvez installer les deux durant une phase de migration ou dans une configuration avancée. Si vous avez installé les deux, configurez vos pools de nœuds afin que les charges de travail soient associées soit à Karpenter, soit au mode automatique EKS. Pour plus d'informations, consultez les [instances EC2 gérées par Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-managed-instances.html) dans le guide de EC2 l'utilisateur Amazon. ## Tableau comparatif | EC2 Instance standard | Instance gérée par le mode automatique EKS | | --- | --- | | Vous êtes responsable de l’application des correctifs et de la mise à jour de l’instance. | AWS corrige et met à jour automatiquement l'instance. | | EKS n’est pas responsable des logiciels installés sur l’instance. | EKS est responsable de certains logiciels sur l’instance, tels que `kubelet`, le moteur d’exécution des conteneurs et le système d’exploitation. | | Vous pouvez supprimer l' EC2 instance à l'aide de l' EC2 API. | EKS détermine le nombre d’instances déployées dans votre compte. Si vous supprimez une charge de travail, EKS réduira le nombre d’instances dans votre compte. | | Vous pouvez utiliser SSH pour accéder à l' EC2 instance. | Vous pouvez déployer des pods et des conteneurs sur l’instance gérée. | | Vous déterminez le système d’exploitation et l’image (AMI). | AWS détermine le système d'exploitation et l'image. | | Vous pouvez déployer des charges de travail reposant sur les fonctionnalités de Windows ou d’Ubuntu. | Vous pouvez également déployer des conteneurs basés sur Linux, sans dépendances particulières au système d’exploitation. | | Vous déterminez le type et la famille d’instance à lancer. | AWS détermine le type et la famille d'instances à lancer. Vous pouvez utiliser un groupe de nœuds pour limiter les types d’instances parmi lesquels le mode automatique EKS peut sélectionner. | Les fonctionnalités suivantes fonctionnent à la fois pour les instances gérées et les EC2 instances standard : + Vous pouvez afficher l'instance dans la AWS console. + Vous pouvez utiliser le stockage d’instance comme stockage éphémère pour les charges de travail. ### Support AMI Avec le mode automatique EKS, AWS détermine l'image (AMI) utilisée pour vos nœuds de calcul. AWS surveille le déploiement des nouvelles versions de l'AMI en mode automatique d'EKS. Si vous rencontrez des problèmes de charge de travail liés à une version d’AMI, créez un cas de support. Pour plus d'informations, consultez les sections [Création de dossiers de support et gestion de dossiers](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) dans le Guide de l'utilisateur du AWS support. En général, EKS publie chaque semaine une nouvelle AMI contenant des correctifs CVE et de sécurité. ## Référence des instances prises en charge par le mode automatique EKS Le mode automatique EKS crée uniquement des instances de types pris en charge et répondant à une taille minimale requise. Le mode automatique EKS prend en charge les types d’instances suivants : | Family | Types d’instances | | --- | --- | | Optimisées pour le calcul (C) | c8i, c8i-flex, c8gd, c8gn, c8g, c7a, c7g, c7gn, c7gd, c7i, c7i-flex, c6a, c6g, c6i, c6gn, c6id, c5ad, c5n, 4 | | Usage général (M) | m8i, m8i-flex, m8a, m8gn, m8gb, m8gd, m8g, m7i, m7a, m7g, m7gd, m7i-flex, m6a, m6i, m6in, m6g, m6idn, m6id, m5, m5ad, m5n, m5dn, m5d, m5zn, m4 | | Optimisées pour la mémoire (R) | r8i, r8i-flex, r8gn, r8gb, r8g, r7a, r7iz, r7gd, r7i, r7g, r6a, r6i, r6id, r6in, r6idn, r6g, r6gd, r5, r5dn, r5b, r5b, 5ad, 5d, r4 | | Capacité extensible (T) | t4g, t3, t3a, t2 | | Mémoire élevée (Z/X) | z1d, x8g, x2gd | | Optimisées pour le stockage (I/D) | i8ge, i7i, i8g, i7ie, i4g, i4i, i3, i3en, is4gen, d3, d3en, im4gn | | Informatique accélérée (P/G/Inf/Trn) | p5, p4d, p4de, p3, p3dn, gr6, g6, g6e, g5g, g5, g4dn, inf2, inf1, trn1, trn1n | | Calcul haute performance (X2) | x2iezn, x2iedn, x2idn | En outre, le mode automatique d'EKS ne créera que EC2 des instances répondant aux exigences suivantes : + Plus d’un processeur + Taille d’instance différente de nano, micro ou petite Pour plus d'informations, consultez les [conventions de dénomination des types d' EC2 instances Amazon](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html). ## Service des métadonnées d’instance + Le mode automatique EKS est IMDSv2 appliqué avec une limite de saut de 1 par défaut, conformément aux meilleures pratiques AWS de sécurité. + Cette configuration par défaut ne peut pas être modifiée en mode automatique. + Pour les modules complémentaires qui nécessitent généralement un accès IMDS, fournissez des paramètres (tels que AWS la région) lors de l'installation afin d'éviter les recherches IMDS. Pour de plus amples informations, veuillez consulter [Déterminez les champs que vous pouvez personnaliser pour les modules complémentaires Amazon EKS](kubernetes-field-management.md). + Si un pod doit absolument accéder à IMDS lorsqu’il s’exécute en mode automatique, il doit être configuré pour s’exécuter avec `hostNetwork: true`. Cela permet au pod d’accéder directement au service de métadonnées de l’instance. + Évaluez toujours les implications de sécurité avant d’autoriser un pod à accéder aux métadonnées de l’instance. Pour plus d'informations sur le service de métadonnées d' EC2 instance Amazon (IMDS), consultez [Configurer les options du service de métadonnées d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html) dans le *guide de l' EC2 utilisateur Amazon*. ## Considérations + Si le stockage éphémère configuré dans le NodeClass est plus petit que le stockage NVMe local de l'instance, le mode automatique d'EKS élimine le besoin de configuration manuelle en effectuant automatiquement les actions suivantes : + Utilise un volume de données Amazon EBS plus petit (20 Gio) afin de réduire les coûts. + Formate et configure le stockage NVMe local pour une utilisation éphémère des données. Cela inclut la configuration d'une matrice RAID 0 s'il existe plusieurs NVMe disques. + Lorsque la NVMe capacité locale `ephemeralStorage.size` est égale ou supérieure, les actions suivantes se produisent : + Le mode automatique ignore le petit volume EBS. + Le NVMe ou les disques sont exposés directement à votre charge de travail. + Le mode automatique d'Amazon EKS ne prend pas en charge les actions suivantes du service d'injection de AWS défauts : + `ec2:RebootInstances` + `ec2:SendSpotInstanceInterruptions` + `ec2:StartInstances` + `ec2:StopInstances` + `ec2:TerminateInstances` + `ec2:PauseVolumeIO` + Le mode automatique d'Amazon EKS prend en charge les actions du Pod EKS du service d'injection de AWS défauts. Pour plus d'informations, consultez les sections [Gestion des expériences du service d'injection de défauts](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html) et [Utilisation des actions AWS FIS aws:eks:pod](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html#configure-service-account) dans le guide de l' AWS utilisateur de Resilience Hub. + Vous n’avez pas besoin d’installer le `Neuron Device Plugin` sur les nœuds du mode automatique EKS. Cependant, si votre cluster contient d’autres types de nœuds, vous devez configurer le plug-in Neuron Device pour qu’il ne s’exécute pas sur les nœuds du mode automatique. Pour de plus amples informations, veuillez consulter [Contrôle du déploiement d’une charge de travail sur les nœuds du mode automatique EKS](associate-workload.md). # Informations sur les identités et l’accès dans le mode automatique EKS Cette rubrique décrit les rôles et autorisations de gestion des identités et des accès (IAM) requis pour utiliser le mode automatique EKS. Le mode automatique EKS utilise deux rôles IAM principaux : un rôle IAM de cluster et un rôle IAM de nœud. Ces rôles fonctionnent conjointement avec l’identité du pod EKS et les entrées d’accès EKS pour assurer une gestion complète des accès aux clusters EKS. Lorsque vous configurez le mode automatique d'EKS, vous devez configurer ces rôles IAM avec des autorisations spécifiques qui permettent aux AWS services d'interagir avec les ressources de votre cluster. Ces autorisations couvrent la gestion des ressources de calcul, des volumes de stockage, des équilibreurs de charge et des composants réseau. La compréhension de la configuration de ces rôles est essentielle pour garantir le bon fonctionnement et la sécurité du cluster. En mode automatique d'EKS, les rôles AWS IAM sont automatiquement mappés aux autorisations Kubernetes via les entrées d'accès EKS, ce qui élimine le besoin de configuration manuelle ou de liaisons personnalisées. `aws-auth` ConfigMaps Lorsque vous créez un nouveau cluster en mode automatique, EKS crée automatiquement les autorisations Kubernetes correspondantes à l'aide des entrées Access, garantissant ainsi que les AWS services et les composants du cluster disposent des niveaux d'accès appropriés au sein du système d'autorisation AWS et du système d'autorisation Kubernetes. Cette intégration automatisée réduit la complexité de la configuration et aide à prévenir les problèmes d’autorisations fréquemment rencontrés lors de la gestion des clusters EKS. ## Rôle IAM du cluster Le rôle Cluster IAM est un rôle AWS Identity and Access Management (IAM) utilisé par Amazon EKS pour gérer les autorisations pour les clusters Kubernetes. Ce rôle accorde à Amazon EKS les autorisations nécessaires pour interagir avec d'autres AWS services au nom de votre cluster et est automatiquement configuré avec des autorisations Kubernetes à l'aide des entrées d'accès EKS. + Vous devez associer des politiques AWS IAM à ce rôle. + Le mode automatique EKS attache automatiquement les autorisations Kubernetes à ce rôle via les entrées d’accès EKS. + Avec le mode automatique d'EKS, AWS suggère de créer un seul rôle IAM de cluster par AWS compte. + AWS suggère de nommer ce rôle`AmazonEKSAutoClusterRole`. + Ce rôle nécessite des autorisations pour plusieurs AWS services afin de gérer les ressources, notamment les volumes EBS, les Elastic Load Balancers et EC2 les instances. + La configuration suggérée pour ce rôle inclut plusieurs politiques IAM AWS gérées, liées aux différentes fonctionnalités du mode automatique d'EKS. + `AmazonEKSComputePolicy` + `AmazonEKSBlockStoragePolicy` + `AmazonEKSLoadBalancingPolicy` + `AmazonEKSNetworkingPolicy` + `AmazonEKSClusterPolicy` Pour plus d'informations sur le rôle IAM du cluster et les politiques IAM AWS gérées, voir : + [AWS politiques gérées pour Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md) + [Rôle IAM de cluster Amazon EKS](cluster-iam-role.md) Pour plus d’informations sur les autorisations d’accès Kubernetes, consultez : + [Vérification des autorisations des stratégies d’accès](access-policy-permissions.md) ## Rôle IAM de nœud Le rôle Node IAM est un rôle AWS Identity and Access Management (IAM) utilisé par Amazon EKS pour gérer les autorisations des nœuds de travail dans les clusters Kubernetes. Ce rôle accorde aux EC2 instances exécutées en tant que nœuds Kubernetes les autorisations nécessaires pour interagir avec les AWS services et les ressources, et est automatiquement configuré avec les autorisations RBAC Kubernetes à l'aide des entrées d'accès EKS. + Vous devez associer des politiques AWS IAM à ce rôle. + Le mode automatique EKS attache automatiquement ces autorisations Kubernetes RBAC à ce rôle via les entrées d’accès EKS. + AWS suggère de nommer ce rôle`AmazonEKSAutoNodeRole`. + Avec le mode automatique d'EKS, AWS suggère de créer un rôle IAM de nœud unique par AWS compte. + Ce rôle dispose d’autorisations limitées. Les principales autorisations incluent la possibilité d’assumer un rôle d’identité du pod et l’autorisation d’extraire des images depuis ECR. + AWS suggère les politiques IAM AWS gérées suivantes : + `AmazonEKSWorkerNodeMinimalPolicy` + `AmazonEC2ContainerRegistryPullOnly` Pour plus d'informations sur le rôle IAM du cluster et les politiques IAM AWS gérées, voir : + [AWS politiques gérées pour Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md) + [Rôle IAM de nœud Amazon EKS](create-node-role.md) Pour plus d’informations sur les autorisations d’accès Kubernetes, consultez : + [Vérification des autorisations des stratégies d’accès](access-policy-permissions.md) ## Rôle lié à un service Amazon EKS utilise un rôle lié à un service (Service-Linked Role, SLR) pour certaines opérations. Un rôle lié à un service est un type unique de rôle IAM lié directement à Amazon EKS. Les rôles liés à un service sont prédéfinis par Amazon EKS et incluent toutes les autorisations requises par le service pour appeler d'autres AWS services en votre nom. AWS crée et configure automatiquement le reflex. Vous ne pouvez supprimer un SLR qu’après avoir supprimé les ressources associées. Vos ressources Amazon EKS sont ainsi protégées, car vous ne pouvez pas involontairement supprimer l’autorisation d’accéder aux ressources. La politique SLR accorde à Amazon EKS l'autorisation d'observer et de supprimer les principaux composants de l'infrastructure : EC2 ressources (instances, interfaces réseau, groupes de sécurité), ressources ELB (équilibreurs de charge, groupes cibles), CloudWatch fonctionnalités (journalisation et métriques) et rôles IAM avec le préfixe « eks ». Il permet également la mise en réseau de terminaux privés via l'association de VPC/hosted zones et inclut des autorisations pour la EventBridge surveillance et le nettoyage des ressources étiquetées EKS. Pour en savoir plus, consultez : + [AWS politique gérée : Amazon EKSService RolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy) + [Autorisations du rôle lié à un service pour Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) ## AWS Balises personnalisées pour les ressources EKS Auto Par défaut, les politiques gérées liées au mode automatique d'EKS n'autorisent pas l'application de balises définies par l'utilisateur aux AWS ressources provisionnées en mode automatique. Si vous souhaitez appliquer des balises définies par l'utilisateur aux AWS ressources, vous devez attribuer des autorisations supplémentaires au rôle IAM du cluster avec des autorisations suffisantes pour créer et modifier des balises sur les AWS ressources. Voici un exemple de politique qui autorisera un accès illimité au balisage : ### Voir un exemple de stratégie de balisage personnalisée ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Compute", "Effect": "Allow", "Action": [ "ec2:CreateFleet", "ec2:RunInstances", "ec2:CreateLaunchTemplate" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" }, "StringLike": { "aws:RequestTag/eks:kubernetes-node-class-name": "*", "aws:RequestTag/eks:kubernetes-node-pool-name": "*" } } }, { "Sid": "Storage", "Effect": "Allow", "Action": [ "ec2:CreateVolume", "ec2:CreateSnapshot" ], "Resource": [ "arn:aws:ec2:*:*:volume/*", "arn:aws:ec2:*:*:snapshot/*" ], "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } }, { "Sid": "Networking", "Effect": "Allow", "Action": "ec2:CreateNetworkInterface", "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" }, "StringLike": { "aws:RequestTag/eks:kubernetes-cni-node-name": "*" } } }, { "Sid": "LoadBalancer", "Effect": "Allow", "Action": [ "elasticloadbalancing:CreateLoadBalancer", "elasticloadbalancing:CreateTargetGroup", "elasticloadbalancing:CreateListener", "elasticloadbalancing:CreateRule", "ec2:CreateSecurityGroup" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } }, { "Sid": "ShieldProtection", "Effect": "Allow", "Action": [ "shield:CreateProtection" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } }, { "Sid": "ShieldTagResource", "Effect": "Allow", "Action": [ "shield:TagResource" ], "Resource": "arn:aws:shield::*:protection/*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } } ] } ``` ## Référence de stratégie d’accès Pour plus d’informations sur les autorisations Kubernetes utilisées par le mode automatique EKS, consultez [Vérification des autorisations des stratégies d’accès](access-policy-permissions.md). # Informations sur le réseau VPC et l’équilibrage de charge dans le mode automatique EKS Cette rubrique explique comment configurer les fonctionnalités de réseau du cloud privé virtuel (VPC) et d’équilibrage de charge dans le mode automatique EKS. Même si le mode automatique EKS gère automatiquement la plupart des composants réseau, vous pouvez tout de même personnaliser certains aspects de la configuration réseau de votre cluster à l’aide de ressources `NodeClass` et d’annotations d’équilibreur de charge. Lorsque vous utilisez le mode automatique EKS, il AWS gère la configuration de l'interface réseau de conteneurs VPC (CNI) et le provisionnement de l'équilibreur de charge pour votre cluster. Vous pouvez influencer le comportement du réseau en définissant des objets `NodeClass` et en appliquant des annotations spécifiques à vos ressources Service et Ingress, tout en conservant le modèle opérationnel automatisé fourni par le mode automatique EKS. ## Fonctionnalité de réseau Le mode automatique EKS introduit une nouvelle fonctionnalité de réseau qui gère le réseau des nœuds et des pods. Vous pouvez la configurer en créant un objet Kubernetes `NodeClass`. Les options de configuration du AWS VPC CNI précédent ne s'appliqueront pas au mode automatique EKS. ### Configuration du réseau avec une `NodeClass` La ressource `NodeClass` dans le mode automatique EKS permet de personnaliser certains aspects de la fonctionnalité de réseau. Grâce à `NodeClass`, vous pouvez définir la sélection des groupes de sécurité, contrôler le placement des nœuds dans les sous-réseaux du VPC ,définir des politiques SNAT, configurer des politiques réseau et activer la journalisation des événements réseau. Cette approche maintient le modèle opérationnel automatisé du mode automatique EKS, tout en offrant une flexibilité de personnalisation du réseau. Vous pouvez utiliser une `NodeClass` pour : + Sélectionner un groupe de sécurité pour les nœuds + Contrôler la manière dont les nœuds sont placés sur les sous-réseaux VPC + Définisser la politique SNAT du nœud sur `random` ou `disabled` + Activer les politiques *réseau* Kubernetes, notamment : + Définir la politique réseau sur Refuser ou Autoriser par défaut + Activer la journalisation des événements réseau dans un fichier. + Isoler le trafic des pods du trafic des nœuds en attachant des pods à différents sous-réseaux. Découvrez comment [créer un Amazon EKS NodeClass](create-node-class.md). ### Considérations Le mode automatique EKS prend en charge : + Politiques réseau EKS. + Les options `HostPort` et `HostNetwork` pour les pods Kubernetes. + Nœuds et pods dans des sous-réseaux publics ou privés. + Mise en cache des requêtes DNS sur le nœud. Le mode automatique EKS ne prend **pas** en charge : + Groupes de sécurité par pod (SGPP). Pour appliquer des groupes de sécurité distincts au trafic du pod en mode automatique, utilisez `podSecurityGroupSelectorTerms` `NodeClass` plutôt le. Pour de plus amples informations, veuillez consulter [Sous-réseaux et groupes de sécurité distincts pour les pods](create-node-class.md#pod-subnet-selector). + Réseau personnalisé dans la `ENIConfig`. Possibilité de placer des pods dans plusieurs sous-réseaux ou de les isoler complètement du trafic des nœuds via [Sous-réseaux et groupes de sécurité distincts pour les pods](create-node-class.md#pod-subnet-selector). + Configurations Warm IP, Warm Prefix et Warm ENI. + Configuration minimale des cibles IP. + Autres configurations prises en charge par le AWS VPC CNI open source. + Configurations de politique réseau telles que la personnalisation du temporisateur Conntrack (la valeur par défaut est 300 s). + Exportation des journaux d'événements réseau vers CloudWatch. ### Gestion des ressources réseau Le mode automatique EKS gère les préfixes, l'adressage IP et la gestion de l'interface réseau en surveillant les NodeClass ressources pour les configurations réseau. Le service exécute automatiquement plusieurs opérations essentielles : **Délégation de préfixes** Le mode automatique d'EKS utilise par défaut la délégation de préfixes (préfixes /28) pour la mise en réseau des pods et gère un pool prédéfini de ressources IP qui évolue en fonction du nombre de pods planifiés. Lorsque la fragmentation du sous-réseau du pod est détectée, le mode automatique provisionne les adresses IP secondaires (/32). Grâce à cet algorithme de mise en réseau de pods par défaut, le mode automatique calcule le nombre maximum de pods par nœud en fonction du nombre de ENIs pods IPs pris en charge par type d'instance (en supposant le pire des cas de fragmentation). Pour plus d'informations sur Max ENIs et IPs par type d'instance, consultez la section [Nombre maximal d'adresses IP par interface réseau](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AvailableIpPerENI.html) dans le guide de l'utilisateur EC2. Les familles d'instances de nouvelle génération (Nitro v6 et versions ultérieures) ont généralement augmenté ENIs et IPs par type d'instance, et le mode automatique ajuste le calcul du nombre maximum de pods en conséquence. Pour les IPv6 clusters, seule la délégation de préfixes est utilisée, et le mode automatique utilise toujours une limite maximale de 110 pods par nœud. **Gestion de la stabilisation** Le service implémente un pool de recharge pour les préfixes ou IPv4 les adresses secondaires qui ne sont plus utilisés. Une fois le temps de stabilisation expiré, ces ressources sont renvoyées au VPC. Cependant, si des pods réutilisent ces ressources pendant le temps de stabilisation, elles sont restaurées à partir du groupe de stabilisation. **IPv6 Support** Pour les IPv6 clusters, le mode automatique EKS fournit un `/80` IPv6 préfixe par nœud sur l'interface réseau principale. Lors de l'utilisation`podSubnetSelectorTerms`, le préfixe est plutôt alloué sur une interface réseau secondaire dans le sous-réseau du pod. Le service assure également une gestion et une récupération de mémoire appropriées de toutes les interfaces réseau. ## Équilibrage de charge Vous configurez les équilibreurs de charge AWS élastiques fournis par EKS Auto Mode à l'aide d'annotations sur les ressources de service et d'entrée. Pour plus d’informations, consultez [Créez un IngressClass pour configurer un Application Load Balancer](auto-configure-alb.md) ou [Utilisation des annotations de service pour configurer les équilibreurs de charge Network Load Balancer](auto-configure-nlb.md). ### Considérations relatives à l’équilibrage de charge avec le mode automatique EKS + Le mode de ciblage par défaut est le mode IP, et non le mode instance. + Le mode automatique EKS prend uniquement en charge le mode groupe de sécurité pour les équilibreurs de charge réseau Network Load Balancer. + AWS ne prend pas en charge la migration des équilibreurs de charge depuis le contrôleur d'équilibrage de AWS charge autogéré vers le mode automatique EKS. + Le champ `networking.ingress.ipBlock` dans la spécification `TargetGroupBinding` n’est pas pris en charge. + Si vos composants master utilisent des groupes de sécurité personnalisés (et non ceux suivant le modèle de nommage `eks-cluster-sg- `), le rôle de votre cluster doit disposer d’autorisations IAM supplémentaires. La politique gérée par EKS par défaut permet uniquement à EKS de modifier les groupes de sécurité nommés `eks-cluster-sg-`. Sans l'autorisation de modifier vos groupes de sécurité personnalisés, EKS ne peut pas ajouter les règles d'entrée requises permettant au ALB/NLB trafic d'atteindre vos modules. #### Considérations relatives au CoreDNS Le mode automatique EKS n'utilise pas le déploiement CoreDNS traditionnel pour fournir une résolution DNS au sein du cluster. Au lieu de cela, les nœuds en mode automatique utilisent CoreDNS s'exécutant en tant que service système directement sur chaque nœud. Si vous passez d'un cluster traditionnel en mode automatique, vous pouvez supprimer le déploiement CoreDNS de votre cluster une fois que vos charges de travail ont été déplacées vers les nœuds du mode automatique. **Important** Si vous prévoyez de gérer un cluster avec des nœuds en mode automatique et en mode non automatique, vous devez conserver le déploiement CoreDNS. Les nœuds non en mode automatique s'appuient sur les modules CoreDNS traditionnels pour la résolution DNS, car ils ne peuvent pas accéder au service DNS au niveau des nœuds fourni par le mode automatique.