**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. # Choix du type d’instance Amazon EC2 optimal pour les nœuds Amazon EC2 fournit un large choix de types d'instance pour les composants master. Chaque type d'instance offre des capacités de calcul, de mémoire, de stockage et de réseau différentes. Chaque instance est également regroupée dans une famille d'instances en fonction de ces capacités. Pour la liste complète, consultez [Types d’instances disponibles](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#AvailableInstanceTypes) dans le *Guide de l’utilisateur Amazon EC2*. Amazon EKS publie plusieurs variantes d'Amazon EC2 AMIs pour permettre le support. Pour vous assurer que le type d'instance que vous sélectionnez est compatible avec Amazon EKS, tenez compte des critères suivants. + Tous les Amazon EKS AMIs ne prennent actuellement pas en charge `mac` cette famille. + Arm et Amazon EKS non accéléré AMIs ne prennent pas en charge les`g3`, `g4``inf`, et `p` les familles. + Amazon EKS accéléré AMIs ne prend pas en charge les `a``c`,`hpc`,`m`, et `t` les familles. + Pour les instances basées sur ARM, Amazon Linux 2023 (AL2023) ne prend en charge que les types d'instances qui utilisent des processeurs Graviton2 ou version ultérieure. AL2023 ne prend pas en charge `A1` les instances. Lorsque vous choisissez entre les types d'instances pris en charge par Amazon EKS, tenez compte des fonctionnalités suivantes de chaque type. **Nombre d'instances dans un groupe de nœuds** De manière générale, il est préférable d’utiliser moins d’instances, mais plus grandes, surtout si vous avez de nombreux DaemonSets. Chaque instance nécessitant des appels API vers le serveur d'API, plus le nombre d'instances est élevé, plus la charge sur le serveur d'API est importante. **Système d’exploitation** Examinez les types d'instances pris en charge pour [Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html), [Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html) et [Bottlerocket](https://aws.amazon.com/bottlerocket/faqs/). Avant de créer des instances Windows, consultez [Déploiement de nœuds Windows sur les clusters EKS](windows-support.md). **Architecture matérielle** Avez-vous besoin d’une architecture x86 ou Arm ? Avant de déployer des instances Arm, consultez [Arm Amazon Linux optimisé pour Amazon EKS AMIs](eks-optimized-ami.md#arm-ami). Avez-vous besoin d’instances basées sur le système Nitro ([Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances) ou [Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances)) ou disposant de capacités [accélérées](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/accelerated-computing-instances.html) ? Si vous avez besoin de fonctionnalités accélérées, vous ne pouvez utiliser Linux qu'avec Amazon EKS. **Nombre maximal de pods** Comme chaque pod reçoit sa propre adresse IP, le nombre d’adresses IP prises en charge par un type d’instance est un facteur déterminant pour savoir combien de pods peuvent s’exécuter sur cette instance. Pour déterminer manuellement combien de pods un type d’instance peut prendre en charge, consultez . AWS Les types [d'instances Nitro System](https://aws.amazon.com/ec2/nitro/) prennent éventuellement en charge un plus grand nombre d'adresses IP que les types d'instances autres que Nitro System. Cependant, toutes les adresses IP attribuées à une instance ne sont pas disponibles pour les pods. Pour attribuer un nombre significativement plus élevé d'adresses IP à vos instances, la version `1.9.0` ou ultérieure du module complémentaire Amazon VPC CNI doit être installée dans votre cluster et configurée de manière appropriée. Pour de plus amples informations, veuillez consulter [Attribution de davantage d’adresses IP aux nœuds Amazon EKS avec des préfixes](cni-increase-ip-addresses.md). Pour attribuer le plus grand nombre d'adresses IP à vos instances, vous devez avoir installé la version `1.10.1` ou une version ultérieure du module complémentaire Amazon VPC CNI dans votre cluster et déployer le cluster avec la famille `IPv6`. **Famille IP** Vous pouvez utiliser n’importe quel type d’instance pris en charge lorsque vous utilisez la famille `IPv4` pour un cluster, ce qui permet à votre cluster d’attribuer des adresses `IPv4` privées à vos pods et services. Mais si vous souhaitez utiliser la famille `IPv6` pour votre cluster, alors vous devez utiliser les types d'instance [AWS Nitro System](https://aws.amazon.com/ec2/nitro/) ou les types d'instance matériel nu. Seul `IPv4` est pris en charge pour les instances Windows. Votre cluster doit utiliser la version `1.10.1` ou une version ultérieure du module complémentaire Amazon VPC CNI. Pour plus d'informations sur l'utilisation de `IPv6`, consultez [En savoir plus sur IPv6 les adresses des clusters, des pods et des services](cni-ipv6.md). **Version du module complémentaire Amazon VPC CNI que vous exécutez** La dernière version du [plug-in CNI Amazon VPC pour Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) prend en charge [ces types d'instance](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go). Il peut être nécessaire de mettre à jour la version de votre module complémentaire CNI Amazon VPC pour bénéficier des derniers types d'instance pris en charge. Pour de plus amples informations, veuillez consulter [Attribuer IPs à des pods avec l'Amazon VPC CNI](managing-vpc-cni.md). La dernière version prend en charge les dernières fonctions pour une utilisation avec Amazon EKS. Les versions antérieures ne prennent pas en charge toutes les fonctionnalités. Vous pouvez afficher les fonctions prises en charge par les différentes versions dans [Changelog](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/CHANGELOG.md) sur GitHub. **Région  AWS dans laquelle vous créez vos nœuds** Tous les types d'instances ne sont pas disponibles dans toutes les AWS régions. **Si vous utilisez des groupes de sécurité pour les pods** Si vous utilisez des groupes de sécurité pour les pods, seuls certains types d’instances sont pris en charge. Pour de plus amples informations, veuillez consulter [Attribution de groupes de sécurité à des pods individuels](security-groups-for-pods.md). ## Comment est déterminé MaxPods La `maxPods` valeur finale appliquée à un nœud dépend de plusieurs composants qui interagissent dans un ordre de priorité spécifique. La compréhension de cet ordre vous permet d'éviter les comportements inattendus lors de la personnalisation`maxPods`. **Ordre de priorité (du plus élevé au plus bas) :** 1. **Application des groupes de nœuds gérés** : lorsque vous utilisez un groupe de nœuds gérés sans [AMI personnalisée](launch-templates.md#launch-template-custom-ami), Amazon EKS impose un plafonnement `maxPods` des données utilisateur du nœud. Pour les instances avec moins de 30 VCPUs, le plafond est`110`. Pour les instances avec une tension supérieure à 30 VCPUs, le plafond est fixé à`250`. Cette valeur a priorité sur toute autre `maxPods` configuration, y compris`maxPodsExpression`. 1. **`maxPods`configuration kubelet** — Si vous définissez `maxPods` directement dans la configuration kubelet (par exemple, via un modèle de lancement avec une AMI personnalisée), cette valeur a priorité sur. `maxPodsExpression` 1. **nodeadm `maxPodsExpression`** — Si vous utilisez [https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/examples/#defining-a-max-pods-expression](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/examples/#defining-a-max-pods-expression)in your`NodeConfig`, nodeadm évalue l'expression à calculer. `maxPods` Cela n'est efficace que lorsque la valeur n'est pas déjà définie par une source de priorité supérieure. 1. **Calcul par défaut basé sur l'ENI** : si aucune autre valeur n'est définie, l'AMI calcule en `maxPods` fonction du nombre d'interfaces réseau élastiques et d'adresses IP prises en charge par le type d'instance. Cela équivaut à la formule`(number of ENIs × (IPs per ENI − 1)) + 2`. Les `+ 2` comptes Amazon VPC CNI s'`kube-proxy`exécutent sur chaque nœud, qui ne consomment pas d'adresse IP de pod. **Important** Si vous utilisez un groupe de nœuds gérés et que vous le définissez `maxPodsExpression` dans votre`NodeConfig`, l'application du groupe de nœuds gérés remplace votre expression. Pour utiliser une `maxPods` valeur personnalisée avec des groupes de nœuds gérés, vous devez spécifier une AMI personnalisée dans votre modèle de lancement et la définir `maxPods` directement. Pour de plus amples informations, veuillez consulter [Personnaliser les nœuds gérés à l’aide de modèles de lancement](launch-templates.md). **Groupes de nœuds gérés et nœuds autogérés** Avec les groupes de nœuds gérés (sans AMI personnalisée), Amazon EKS injecte la `maxPods` valeur dans les données utilisateur bootstrap du nœud. Autrement dit : + La `maxPods` valeur est toujours plafonnée à `110` ou `250` en fonction de la taille de l'instance. + Toute configuration `maxPodsExpression` que vous configurez est remplacée par cette valeur injectée. + Pour utiliser une `maxPods` valeur différente, spécifiez une AMI personnalisée dans votre modèle de lancement et `--use-max-pods false` transmettez-la `--kubelet-extra-args '--max-pods=my-value'` au `bootstrap.sh` script. Pour obtenir des exemples, consultez [Personnaliser les nœuds gérés à l’aide de modèles de lancement](launch-templates.md). Avec les nœuds autogérés, vous avez un contrôle total sur le processus d'amorçage. Vous pouvez l'utiliser `maxPodsExpression` dans votre `NodeConfig` ou le passer `--max-pods` directement à`bootstrap.sh`. ## Considérations relatives au mode automatique EKS Le mode automatique EKS limite le nombre de pods sur les nœuds à la plus faible des deux valeurs suivantes : + Plafond strict de 110 pods + Le résultat du calcul du nombre maximal de pods décrit ci-dessus.