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 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.

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 les charges de travail d'entraînement et d'inférence liées à l'IA à 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 fournissent et dimensionnent des instances de calcul accélérées à mesure que les charges de travail sont planifiées sur le cluster. Avec le provisionnement statique, EKS Auto Mode et Karpenter fournissent et maintiennent 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és de base 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 fournissent toujours la capacité réservée en premier, suivie de Spot or. On-Demand

EKS Auto Mode par rapport à Karpenter

Les deux approches partagent l' NodePool API, mais elles diffèrent en termes de propriété opérationnelle, d'API de ressources, de support 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 avoir un contrôle total sur le cycle de vie des nœuds, les AMI, le réglage du système d'exploitation et les correctifs.

Modèle opérationnel

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

Vous installez et utilisez le contrôleur Karpenter dans votre cluster, ainsi que vos propres GPU/Trainium pilotes, plug-ins de périphériques, cycle de vie des AMI, correctifs et gestion des interruptions ponctuelles.

Options de calcul

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

On-Demand, Spot, ODCRs, 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 entre 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.

Extraction rapide des conteneurs

Le pull parallèle SOCI est 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, répartir

Cluster, partitionner, répartir

Configuration de l'interface réseau

Non pris en charge

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 connues

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

Les tableaux ci-dessous indiquent 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 de Karpenter aux nœuds dans le cadre du processus de provisionnement qui peuvent être utilisés ultérieurement pour le ciblage de la charge de travail.

EKS Auto Mode

Pour la liste complète, voir Étiquettes compatibles avec 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 dans une catégorie.

eks.amazonaws.com/instance-gpu-name

h100

Nom du GPU de 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 GPU.

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 dans une catégorie.

karpenter.k8s.aws/instance-gpu-name

h100

Nom du GPU de 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

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

  • karpenter.sh/capacity-type: reservedon-demand, ouspot. Indique la capacité qui soutient le nœud.

  • karpenter.k8s.aws/capacity-reservation-id: ID de réservation spécifique avec 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 illustrent les modèles de planification courants :

Ajoutez un Pod à une réservation spécifique (aucune solution de rechange) :

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

Nœuds ODCR cibles uniquement (tous les ODCR, pas les blocs de capacité) :

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

Ciblez toute capacité réservée (ODCR ou bloc de capacité) :

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

Préférez réserver, 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 point de contrôle correspond au type de réservation qui répond à 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'une de ces situations se produit et qu'EKS Auto Mode/Karpenter détecte que l'instance n'appartient plus à un ODCR, l'karpenter.sh/capacity-typeétiquette du nœud passe de àreserved. on-demand L'instance continue de fonctionner en tant que On-Demand capacité standard, et les pods existants continuent de fonctionner sans interruption.

Note

Tout Pod programmé avec un code strict ne nodeSelector: karpenter.sh/capacity-type: reserved sera pas programmé sur le nœud s'il a été réétiqueté. Pour que les charges de travail puissent survivre à l'expiration ou à l'annulation d'un ODCR, utilisez le preferredDuringSchedulingIgnoredDuringExecution modèle illustré 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'instance). Planifiez des tâches de formation et d'inférence pour terminer ou enregistrer l'état 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 transférer 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 instance.

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

Capacité statique NodePools

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

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

Considérations

  • Une fois replicas défini sur un NodePool, vous ne pouvez pas le supprimer. Personne NodePool ne peut basculer entre le provisionnement de capacité statique et le provisionnement dynamique.

  • La capacité statique n' NodePools est pas prise en compte pour la consolidation. Défini limits.nodes ci-dessus replicas pour autoriser le dimensionnement 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 capacité statique NodePool avec 4 nœuds (replicas) qui peuvent être 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 être 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 ML vous permettent de réserver P-family des instances Trainium pour une future fenêtre définie. Ils sont prépayés, donc EKS Auto Mode et Karpenter les proposent comme 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 de réservation ouverte correspondant à Capacity Blocks for 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 davantage restreint en spécifiant un identifiant de compte propriétaire.

Pour plus d'exemples, consultez la documentation de Karpenter.

EKS Auto Mode

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

Avec cette consolidateAfter: Never option, Karpenter n'essaiera pas de remplacer, de fusionner ou de résilier des nœuds pour réduire les coûts ou 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 un EC2NodeClass qui inclut en plus des sélecteurs d'AMI, de sous-réseau et de groupe de sécuritécapacityReservationSelectorTerms, puis créez-en un NodePool qui l'utilise.

Avec cette consolidateAfter: Never option, Karpenter n'essaiera pas de remplacer, de fusionner ou de résilier des nœuds pour réduire les coûts ou 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é au On-Demand tarif 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 proposent gratuitement 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 capacityReservationSelectorTerms avec vos conditions 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, il sélectionne les réservations en fonction de leur comportement correspondant : ouverte (correspond à toutes les instances compatibles) ou ciblées (correspond uniquement aux instances explicitement ciblées). Cela peut être davantage restreint en spécifiant un identifiant de compte propriétaire.

Pour plus d'exemples, consultez la documentation de Karpenter.

EKS Auto Mode

Créez un NodeClass with capacityReservationSelectorTerms et un a NodePool qui priorisent reserved avec on-demand une solution de secours. Épinglez 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 : 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 des On-Demand instances de manière explicite karpenter.sh/capacity-type: on-demand en définissant 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 imprévisible des inférences 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 de la capacité EC2 de réserve. AWS peut récupérer des instances Spot moyennant 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 PodDisruptionBudget point de contrôle vers 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 d'importantes économies de coûts.

Les candidats courants incluent :

  • Réglage des hyperparamètres et balayages : de nombreux essais courts et parallèles qui peuvent être réessayés en cas d'interruption.

  • Formation distribuée avec point de contrôle : tâches de longue durée qui enregistrent régulièrement 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 : évaluation à grande échelle des tâches par rapport à des ensembles de données dans lesquels la latence de bout en bout est mesurée en heures et non en secondes.

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

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

  • Développement, prototypage et ordinateurs portables : 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 configurant 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 n'est 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 ne le configurez qu'une seule fois au moment de l'installation.

Si vous installez Karpenter directement avec Helm, configurez settings.interruptionQueue votre 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, définissez-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 les utiliser.

# 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 sur 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"