**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 de nœuds autogérés avec des blocs de capacité pour ML
Les blocs de capacité pour le Machine Learning (ML) vous permettent de réserver des instances GPU à une date ultérieure pour prendre en charge vos charges de travail de ML de courte durée. Pour plus d’informations, consultez la section [Blocs de capacité pour ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) dans le *Guide de l’utilisateur Amazon EC2 pour les instances Linux*.
## Considérations
**Important**
Les blocs de capacité ne sont disponibles que pour certains types d'instances et AWS certaines régions Amazon EC2. Pour plus d’informations sur la compatibilité, consultez la section [Prérequis pour l’utilisation des blocs de capacité](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-using.html#capacity-blocks-prerequisites) dans le *Guide de l’utilisateur Amazon EC2 pour les instances Linux*.
Si vous créez un groupe de nœuds autogérés avant que la réserve de capacité de capacité ne devienne active, définissez alors la capacité souhaitée sur `0`.
Afin de disposer de suffisamment de temps pour vidanger le(s) nœud(s) de manière gracieuse, nous vous conseillons de programmer une mise à l'échelle jusqu'à zéro plus de 30 minutes avant l'heure de fin de la réserve du bloc de capacité.
Pour que vos pods soient correctement vidés, nous vous recommandons de configurer le AWS Node Termination Handler comme expliqué dans les étapes d'exemple.
## Utilisation des blocs de capacité avec des nœuds autogérés
Vous pouvez utiliser les blocs de capacité avec Amazon EKS pour l'approvisionnement et la mise à l'échelle de vos nœuds autogérés. Les étapes suivantes vous donnent un aperçu général de l'exemple. Les exemples AWS CloudFormation de modèles ne couvrent pas tous les aspects nécessaires à une charge de travail de production. Il est généralement recommandé d’ajouter un script de démarrage pour joindre le nœud au cluster, de spécifier une AMI Amazon EKS accélérée, ainsi qu’un profil d’instance approprié pour intégrer le nœud au cluster. Pour de plus amples informations, veuillez consulter [Créer des nœuds Amazon Linux autogérés](launch-workers.md).
1. Créez un modèle de lancement applicable à votre charge de travail. Pour plus d’informations, consultez la section [Utiliser des blocs de capacité pour les charges de travail de machine learning](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-template-capacity-blocks.html) dans le *Guide de l’utilisateur Amazon EC2 Auto Scaling*.
Assurez-vous que les `LaunchTemplateData` incluent les éléments suivants :
+ `InstanceMarketOptions` avec `MarketType` défini sur `"capacity-block"`
+ `CapacityReservationSpecification: CapacityReservationTarget` avec `CapacityReservationId` défini sur le bloc de capacité (par exemple : `cr-{{02168da1478b509e0}} `)
+ `IamInstanceProfile`avec le `Arn` set correspondant à la valeur applicable {{iam-instance-profile-arn}}
+ `ImageId`réglé sur la valeur applicable {{image-id}}
+ `InstanceType`défini sur un type d'instance qui prend en charge les blocs de capacité (par exemple :{{p5.48xlarge}})
+ `SecurityGroupIds`défini sur les identifiants applicables (par exemple :{{sg-05b1d815d1EXAMPLE}})
+ `UserData`défini sur celui applicable {{user-data}} à votre groupe de nœuds autogéré
Voici un extrait d'un CloudFormation modèle qui crée un modèle de lancement ciblant un bloc de capacité.
```
NodeLaunchTemplate:
Type: "AWS::EC2::LaunchTemplate"
Properties:
LaunchTemplateData:
InstanceMarketOptions:
MarketType: "capacity-block"
CapacityReservationSpecification:
CapacityReservationTarget:
CapacityReservationId: "cr-02168da1478b509e0"
IamInstanceProfile:
Arn: iam-instance-profile-arn
ImageId: image-id
InstanceType: p5.48xlarge
KeyName: key-name
SecurityGroupIds:
- sg-05b1d815d1EXAMPLE
UserData: user-data
```
Vous devez transmettre le sous-réseau de la zone de disponibilité dans laquelle la réservation est effectuée, car les blocs de capacité sont répartis par zone.
1. Utilisez le modèle de lancement pour créer un groupe de nœuds autogérés. Si vous le faites avant que la réserve de capacité ne soit active, définissez la capacité souhaitée sur `0`. Lorsque vous créez le groupe de nœuds, assurez-vous que vous ne spécifiez que le sous-réseau correspondant à la zone de disponibilité dans laquelle la capacité est réservée.
Voici un exemple de CloudFormation modèle auquel vous pouvez faire référence lors de la création d'un modèle applicable à votre charge de travail. Cet exemple récupère le `LaunchTemplateId` et la `Version` de la ressource ` AWS::Amazon EC2::LaunchTemplate` indiquée à l’étape précédente. Il obtient également les valeurs pour `DesiredCapacity`, `MaxSize`, `MinSize`, et `VPCZoneIdentifier` qui sont déclarées ailleurs dans le même modèle.
```
NodeGroup:
Type: "AWS::AutoScaling::AutoScalingGroup"
Properties:
DesiredCapacity: !Ref NodeAutoScalingGroupDesiredCapacity
LaunchTemplate:
LaunchTemplateId: !Ref NodeLaunchTemplate
Version: !GetAtt NodeLaunchTemplate.LatestVersionNumber
MaxSize: !Ref NodeAutoScalingGroupMaxSize
MinSize: !Ref NodeAutoScalingGroupMinSize
VPCZoneIdentifier: !Ref Subnets
Tags:
- Key: Name
PropagateAtLaunch: true
Value: !Sub ${ClusterName}-${NodeGroupName}-Node
- Key: !Sub kubernetes.io/cluster/${ClusterName}
PropagateAtLaunch: true
Value: owned
```
1. Une fois que le groupe de nœuds a été créé avec succès, assurez-vous d'enregistrer le `NodeInstanceRole` pour le groupe de nœuds qui a été créé. Vous en avez besoin pour vous assurer que, lorsque le groupe de nœuds est mis à l’échelle, les nouveaux nœuds rejoignent bien le cluster et que Kubernetes les reconnaisse. Pour plus d'informations, consultez les AWS Management Console instructions de la section [Création de nœuds Amazon Linux autogérés](launch-workers.md).
1. Nous vous recommandons de créer une politique de mise à l'échelle programmée pour le groupe Auto Scaling qui s'aligne sur les heures de réserve du bloc de capacité. Pour plus d'informations, consultez la section [Mise à l'échelle programmée pour Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html) dans le *Guide de l'utilisateur d'Amazon EC2 Auto Scaling*.
Vous pouvez utiliser toutes les instances que vous avez réservées jusqu'à 30 minutes avant l'heure de fin du bloc de capacité. Les instances encore en cours d'exécution à ce moment-là commenceront à prendre fin. Afin de disposer de suffisamment de temps pour vidanger le(s) nœud(s) de manière gracieuse, nous vous conseillons de programmer une mise à l'échelle jusqu'à zéro plus de 30 minutes avant l'heure de fin de la réserve du bloc de capacité.
Si, au lieu de cela, vous souhaitez effectuer l’augmentation verticale manuellement la capacité chaque fois que la réserve de capacité devient `Active`, vous devez mettre à jour la capacité souhaitée du groupe Auto Scaling au moment du début de la réserve du bloc de capacité. Ensuite, vous devrez également réduire manuellement la capacité plus de 30 minutes avant l'heure de fin de la réserve du bloc de capacité.
1. Le groupe de nœuds est maintenant prêt à accueillir les charges de travail et à programmer des pods.
1. Pour que vos pods soient correctement vidés, nous vous recommandons de configurer AWS Node Termination Handler. Ce gestionnaire sera en mesure de surveiller les événements du cycle de vie « ASG Scale-in » liés à Amazon EC2 Auto Scaling en utilisant le plan de contrôle Kubernetes EventBridge et de permettre au plan de contrôle Kubernetes de prendre les mesures nécessaires avant que l'instance ne soit indisponible. Dans le cas contraire, vos pods et objets Kubernetes risquent de rester bloqués à l’état d’attente. Pour plus d'informations, consultez [AWS Node Termination Handler activé](https://github.com/aws/aws-node-termination-handler) GitHub.
Si vous ne configurez pas de gestionnaire d’arrêt des nœuds Node Termination Handler, nous vous recommandons de commencer à évacuer vos pods manuellement avant la fenêtre des 30 minutes, afin de leur laisser suffisamment de temps pour être évacués correctement.