View a markdown version of this page

Création d’un pool de nœuds pour le mode automatique EKS - Amazon EKS

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.

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. Avec les NodePool ressources 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 la fonction intégrée NodePools.

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 étiquettes (préfixées pareks.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 parfaite avec les outils Kubernetes existants tout en fournissant une intégration approfondie AWS de l'infrastructure.

Créez un NodePool

Suivez ces étapes pour créer un cluster Amazon EKS NodePool pour votre cluster Amazon EKS :

  1. Créez un fichier YAML nommé nodepool.yaml avec la NodePool configuration requise. Vous pouvez utiliser l’exemple de configuration ci-dessous.

  2. Appliquez le NodePool à votre cluster :

    kubectl apply -f nodepool.yaml
  3. Vérifiez que le NodePool a été créé avec succès :

    kubectl get nodepools
  4. (Facultatif) Surveillez l' NodePool état :

    kubectl describe nodepool default

Assurez-vous que votre NodePool référence est valide NodeClass et existe dans votre cluster. NodeClass définit des AWS configurations spécifiques pour vos ressources de calcul. Pour de plus amples informations, veuillez consulter Création d’une classe de nœuds pour Amazon EKS.

Exemple 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

topologie.kubernetes. io/zone

us-east-2a

AWS région

node .kubernetes. io/instance-type

g4dn.8xlarge

AWS type d'instance

kubernetes. io/arch

amd64

Architectures définies par les valeurs GOARCH sur l’instance

charpentier. sh/capacity-type

spot

Les types de capacité comprennent spot, on-demand

eks.amazonaws. com/instance-hyperviseur

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-compatible avec le chiffrement pendant le transport

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-ebs-bandwidth

9500

Nombre maximal de mégabits d’EBS disponibles sur l’instance

eks.amazonaws. com/instance-bande passante réseau

131072

Nombre de mégabits de base 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

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.

É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 la fonction intégrée NodePools.

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 pool de nœuds intégré, celui-ci n'default NodeClass est pas automatiquement provisionné. Vous devrez créer une personnalisation NodeClass. Pour de plus amples informations, veuillez consulter Création d’une classe de nœuds pour Amazon EKS.

Présentation :

  1. Créez un cluster EKS avec les valeurs nodePools et nodeRoleArn laissées vides.

  2. Créez une NodeClass personnalisée avec un ARN de rôle de nœud

  3. Créez une entrée d’accès pour la classe de nœuds personnalisée

  4. Créez un groupe de nœuds personnalisé, comme décrit ci-dessus.

Interruption

Vous pouvez configurer le mode automatique d'EKS pour perturber les nœuds NodePool de différentes manières. 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 par le biais NodePool despec.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 dans la documentation de 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'terminationGracePeriodest pas explicitement défini sur un mode automatique EKS NodePool, le système applique automatiquement un délai de grâce de résiliation par défaut de 24 heures au délai de résiliation 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 le délai de grâce soit explicitement défini sur le NodePool ou défini par défaut sur le NodeClaim, ce qui garantit un comportement de terminaison des nœuds prévisible dans l'ensemble du cluster.