Aidez à améliorer cette page
Pour contribuer à ce guide de l’utilisateur, cliquez sur le lien Modifier cette page sur GitHub qui se trouve dans le volet droit de chaque page.
Create a Node Pool for EKS Auto Mode
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 ressource NodePool de Karpenter, vous pouvez définir des exigences précises 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, consultez Activer ou désactiver les groupes de nœuds créés.
La spécification NodePool permet un contrôle précis des ressources de cluster computing EKS à l’aide de diverses étiquettes et exigences prises en charge. Ces options incluent la définition des catégories d’instances EC2, la configuration du processeur, la sélection des zones de disponibilité, le choix de l’architecture (ARM64 ou AMD64) et le type de capacité (Spot 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. De plus, des étiquettes spécifiques à EKS (préfixées par eks.amazonaws.com/) étendent cette fonctionnalité en ajoutant des attributs spécifiques à AWS, tels que les types d’instance, les fabricants de processeurs, les capacités GPU et les spécifications réseau. Ce système d’étiquetage standardisé assure une intégration fluide avec les outils Kubernetes existants, tout en offrant une intégration approfondie à l’infrastructure AWS.
Création d’un NodePool
Pour créer un NodePool pour votre cluster Amazon EKS, procédez comme suit :
-
Créez un fichier YAML nommé
nodepool.yamlcontenant la configuration requise de votre NodePool. Vous pouvez utiliser l’exemple de configuration ci-dessous. -
Appliquez le NodePool à votre cluster :
kubectl apply -f nodepool.yaml -
Vérifiez que le NodePool a été créé avec succès :
kubectl get nodepools -
(Facultatif) Surveillez l’état du NodePool :
kubectl describe nodepool default
Assurez-vous que votre NodePool fait référence à un NodeClass valide existant dans votre cluster. La NodeClass définit les configurations spécifiques à AWS pour vos ressources de calcul. Pour de plus amples informations, consultez Création d’une classe de nœuds pour Amazon EKS.
Exemple de 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"] 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 |
|---|---|---|
|
topology.kubernetes.io/zone |
us-east-2a |
AWS région |
|
node.kubernetes.io/instance-type |
g4dn.8xlarge |
Type d'instance AWS |
|
kubernetes.io/arch |
amd64 |
Architectures définies par les valeurs GOARCH |
|
karpenter.sh/capacity-type |
spot |
Les types de capacité comprennent |
|
eks.amazonaws.com/instance-hypervisor |
nitro |
Types d’instance utilisant un hyperviseur spécifique |
|
eks.amazonaws.com/compute-type |
auto |
Identifie les nœuds gérés par le mode automatique EKS |
|
eks.amazonaws.com/instance-encryption-in-transit-supported |
true |
Types d’instance prenant en charge (ou non) le chiffrement en transit |
|
eks.amazonaws.com/instance-category |
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-generation |
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-family |
g4dn |
Types d’instance présentant des propriétés similaires, mais des quantités de ressources différentes |
|
eks.amazonaws.com/instance-size |
8xlarge |
Types d’instance présentant des quantités de ressources similaires, mais des propriétés différentes |
|
eks.amazonaws.com/instance-cpu |
32 |
Nombre de processeurs sur l’instance |
|
eks.amazonaws.com/instance-cpu-manufacturer |
|
Nom du fabricant du processeur |
|
eks.amazonaws.com/instance-memory |
131072 |
Nombre de mébioctets de mémoire sur l’instance |
|
eks.amazonaws.com/instance-ebs-bandwidth |
9500 |
Nombre maximal de mégabits d’EBS disponibles sur l’instance |
|
eks.amazonaws.com/instance-network-bandwidth |
131072 |
Nombre de mégabits de base disponibles sur l’instance |
|
eks.amazonaws.com/instance-gpu-name |
t4 |
Nom du GPU présent sur l’instance, le cas échéant |
|
eks.amazonaws.com/instance-gpu-manufacturer |
nvidia |
Nom du fabricant du GPU |
|
eks.amazonaws.com/instance-gpu-count |
1 |
Nombre de GPU présents sur l’instance |
|
eks.amazonaws.com/instance-gpu-memory |
16384 |
Quantité de mémoire GPU en mébioctets sur l’instance |
|
eks.amazonaws.com/instance-local-nvme |
900 |
Quantité de stockage local NVMe en gibioctets sur l’instance |
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, consultez Référence des instances prises en charge par le mode automatique EKS.
É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, consultez Activer ou désactiver les groupes de nœuds créés.
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 groupes de nœuds intégrés, la NodeClass default n’est pas provisionnée automatiquement. Vous devrez créer une NodeClass personnalisée. Pour de plus amples informations, consultez Création d’une classe de nœuds pour Amazon EKS.
Présentation :
-
Créez un cluster EKS avec les valeurs
nodePoolsetnodeRoleArnlaissées vides.-
Exemple eksctl
autoModeConfig:autoModeConfig: enabled: true nodePools: [] # Do not set a nodeRoleARNPour plus d’informations, consultez Création d’un cluster du mode automatique EKS à l’aide de la CLI eksctl.
-
-
Créez une NodeClass personnalisée avec un ARN de rôle de nœud
-
Pour plus d’informations, consultez Création d’une classe de nœuds pour Amazon EKS.
-
-
Créez une entrée d’accès pour la classe de nœuds personnalisée
-
Pour plus d’informations, consultez Création d’une entrée d’accès pour la classe de nœuds.
-
-
Créez un groupe de nœuds personnalisé, comme décrit ci-dessus.
Interruption
Vous pouvez configurer le mode automatique EKS afin de gérer l’interruption des nœuds à partir de votre NodePool de plusieurs façons. Vous pouvez utiliser spec.disruption.consolidationPolicy, spec.disruption.consolidateAfter ou spec.template.spec.expireAfter. Vous pouvez également limiter le taux d’interruption du mode automatique EKS à l’aide du paramètre spec.disruption.budgets du NodePool. 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
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 le terminationGracePeriod n’est pas explicitement définie dans une NodePool EKS Auto, le système applique automatiquement un délai de grâce de 24 heures à la NodeClaim associée. Même si les utilisateurs d’EKS Auto ne verront pas un terminationGracePeriod défini par défaut dans leurs configurations personnalisées de NodePool, ils pourront l’observer dans la NodeClaim. La fonctionnalité demeure identique, qu’elle soit définie explicitement dans la NodePool ou appliquée par défaut dans la NodeClaim, ce qui garantit un comportement prévisible lors de la terminaison des nœuds dans le cluster.