**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 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. # Création d’un pool de nœuds pour le mode automatique EKS Les groupes de nœuds Amazon EKS offrent une méthode flexible pour gérer les ressources de calcul dans votre cluster Kubernetes. Cette rubrique explique comment créer et configurer des groupes de nœuds à l’aide de Karpenter, un outil de provisionnement de nœuds qui permet d’optimiser l’étendue du cluster et l’utilisation des ressources. Grâce à la NodePool ressource de Karpenter, vous pouvez définir des exigences spécifiques pour vos ressources de calcul, notamment les types d'instances, les zones de disponibilité, les architectures et les types de capacité. Les groupes de nœuds intégrés `system` et `general-purpose` ne peuvent pas être modifiés. Vous pouvez uniquement les activer ou les désactiver. Pour de plus amples informations, veuillez consulter [Activer ou désactiver Built-in NodePools](set-builtin-node-pools.md). La NodePool spécification permet un contrôle précis des ressources de calcul de votre cluster EKS grâce à diverses étiquettes et exigences prises en charge. Il s'agit notamment d'options permettant de spécifier les catégories d'instances EC2, les configurations du processeur, les zones de disponibilité, les architectures (ARM64/AMD64) et les types de capacité (ponctuels ou à la demande). Vous pouvez également définir des limites de ressources pour l’utilisation du processeur et de la mémoire, afin que votre cluster respecte les contraintes opérationnelles requises. Le mode automatique EKS utilise des étiquettes Kubernetes reconnues afin de proposer des méthodes uniformes et standardisées d’identification des caractéristiques des nœuds. Ces étiquettes, par exemple `topology.kubernetes.io/zone` pour les zones de disponibilité et `kubernetes.io/arch` pour l’architecture du processeur, respectent les conventions établies de Kubernetes. En outre, EKS-specific les libellés (préfixés par`eks.amazonaws.com/`) étendent cette fonctionnalité avec AWS des attributs spécifiques tels que les types d'instances, les fabricants de processeurs, les capacités du GPU et les spécifications réseau. Ce système d'étiquetage standardisé permet une intégration fluide avec les outils Kubernetes existants tout en fournissant une intégration approfondie AWS de l'infrastructure. ## Créez un NodePool Pour créer un NodePool cluster Amazon EKS, procédez comme suit : 1. Créez un fichier YAML nommé `nodepool.yaml` avec la NodePool configuration requise. Vous pouvez utiliser l’exemple de configuration ci-dessous. 1. Appliquez le NodePool à votre cluster : ``` kubectl apply -f nodepool.yaml ``` 1. Vérifiez que le NodePool a été créé correctement : ``` kubectl get nodepools ``` 1. (Facultatif) Surveillez l' NodePool état : ``` kubectl describe nodepool default ``` Assurez-vous que vos NodePool références sont valides et NodeClass qu'elles existent dans votre cluster. Il NodeClass définit les configurations AWS spécifiques à vos ressources de calcul. Pour de plus amples informations, veuillez consulter [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md). ## échantillon NodePool ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: my-node-pool spec: template: metadata: labels: billing-team: my-team spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "eks.amazonaws.com/instance-category" operator: In values: ["c", "m", "r"] - key: "eks.amazonaws.com/instance-cpu" operator: In values: ["4", "8", "16", "32"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-west-2a", "us-west-2b"] - key: "kubernetes.io/arch" operator: In values: ["arm64", "amd64"] disruption: consolidationPolicy: Balanced consolidateAfter: 30s limits: cpu: "1000" memory: 1000Gi ``` ## Étiquettes prises en charge par le mode automatique EKS Le mode automatique EKS prend en charge les étiquettes bien connues suivantes. **Note** Le mode automatique EKS utilise des étiquettes différentes de celles de Karpenter. Les étiquettes associées aux instances gérées EC2 commencent par `eks.amazonaws.com`. | Étiquette | Exemple | Description | | --- | --- | --- | | topologie.kubernetes. io/zone | us-east-2a | AWS région | | node.kubernetes. io/instance-tapez | g4dn.8xlarge | AWS type d'instance | | kubernetes. io/arch | amd64 | Architectures définies par les [valeurs GOARCH](https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go#L58) sur l’instance | | charpentier. sh/capacity-tapez | spot | Les types de capacité incluent `spot``on-demand`, et`reserved`. Si vous ne spécifiez pas de type de capacité, Karpenter établit alors `reserved` `spot` des priorités. `on-demand` | | eks.amazonaws. com/instance-hyperviseur | nitro | Types d’instance utilisant un hyperviseur spécifique | | eks.amazonaws. com/compute-tapez | auto | Identifie les nœuds gérés par le mode automatique EKS | | eks.amazonaws. com/instance-pris en charge par le chiffrement en transit | true | Types d’instance prenant en charge (ou non) le chiffrement en transit | | eks.amazonaws. com/instance-catégorie | g | Types d’instance de la même catégorie, généralement la chaîne précédant le numéro de génération | | eks.amazonaws. com/instance-génération | 4 | Numéro de génération du type d’instance au sein d’une même catégorie d’instances | | eks.amazonaws. com/instance-famille | g4dn | Types d’instance présentant des propriétés similaires, mais des quantités de ressources différentes | | eks.amazonaws. com/instance-taille | 8xlarge | Types d’instance présentant des quantités de ressources similaires, mais des propriétés différentes | | eks.amazonaws. com/instance-processeur | 32 | Nombre de processeurs sur l’instance | | eks.amazonaws. com/instance-fabricant de processeurs | `aws` | Nom du fabricant du processeur | | eks.amazonaws. com/instance-mémoire | 131072 | Nombre de mébioctets de mémoire sur l’instance | | eks.amazonaws. com/instance-bande passante EBS | 9500 | Nombre [maximal de mégabits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html#ebs-optimization-performance) d’EBS disponibles sur l’instance | | eks.amazonaws. com/instance-bande passante réseau | 131072 | Nombre de [mégabits de base](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) disponibles sur l’instance | | eks.amazonaws. com/instance-nom-GPU | t4 | Nom du GPU présent sur l’instance, le cas échéant | | eks.amazonaws. com/instance-fabricant de GPU | nvidia | Nom du fabricant du GPU | | eks.amazonaws. com/instance-nombre de processeurs graphiques | 1 | Nombre de GPU présents sur l’instance | | eks.amazonaws. com/instance-mémoire GPU | 16384 | Quantité de mémoire GPU en mébioctets sur l’instance | | eks.amazonaws. com/instance-nom-local | 900 | Quantité de stockage local NVMe en gibioctets sur l’instance | | eks.amazonaws. com/capacity-interruption de réservation | true | Si la réservation de capacité est interruptible. Présent uniquement sur les nœuds dotés de`karpenter.sh/capacity-type: reserved`. | **Note** Le mode automatique EKS ne prend en charge que certains types d’instances et impose des exigences de taille minimale. Pour de plus amples informations, veuillez consulter [Référence des instances prises en charge par le mode automatique EKS](automode-learn-instances.md#auto-supported-instances). ## Étiquettes non prises en charge par le mode automatique EKS Le mode automatique EKS ne prend pas en charge les étiquettes suivantes. + Le mode automatique EKS ne prend en charge que Linux + `node.kubernetes.io/windows-build` + `kubernetes.io/os` ## Désactivation des groupes de nœuds intégrés Si vous créez des groupes de nœuds personnalisés, vous pouvez désactiver les groupes de nœuds intégrés. Pour de plus amples informations, veuillez consulter [Activer ou désactiver Built-in NodePools](set-builtin-node-pools.md). ## Cluster sans groupes de nœuds intégrés Vous pouvez créer un cluster sans groupes de nœuds intégrés. Cela est utile si votre organisation a mis en place des groupes de nœuds personnalisés. **Note** Lorsque vous créez un cluster sans pools de nœuds intégrés, celui-ci n'`default` NodeClass est pas automatiquement provisionné. Vous devez créer une personnalisation NodeClass. Pour de plus amples informations, veuillez consulter [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md). **Présentation :** 1. Créez un cluster EKS avec les deux `nodePools` et `nodeRoleArn` les valeurs vides. + Exemple eksctl `autoModeConfig` : ``` autoModeConfig: enabled: true nodePools: [] # Do not set a nodeRoleARN ``` Pour de plus amples informations, consultez [Création d’un cluster du mode automatique EKS à l’aide de la CLI eksctl](automode-get-started-eksctl.md). 1. Créez une NodeClass personnalisée avec un ARN de rôle de nœud + Pour de plus amples informations, consultez [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md). 1. Créez une entrée d’accès pour la classe de nœuds personnalisée + Pour de plus amples informations, consultez [Création d’une entrée d’accès pour la classe de nœuds](create-node-class.md#auto-node-access-entry). 1. Créez un groupe de nœuds personnalisé, comme décrit ci-dessus. ## Interruption Vous pouvez configurer le mode automatique EKS pour perturber les nœuds via vous NodePool de plusieurs manières. Vous pouvez utiliser `spec.disruption.consolidationPolicy`, `spec.disruption.consolidateAfter` ou `spec.template.spec.expireAfter`. Vous pouvez également limiter le débit de l'interruption du mode automatique EKS par le biais des NodePool « `spec.disruption.budgets` ». Vous pouvez également contrôler les fenêtres temporelles et le nombre de nœuds interrompus simultanément. Pour obtenir des instructions sur la configuration de ce comportement, consultez la section [Interruption](https://karpenter.sh/docs/concepts/disruption/) dans la documentation de Karpenter. Le `consolidationPolicy` champ accepte trois valeurs : + `WhenEmpty`— Consolide uniquement les nœuds vides, de sorte que les charges de travail en cours d'exécution ne soient jamais perturbées. + `WhenEmptyOrUnderutilized`— Consolide de manière agressive pour des raisons de coût, perturbant les charges de travail chaque fois que les pods d'un nœud peuvent être remballés à moindre coût. + `Balanced`— Évalue chaque action de consolidation en évaluant le coût des interruptions par rapport aux économies de coûts. Ignore les actions lorsque les perturbations l'emportent sur les économies. Pour plus de détails sur chaque valeur, consultez la section [ Disruption ](https://karpenter.sh/docs/concepts/disruption/) dans la documentation Karpenter. Vous pouvez configurer l’interruption pour les groupes de nœuds afin de : + Identifier les instances sous-utilisées et consolider les charges de travail. + Créer un budget d’interruption pour limiter la fréquence des arrêts de nœuds liés à la dérive, au vidage ou à la consolidation. Par défaut, le mode automatique EKS : + Consolide les instances sous-utilisées. + Met fin aux instances au bout de 336 heures. + Définit un budget d’interruption unique correspondant à 10 % des nœuds. + Permet le remplacement des nœuds en cas de dérive lors de la publication d’une nouvelle AMI du mode automatique (environ une fois par semaine). ## Délai de grâce avant terminaison Lorsque a n'`terminationGracePeriod`est pas explicitement défini dans un mode EKS Auto NodePool, le système applique automatiquement une période de grâce de résiliation par défaut de 24 heures au mode associé NodeClaim. Les clients du mode automatique EKS ne verront pas de valeur `terminationGracePeriod` par défaut dans leurs NodePool configurations personnalisées, mais ils observeront cette valeur par défaut sur le NodeClaim. La fonctionnalité reste cohérente, que la période de grâce soit explicitement définie sur le NodePool ou par défaut sur le NodeClaim, garantissant ainsi un comportement de terminaison prévisible des nœuds sur l'ensemble du cluster.