View a markdown version of this page

Gérez le calcul des AI/ML charges de travail avec EKS Auto Mode et Karpenter - 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 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.

Gérez le calcul des AI/ML charges de travail avec EKS Auto Mode et Karpenter

Astuce

Inscrivez-vous aux prochains AI/ML ateliers Amazon EKS.

Cette section explique comment gérer le calcul accéléré (AWS Trainium, GPU NVIDIA) pour la formation à l'IA et les charges de travail d'inférence à l'aide du mode automatique Amazon EKS ou de Karpenter autogéré.

EKS Auto Mode et Karpenter prennent en charge deux modes de provisionnement : le provisionnement dynamique et le provisionnement statique. Grâce au provisionnement dynamique, EKS Auto Mode et Karpenter provisionnent et dimensionnent des instances de calcul accélérées au fur et à mesure que les charges de travail sont planifiées sur le cluster. Avec le provisionnement statique, EKS Auto Mode et Karpenter provisionnent et gèrent un nombre fixe de nœuds. Le provisionnement dynamique et statique peut être utilisé dans le même cluster pour maintenir un pool de capacité de référence constant tout en s'adaptant aux demandes de charge de travail.

EKS Auto Mode et Karpenter prennent en charge les quatre options d'achat de capacité (SpotOn-Demand, Capacity Blocks et ODCR) et provisionnent toujours la capacité réservée en premier, suivie de Spot ou. On-Demand

EKS Auto Mode contre Karpenter

Les deux approches partagent l' NodePool API, mais elles diffèrent en termes de propriété opérationnelle, d'API de ressources, de prise en charge du système d'exploitation, de gestion des interruptions ponctuelles et de flexibilité de configuration.

Fonctionnalité Mode automatique EKS Self-managed Charpentier

Idéal pour

Les équipes qui préfèrent une infrastructure gérée avec un minimum de frais opérationnels

Les équipes qui préfèrent un contrôle total sur le cycle de vie des nœuds, les AMI, le réglage du système d'exploitation et l'application de correctifs.

Modèle opérationnel

AWS fournit et gère le contrôleur Karpenter, GPU/Trainium les pilotes, les plug-ins de périphériques, les correctifs du système d'exploitation et la gestion des interruptions ponctuelles.

Vous installez et utilisez le contrôleur Karpenter dans votre cluster et vous êtes propriétaire des GPU/Trainium pilotes, des plug-ins de périphériques, du cycle de vie de l'AMI, des correctifs et de la gestion des interruptions ponctuelles.

Options de calcul

On-Demand, Spot, ODCR, blocs de capacité pour ML

On-Demand, Spot, ODCR, blocs de capacité pour ML

API de ressources

NodePool (karpenter.sh/v1), NodeClass (eks.amazonaws.com/v1).

NodePool (karpenter.sh/v1), EC2NodeClass (karpenter.k8s.aws/v1).

Système d'exploitation Node

Bottlerocket uniquement. Dépendances GPU NVIDIA, AWS Trainium et EFA incluses.

AL2023, Bottlerocket, Windows ou votre propre AMI.

Durée de vie du nœud

Durée de vie maximale des nœuds de 21 jours pour les correctifs de sécurité. Les charges de travail doivent tolérer la rotation des nœuds.

Vous définissez le cycle de vie des nœuds NodePool expireAfter et les budgets d'interruption.

Gestion des interruptions ponctuelles

Autochtone. Aucune file d'attente SQS ni aucun gestionnaire de terminaison de nœud n'est requis.

Il est de votre responsabilité de configurer et d'activer.

Tirage rapide des conteneurs

Pull parallèle SOCI inclus dans toutes les instances des familles G, P et Trn

Il est de votre responsabilité de configurer et d'activer.

Groupes de placement EC2

Cluster, partitionner, étaler

Cluster, partitionner, étaler

Configuration de l'interface réseau

Configuration par interface pour le type interface ou EFA-only

Configuration par interface pour le type interface ou EFA-only

Réparation de nœuds

Activé par défaut, agent de surveillance des nœuds EKS inclus

Activé en option, agent de surveillance des nœuds EKS autogéré

Tarification

Frais de gestion du mode automatique EKS en plus du coût de l'instance EC2 sous-jacente.

Open source. Vous payez pour les instances EC2 sous-jacentes.

Étiquettes courantes et AI/ML bien connues

EKS Auto Mode et Karpenter présentent des étiquettes d'instance que vous pouvez utiliser dans un Pod nodeSelector ou nodeAffinity pour cibler NodePool requirements des charges de travail sans coder en dur les types d'instances. Le préfixe de l'étiquette diffère entre les deux : le mode EKS Auto est utilisé eks.amazonaws.com/ alors que Karpenter utilise le mode autogéré. karpenter.k8s.aws/

Les tableaux ci-dessous présentent les étiquettes pertinentes qui peuvent être utilisées dans NodePools. EKS Auto Mode et Karpenter appliquent également les étiquettes répertoriées dans la documentation Karpenter aux nœuds dans le cadre du processus de provisionnement, qui peuvent ensuite être utilisées pour le ciblage de la charge de travail.

EKS Auto Mode

Pour la liste complète, consultez la section Étiquettes prises en charge par le mode automatique EKS.

Étiquette Exemple de valeur Description

eks.amazonaws.com/instance-family

p5

Types d'instances présentant des propriétés similaires mais des quantités de ressources différentes.

eks.amazonaws.com/instance-category

p

Catégorie d'instance, généralement la lettre précédant le numéro de génération.

eks.amazonaws.com/instance-generation

5

Numéro de génération du type d'instance au sein d'une catégorie.

eks.amazonaws.com/instance-gpu-name

h100

Nom du GPU sur l'instance.

eks.amazonaws.com/instance-gpu-manufacturer

nvidia

Nom du fabricant du GPU.

eks.amazonaws.com/instance-gpu-count

8

Nombre de GPU sur l'instance.

eks.amazonaws.com/instance-gpu-memory

81920

Mégaoctets de mémoire par processeur graphique.

karpenter.sh/capacity-type

reserved

Type de capacité : spoton-demand, oureserved.

topology.kubernetes.io/zone

us-east-1a

Zone de disponibilité.

Self-managed Karpenter

Pour la liste complète, voir Karpenter Well-Known Labels.

Étiquette Exemple de valeur Description

karpenter.k8s.aws/instance-family

p5

Types d'instances présentant des propriétés similaires mais des quantités de ressources différentes.

karpenter.k8s.aws/instance-category

p

Catégorie d'instance, généralement la lettre précédant le numéro de génération.

karpenter.k8s.aws/instance-generation

5

Numéro de génération du type d'instance au sein d'une catégorie.

karpenter.k8s.aws/instance-gpu-name

h100

Nom du GPU sur l'instance.

karpenter.k8s.aws/instance-gpu-manufacturer

nvidia

Nom du fabricant du GPU.

karpenter.k8s.aws/instance-gpu-count

8

Nombre de GPU sur l'instance.

karpenter.sh/capacity-type

reserved

Type de capacité : spoton-demand, oureserved.

topology.kubernetes.io/zone

us-east-1a

Zone de disponibilité.

kubernetes.io/arch

amd64

Architecture du processeur.

Étiquettes de planification pour la capacité réservée

Lorsque EKS Auto Mode ou Karpenter lance un nœud dans une réservation, il ajoute les libellés suivants. Utilisez-les dansnodeSelector, l'affinité des nœuds ou les NodePool exigences pour acheminer les charges de travail.

  • karpenter.sh/capacity-type:reserved,on-demand, ouspot. Indique la capacité supportant le nœud.

  • karpenter.k8s.aws/capacity-reservation-id: ID de réservation spécifique sur lequel le nœud a été lancé.

  • karpenter.k8s.aws/capacity-reservation-type: default pour les ODCR, capacity-block pour les blocs de capacité.

Les exemples suivants présentent des modèles de planification courants :

Associez un Pod à une réservation spécifique (pas de solution de rechange) :

spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-id: "cr-0123456789abcdef0"

Nœuds ODCR cibles uniquement (n'importe quel ODCR, pas les blocs de capacité) :

spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-type: default

Ciblez n'importe quelle capacité réservée (ODCR ou bloc de capacité) :

spec: nodeSelector: karpenter.sh/capacity-type: reserved

Préférez la réservation mais revenez à Spot ou, en On-Demand cas d'indisponibilité :

spec: affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 preference: matchExpressions: - key: karpenter.sh/capacity-type operator: In values: ["reserved"]

Comportement d'expiration des réservations

Les ODCR et les blocs de capacité se comportent différemment à la fin de la réservation. Assurez-vous que votre stratégie de planification et de contrôle correspond au type de réservation correspondant à votre charge de travail.

ODCR

Une instance lancée dans un ODCR n'y figure pas indéfiniment. L'ODCR peut expirer, être annulé ou l'instance peut être supprimée manuellement de l'ODCR. Si l'un de ces problèmes se produit et que EKS Auto Mode/Karpenter détecte que l'instance n'appartient plus à un ODCR, il met à jour l'karpenter.sh/capacity-typeétiquette du nœud de àreserved. on-demand L'instance continue de fonctionner à On-Demand capacité standard et les pods existants continuent de fonctionner sans interruption.

Note

Tout pod programmé avec un strict ne nodeSelector: karpenter.sh/capacity-type: reserved sera pas programmé sur le nœud s'il a été renommé. Pour que les charges de travail survivent à l'expiration ou à l'annulation de l'ODCR, utilisez le preferredDuringSchedulingIgnoredDuringExecution schéma ci-dessus au lieu d'un. nodeSelector

Blocs de capacité

Contrairement aux ODCR, les blocs de capacité ont toujours une heure de fin, et EC2 met fin aux instances de blocs de capacité 30 minutes avant l'heure de fin (60 minutes pour UltraServer les types d'instances). Planifiez les tâches de formation et d'inférence à terminer ou à enregistrer avant la fermeture de la fenêtre de réservation. Les pods qui utilisent un strict nodeSelector pour une utilisation spécifique une capacity-reservation-id Pending fois le blocage expiré et qui ne seront pas reprogrammés ailleurs. Combinez le point de contrôle avec le modèle d'affinité flexible ci-dessus si vous avez besoin de déplacer des charges de travail vers une autre capacité pendant l'expiration du bloc de capacité.

  • Vous pouvez utiliser des instances réservées jusqu'à 30 minutes avant l'heure de fin du bloc de capacité pour la plupart des types d'instances, ou 60 minutes avant l'heure de fin pour les types d' UltraServer instances.

  • EKS Auto Mode et Karpenter commencent à vider de manière préventive les nœuds d'un bloc de capacité 10 minutes avant la fin de l'EC2, afin que les charges de travail aient le temps de passer au point de contrôle et de s'arrêter correctement.

Capacité statique NodePools

EKS Auto Mode et Karpenter prennent en charge la capacité statique NodePools, qui permet de maintenir un nombre fixe de nœuds indépendamment de la charge de travail. Les pools statiques éliminent les délais de démarrage à froid pour les inférences sensibles à la latence et vous permettent de réserver une empreinte d'infrastructure minimale pour votre cluster.

La capacité statique est configurée en définissant le replicas champ sur le NodePool.

Considérations

  • Une fois qu'replicasil est défini sur a NodePool, vous ne pouvez pas le supprimer. Un seul utilisateur NodePool ne peut pas basculer entre le provisionnement de capacité statique et dynamique.

  • La capacité statique n' NodePools est pas prise en compte pour la consolidation. Définissez limits.nodes ci-dessus replicas pour autoriser une mise à l'échelle temporaire lors de la dérive ou de l'expiration de l'AMI.

  • Pour une distribution prévisible des zones de disponibilité (AZ), créez une capacité statique NodePool par zone de disponibilité plutôt que de couvrir plusieurs zones dans un seul pool.

EKS Auto Mode

L'exemple ci-dessous montre une capacité statique NodePool qui utilise le mode automatique EKS par défaut NodeClass et crée une statique NodePool avec 4 nœuds (replicas) pouvant contenir au maximum 6 nœuds (limits.nodes).

apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-static-inference spec: replicas: 4 template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6e"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-east-1a"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule limits: nodes: 6 # Allow temporary headroom during node replacement
Self-managed Karpenter

Avec Karpenter autogéré, la capacité statique est limitée par la StaticCapacity fonctionnalité alpha (lancée dans la version 1.8 de Karpenter), qui doit être activée dans les valeurs Helm :

settings: featureGates: staticCapacity: true

Il NodePool fait référence à un EC2NodeClass nom personnalisé my-nodeclass et crée une statique NodePool avec 4 nœuds (replicas) qui peuvent contenir au maximum 6 nœuds (limits.nodes).

apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-static-inference spec: replicas: 4 template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: my-nodeclass requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6e"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-east-1a"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule limits: nodes: 6 # Allow temporary headroom during node replacement

Blocs de capacité pour ML

Les blocs de capacité pour le machine learning vous permettent de réserver P-family des instances et des instances Trainium pour une période future définie. Ils sont prépayés, donc EKS Auto Mode et Karpenter les modélisent comme étant gratuits et les priorisent par rapport On-Demand à Spot. Les blocs de capacité pour ML peuvent avoir une durée de réservation de 1 à 14 jours ou un multiple de 7 jours, jusqu'à 182 jours (6 mois).

Pour utiliser Capacity Blocks for ML avec EKS Auto Mode ou Karpenter, configurez capacityReservationSelectorTerms avec votre identifiant de réservation de capacité dans votre NodeClass. Vous ne pouvez pas utiliser la correspondance de réservation ouverte avec les blocs de capacité pour le ML. Un terme peut spécifier un identifiant, un ensemble de balises ou des critères de correspondance d'instance à sélectionner. Lors de la spécification des tags, il sélectionnera toutes les réservations de capacité accessibles depuis le compte avec les tags correspondants. Cela peut être encore restreint en spécifiant un identifiant de compte propriétaire.

Pour plus d'exemples, consultez la documentation https://karpenter.sh/docs/concepts/nodeclasses/#speccapacityreservationselectorterms Karpenter.

EKS Auto Mode

Créez un NodeClass qui fait référence à votre réservation de bloc de capacité, puis créez-en un NodePool qui l'utilise.

Avec consolidateAfter: Never set, Karpenter n'essaiera pas de remplacer, de fusionner ou de supprimer des nœuds dans le but de réduire les coûts ou de regrouper les charges de travail de manière plus efficace. Ceci est recommandé pour les blocs de capacité car la capacité est déjà prépayée.

apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: capacity-block-gpu spec: capacityReservationSelectorTerms: - id: "cr-0123456789abcdef0" # Your Capacity Block reservation ID # Alternative: select by tags # - tags: # role: "production-inference" # owner: "012345678901" --- apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-capacity-block spec: disruption: consolidationPolicy: WhenEmpty consolidateAfter: Never template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: capacity-block-gpu requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["reserved"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["p5", "p5e", "p5en", "p4d"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule
Self-managed Karpenter

Créez-en un EC2NodeClass qui inclut des sélecteurs d'AMI, de sous-réseau et de groupe de sécurité en plus decapacityReservationSelectorTerms, puis créez-en un NodePool qui l'utilise.

Avec consolidateAfter: Never set, Karpenter n'essaiera pas de remplacer, de fusionner ou de supprimer des nœuds dans le but de réduire les coûts ou de regrouper les charges de travail de manière plus efficace. Ceci est recommandé pour les blocs de capacité car la capacité est déjà prépayée.

apiVersion: karpenter.k8s.aws/v1 kind: EC2NodeClass metadata: name: capacity-block-gpu spec: amiSelectorTerms: - alias: al2023@latest subnetSelectorTerms: - tags: karpenter.sh/discovery: ml-cluster securityGroupSelectorTerms: - tags: karpenter.sh/discovery: ml-cluster capacityReservationSelectorTerms: - id: "cr-0123456789abcdef0" # Your Capacity Block reservation ID # Alternative: select by tags # - tags: # role: "production-inference" # owner: "012345678901" --- apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-capacity-block spec: disruption: consolidationPolicy: WhenEmpty consolidateAfter: Never template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: capacity-block-gpu requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["reserved"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["p5", "p5e", "p5en", "p4d"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule

On-Demand Réservations de capacité (ODCR)

Les ODCR garantissent la capacité dans une zone de disponibilité (AZ) spécifique sans engagement à long terme. Vous êtes facturé aux On-Demand tarifs standard, que la capacité soit utilisée ou non. Les ODCR prennent en charge toutes les familles de GPU NVIDIA, y compris les G-family instances qui ne sont pas prises en charge par Capacity Blocks for ML. Les ODCR étant prépayés, EKS Auto Mode et Karpenter les modélisent comme étant gratuits et les priorisent par rapport à Spot. On-Demand

Les ODCR se comportent différemment des blocs de capacité pour le ML à la fin de la réservation. Lorsqu'un ODCR expire ou est annulé, l'instance continue de fonctionner en standard On-Demand. Consultez Comportement d'expiration des réservations pour plus de détails.

Pour utiliser les ODCR avec EKS Auto Mode ou Karpenter, configurez les conditions capacityReservationSelectorTerms de réservation de capacité dans votre. NodeClass Un terme peut spécifier un identifiant, un ensemble de balises ou des critères de correspondance d'instance à sélectionner. Lors de la spécification des tags, il sélectionnera toutes les réservations de capacité accessibles depuis le compte avec les tags correspondants. Lors de la spécification des critères de correspondance des instances, elle sélectionne les réservations en fonction de leur comportement correspondant : ouvert (correspond à toutes les instances compatibles) ou ciblé (correspond uniquement aux instances explicitement ciblées). Cela peut être encore restreint en spécifiant un identifiant de compte propriétaire.

Pour plus d'exemples, consultez la documentation https://karpenter.sh/docs/concepts/nodeclasses/#speccapacityreservationselectorterms Karpenter.

EKS Auto Mode

Créez un NodeClass avec capacityReservationSelectorTerms et un NodePool qui donne la priorité reserved à Fallback. on-demand Épingler topology.kubernetes.io/zone à l'AZ de l'ODCR :

apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: odcr-gpu-production spec: capacityReservationSelectorTerms: - id: "cr-0987654321fedcba0" # Alternative: select by tags # - tags: # Purpose: "production-inference" # owner: "012345678901" --- apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-reserved-production spec: disruption: consolidationPolicy: WhenEmpty consolidateAfter: Never template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: odcr-gpu-production requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["reserved", "on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["p5", "g6e"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-east-1a"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule
Self-managed Karpenter

Créez un EC2NodeClass avec des sélecteurs d'AMI, de sous-réseau et de groupe de sécurité en plus decapacityReservationSelectorTerms, puis créez les éléments suivants : NodePool

apiVersion: karpenter.k8s.aws/v1 kind: EC2NodeClass metadata: name: odcr-gpu-production spec: amiSelectorTerms: - alias: al2023@latest subnetSelectorTerms: - tags: karpenter.sh/discovery: ml-cluster securityGroupSelectorTerms: - tags: karpenter.sh/discovery: ml-cluster capacityReservationSelectorTerms: - id: "cr-0987654321fedcba0" --- apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-reserved-production spec: disruption: consolidationPolicy: WhenEmpty consolidateAfter: Never template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: odcr-gpu-production requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["reserved", "on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["p5", "g6e"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-east-1a"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule

On-Demand

On-Demand est le type de capacité par défaut et peut être utilisé avec un provisionnement statique ou dynamique dans EKS Auto Mode et Karpenter. Vous pouvez demander explicitement On-Demand des instances karpenter.sh/capacity-type: on-demand en paramétrant votre NodePool. EKS Auto Mode et Karpenter sélectionnent l'instance la moins chère qui répond aux demandes de ressources du Pod. On-Demand À utiliser pour le développement, le prototypage, la mise à l'échelle d'inférence imprévisible et toute charge de travail nécessitant une disponibilité immédiate sans risque d'interruption.

EKS Auto Mode
apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-ondemand spec: template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6", "g6e", "g7e"] - key: "karpenter.k8s.aws/instance-gpu-manufacturer" operator: In values: ["nvidia"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule
Self-managed Karpenter
apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-ondemand spec: template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6", "g6e", "g7e"] - key: "karpenter.k8s.aws/instance-gpu-manufacturer" operator: In values: ["nvidia"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule

Spot

Spot permet de réaliser jusqu'à 90 % d'économies On-Demand par rapport à l'utilisation d'une capacité EC2 de rechange. AWS peut récupérer des instances Spot avec un préavis d'interruption de 2 minutes. Optimisez la disponibilité en répertoriant plusieurs familles d'instances sur le NodePool. Associez les charges de travail Spot à un point de contrôle PodDisruptionBudget et à un stockage durable (Amazon S3 ou Amazon EFS) à intervalles réguliers afin que les Pods puissent enregistrer leur état pendant la période de vidange.

Spot convient parfaitement aux charges de travail de formation et d'inférence tolérantes aux pannes et pouvant être reprises, pour lesquelles des interruptions occasionnelles sont acceptables en échange de réductions de coûts importantes.

Les candidats les plus courants sont les suivants :

  • Réglage et balayage des hyperparamètres  : de nombreux essais courts et parallèles qui peuvent être réessayés s'ils sont interrompus.

  • Formation distribuée avec points de contrôle  : tâches de longue durée qui enregistrent périodiquement l'état dans S3 ou FSx et peuvent reprendre à partir du dernier point de contrôle après la perte d'un nœud.

  • Inférence par lots et hors ligne  : tâches de notation à grande échelle par rapport à des ensembles de données où la latence de bout en bout est mesurée en heures et non en secondes.

  • Prétraitement des données et pipelines d'ingénierie des fonctionnalités  : transformations parallèles sur de grands ensembles de données.

  • Évaluation et analyse comparative des modèles  : tâches répétables qui produisent des résultats idempotents.

  • Développement, prototypage et blocs-notes  : expérimentation interactive où les utilisateurs peuvent tolérer des redémarrages occasionnels.

Évitez Spot pour les inférences en temps réel sensibles à la latence, les points de terminaison SLA-bound de production et les charges de travail qui ne sont pas contrôlées ou ne peuvent tolérer les redémarrages.

Vous pouvez demander explicitement des instances Spot karpenter.sh/capacity-type: spot en paramétrant votre NodePool.

EKS Auto Mode

Le mode automatique EKS gère les interruptions ponctuelles de manière native. Aucune file d'attente SQS ni aucun gestionnaire de terminaison de nœud ne sont requis.

apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-spot spec: disruption: budgets: - nodes: 10% consolidationPolicy: WhenEmpty consolidateAfter: 1h template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["spot"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6", "g6e", "g7e"] - key: "karpenter.k8s.aws/instance-gpu-manufacturer" operator: In values: ["nvidia"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule limits: resources: nvidia.com/gpu: "64"
Self-managed Karpenter

Self-managed Karpenter vous demande d'activer la gestion native des interruptions sur le contrôleur Karpenter (et non sur le NodePool) en configurant une file d'interruption : une file d'attente SQS qui reçoit les événements d'interruption EC2 Spot et de recommandation de rééquilibrage. Vous devez le configurer une seule fois au moment de l'installation.

Si vous installez Karpenter directement avec Helm, définissez settings.interruptionQueue : values.yaml

# karpenter values.yaml (Helm) settings: clusterName: my-cluster interruptionQueue: my-queue # Name of the SQS queue receiving Spot events

Si vous démarrez Karpenter aveceksctl, configurez-le withSpotInterruptionQueue: true dans le fichier de configuration de votre cluster. eksctlcrée la file d'attente et EventBridge les règles SQS et configure le contrôleur Karpenter pour qu'il les utilise.

# eksctl ClusterConfig karpenter: version: "${KARPENTER_VERSION}" withSpotInterruptionQueue: true

Une fois que le contrôleur est configuré pour utiliser votre file d'attente, aucune configuration supplémentaire n'est nécessaire pour les NodePool ressources individuelles. La gestion des interruptions s'applique à l'ensemble du cluster.

apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu-spot spec: disruption: budgets: - nodes: 10% consolidationPolicy: WhenEmpty consolidateAfter: 1h template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["spot"] - key: "karpenter.k8s.aws/instance-family" operator: In values: ["g6", "g6e", "g7e"] - key: "karpenter.k8s.aws/instance-gpu-manufacturer" operator: In values: ["nvidia"] taints: - key: nvidia.com/gpu value: "true" effect: NoSchedule limits: resources: nvidia.com/gpu: "64"