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.

# Autoscaling sur EKS SageMaker HyperPod
<a name="sagemaker-hyperpod-eks-autoscaling"></a>

Amazon SageMaker HyperPod fournit une solution gérée de mise à l'échelle automatique des nœuds basée sur Karpenter pour les clusters créés avec l'orchestration EKS. [Karpenter](https://karpenter.sh/) est un gestionnaire de cycle de vie des nœuds Kubernetes open source conçu pour optimiser la mise à l'échelle des AWS clusters et la rentabilité. Contrairement aux déploiements Karpenter autogérés, SageMaker HyperPod l'implémentation gérée élimine les frais opérationnels liés à l'installation, à la configuration et à la maintenance des contrôleurs Karpenter tout en offrant une résilience et une tolérance aux pannes intégrées. Cette solution de mise à l'échelle automatique gérée repose sur les capacités HyperPod de [provisionnement continu](sagemaker-hyperpod-scaling-eks.md) et vous permet de dimensionner efficacement les ressources informatiques pour les charges de travail de formation et d'inférence grâce à la gestion automatique des défaillances et à la restauration. 

Vous ne payez que ce que vous utilisez. Vous êtes responsable du paiement de toutes les instances de calcul qui sont automatiquement provisionnées par le biais de l'autoscaling conformément à la tarification standard SageMaker HyperPod. Pour obtenir des informations détaillées sur les prix, consultez [Amazon SageMaker AI](https://aws.amazon.com/sagemaker/ai/pricing/).

En activant la mise à l'échelle automatique basée sur Karpenter avec HyperPod, vous avez accès à :
+ **Cycle de vie géré par les services** : HyperPod gère l'installation, les mises à jour et la maintenance de Karpenter, éliminant ainsi les frais opérationnels.
+ **Provisionnement juste à temps** : Karpenter observera vos pods en attente et provisionnera le calcul requis pour vos charges de travail à partir d’un pool à la demande.
+ **Mise à échelle à zéro** : réduisez verticalement les nœuds jusqu’à zéro sans conserver l’infrastructure de contrôleur dédiée.
+ **Sélection de nœuds adaptée à la charge de travail** : Karpenter choisit les types d’instances optimaux en fonction des exigences de pod, des zones de disponibilité et de la tarification pour minimiser les coûts.
+ **Consolidation automatique des nœuds** : Karpenter évalue régulièrement le cluster à la recherche d’opportunités d’optimisation, en déplaçant les charges de travail pour éliminer les nœuds sous-utilisés.
+ **Résilience intégrée** : tire parti des mécanismes intégrés HyperPod de tolérance aux pannes et de restauration des nœuds.

Les rubriques suivantes expliquent comment activer l' HyperPod autoscaling avec Karpenter.

**Topics**
+ [Conditions préalables](#sagemaker-hyperpod-eks-autoscaling-prereqs)
+ [Créez un rôle IAM pour le HyperPod dimensionnement automatique avec Karpenter](sagemaker-hyperpod-eks-autoscaling-iam.md)
+ [Création et configuration d'un HyperPod cluster avec Karpenter Autoscaling](sagemaker-hyperpod-eks-autoscaling-cluster.md)
+ [Créez un NodeClass](sagemaker-hyperpod-eks-autoscaling-nodeclass.md)
+ [Créez un NodePool](sagemaker-hyperpod-eks-autoscaling-nodepool.md)
+ [Déploiement d’une charge de travail](sagemaker-hyperpod-eks-autoscaling-workload.md)

## Conditions préalables
<a name="sagemaker-hyperpod-eks-autoscaling-prereqs"></a>
+ Le provisionnement continu est activé sur votre HyperPod cluster. Activez le provisionnement continu en le configurant `Continuous` lors `--node-provisioning-mode` de la création de votre SageMaker HyperPod cluster. Pour de plus amples informations, veuillez consulter [Provisionnement continu pour des opérations de cluster améliorées sur Amazon EKS](sagemaker-hyperpod-scaling-eks.md).
+ La version 1.0.742.0\$11.0.241.0 ou supérieure de l’agent de surveillance de l’état doit être installée. Nécessaire pour les opérations et la surveillance du HyperPod cluster. L’agent doit être configuré avant d’activer la mise à l’échelle automatique de Karpenter afin de garantir des rapports appropriés sur l’état du cluster et la gestion correcte du cycle de vie des nœuds. Pour de plus amples informations, veuillez consulter [Système de surveillance de la santé](sagemaker-hyperpod-eks-resiliency-health-monitoring-agent.md).
+ Seulement si votre cluster Amazon EKS exécute Karpenter, les versions `NodePool` et `NodeClaim` de Karpenter doivent être v1.
+ `NodeRecovery` doit être défini sur automatique. Pour de plus amples informations, veuillez consulter [Récupération automatique des nœuds](sagemaker-hyperpod-eks-resiliency-node-recovery.md).

# Créez un rôle IAM pour le HyperPod dimensionnement automatique avec Karpenter
<a name="sagemaker-hyperpod-eks-autoscaling-iam"></a>

Dans les étapes suivantes, vous allez créer un rôle IAM qui permet SageMaker HyperPod de gérer les nœuds Kubernetes dans votre cluster via le dimensionnement automatique basé sur Karpenter. Ce rôle fournit les autorisations nécessaires pour HyperPod ajouter et supprimer automatiquement des nœuds de cluster en fonction de la charge de travail.

**Ouverture de la console IAM**

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à l'adresse console.aws.amazon.com.

1. Dans le panneau de navigation, choisissez **Rôles**.

1. Choisissez **Créer un rôle**.

**Configuration de la politique d’approbation**

1. Pour **Type d’entité de confiance**, choisissez **Politique de confiance personnalisée**.

1. Dans l’éditeur de la **Politique d’approbation personnalisée**, remplacez la politique par défaut par la suivante :

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "Service": [
                       "hyperpod.sagemaker.amazonaws.com"
                   ]
               },
               "Action": "sts:AssumeRole"
           }
       ]
   }
   ```

------

1. Choisissez **Suivant**.

**Création et attachement de la politique d’autorisations**

Dans SageMaker HyperPod la mesure où des autorisations spécifiques ne sont pas disponibles dans les politiques AWS gérées, vous devez créer une politique personnalisée.

1. Choisissez **Create Policy** (Créer une politique). Cela ouvre un nouvel onglet du navigateur.

1. Choisissez l’onglet **JSON**.

1. Remplacez la politique par défaut par le code suivant :

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "sagemaker:BatchAddClusterNodes",
                   "sagemaker:BatchDeleteClusterNodes"
               ],
               "Resource": "arn:aws:sagemaker:*:*:cluster/*",
               "Condition": {
                   "StringEquals": {
                       "aws:ResourceAccount": "${aws:PrincipalAccount}"
                   }
               }
           },
           {
               "Effect": "Allow",
               "Action": [
                   "kms:CreateGrant",
                   "kms:DescribeKey"
               ],
               "Resource": "arn:aws:kms:*:*:key/*",
               "Condition": {
                   "StringLike": {
                       "kms:ViaService": "sagemaker.*.amazonaws.com"
                   },
                   "Bool": {
                       "kms:GrantIsForAWSResource": "true"
                   },
                   "ForAllValues:StringEquals": {
                       "kms:GrantOperations": [
                           "CreateGrant",
                           "Decrypt",
                           "DescribeKey",
                           "GenerateDataKeyWithoutPlaintext",
                           "ReEncryptTo",
                           "ReEncryptFrom",
                           "RetireGrant"
                       ]
                   }
               }
           }
       ]
   }
   ```

------

1. Choisissez **Suivant**.

1. Pour **Policy name** (Nom de la politique), saisissez **SageMakerHyperPodKarpenterPolicy**.

1. (Facultatif) Dans le champ **Description**, saisissez une description pour la politique.

1. Sélectionnez **Créer une politique**.

1. Retournez à l’onglet de création de rôle et actualisez la liste des politiques.

1. Recherchez et sélectionnez **SageMakerHyperPodKarpenterPolicy**celui que vous venez de créer.

1. Choisissez **Suivant**.

**Création et nommage du rôle**

1. Pour le **Nom du rôle**, saisissez `SageMakerHyperPodKarpenterRole`.

1. (Facultatif) Pour **Description**, saisissez la description du rôle.

1. Dans la section **Étape 1 : Sélection des entités de confiance**, vérifiez que la politique d’approbation montre les principaux de service corrects.

1. Dans la section **Étape 2 : Ajout d’autorisations**, vérifiez que `SageMakerHyperPodKarpenterPolicy` est attachée.

1. Choisissez **Créer un rôle**.

**Enregistrement de l’ARN du rôle**

Une fois le rôle créé avec succès :

1. Dans la liste **Rôles**, choisissez le nom de rôle `SageMakerHyperPodKarpenterRole`.

1. Copiez l’**ARN du rôle** à partir de la section **Récapitulatif**. Vous aurez besoin de cet ARN lors de la création de votre HyperPod cluster.

L’ARN du rôle respecte le format suivant : `arn:aws:iam::ACCOUNT-ID:role/SageMakerHyperPodKarpenterRole`.

# Création et configuration d'un HyperPod cluster avec Karpenter Autoscaling
<a name="sagemaker-hyperpod-eks-autoscaling-cluster"></a>

Dans les étapes suivantes, vous allez créer un SageMaker HyperPod cluster avec le provisionnement continu activé et le configurer pour utiliser l'autoscaling basé sur Karpenter.

**Création d'un HyperPod cluster**

1. Chargez la configuration de votre environnement et extrayez les valeurs des CloudFormation piles.

   ```
   source .env
   SUBNET1=$(cfn-output $VPC_STACK_NAME PrivateSubnet1)
   SUBNET2=$(cfn-output $VPC_STACK_NAME PrivateSubnet2)
   SUBNET3=$(cfn-output $VPC_STACK_NAME PrivateSubnet3)
   SECURITY_GROUP=$(cfn-output $VPC_STACK_NAME NoIngressSecurityGroup)
   EKS_CLUSTER_ARN=$(cfn-output $EKS_STACK_NAME ClusterArn)
   EXECUTION_ROLE=$(cfn-output $SAGEMAKER_STACK_NAME ExecutionRole)
   SERVICE_ROLE=$(cfn-output $SAGEMAKER_STACK_NAME ServiceRole)
   BUCKET_NAME=$(cfn-output $SAGEMAKER_STACK_NAME Bucket)
   HP_CLUSTER_NAME="hyperpod-eks-test-$(date +%s)"
   EKS_CLUSTER_NAME=$(cfn-output $EKS_STACK_NAME ClusterName)
   HP_CLUSTER_ROLE=$(cfn-output $SAGEMAKER_STACK_NAME ClusterRole)
   ```

1. Chargez le script d’initialisation de nœud dans votre compartiment Amazon S3.

   ```
   aws s3 cp lifecyclescripts/on_create_noop.sh s3://$BUCKET_NAME
   ```

1. Créez un fichier de configuration de cluster avec vos variables d’environnement.

   ```
   cat > cluster_config.json << EOF
   {
       "ClusterName": "$HP_CLUSTER_NAME",
       "InstanceGroups": [
           {
               "InstanceCount": 1,
               "InstanceGroupName": "system",
               "InstanceType": "ml.c5.xlarge",
               "LifeCycleConfig": {
                   "SourceS3Uri": "s3://$BUCKET_NAME",
                   "OnCreate": "on_create_noop.sh"
               },
               "ExecutionRole": "$EXECUTION_ROLE"
           },
           {
               "InstanceCount": 0,
               "InstanceGroupName": "auto-c5-az1",
               "InstanceType": "ml.c5.xlarge",
               "LifeCycleConfig": {
                   "SourceS3Uri": "s3://$BUCKET_NAME",
                   "OnCreate": "on_create_noop.sh"
               },
               "ExecutionRole": "$EXECUTION_ROLE"
           },
           {
               "InstanceCount": 0,
               "InstanceGroupName": "auto-c5-4xaz2",
               "InstanceType": "ml.c5.4xlarge",
               "LifeCycleConfig": {
                   "SourceS3Uri": "s3://$BUCKET_NAME",
                   "OnCreate": "on_create_noop.sh"
               },
               "ExecutionRole": "$EXECUTION_ROLE",
               "OverrideVpcConfig": {
                   "SecurityGroupIds": [
                       "$SECURITY_GROUP"
                   ],
                   "Subnets": [
                       "$SUBNET2"
                   ]
               }
           },
           {
               "InstanceCount": 0,
               "InstanceGroupName": "auto-g5-az3",
               "InstanceType": "ml.g5.xlarge",
               "LifeCycleConfig": {
                   "SourceS3Uri": "s3://$BUCKET_NAME",
                   "OnCreate": "on_create_noop.sh"
               },
               "ExecutionRole": "$EXECUTION_ROLE",
               "OverrideVpcConfig": {
                   "SecurityGroupIds": [
                       "$SECURITY_GROUP"
                   ],
                   "Subnets": [
                       "$SUBNET3"
                   ]
               }
           }
       ],
       "VpcConfig": {
           "SecurityGroupIds": [
               "$SECURITY_GROUP"
           ],
           "Subnets": [
               "$SUBNET1"
           ]
       },
       "Orchestrator": {
           "Eks": {
               "ClusterArn": "$EKS_CLUSTER_ARN"
           }
       },
       "ClusterRole": "$HP_CLUSTER_ROLE",
       "AutoScaling": {
           "Mode": "Enable",
           "AutoScalerType": "Karpenter"
       },
       "NodeProvisioningMode": "Continuous"
   }
   EOF
   ```

1. Exécutez la commande suivante pour créer votre HyperPod cluster.

   ```
   aws sagemaker create-cluster --cli-input-json file://./cluster_config.json
   ```

1. Le processus de création du cluster prend environ 20 minutes. Surveillez l'état du cluster jusqu'à ce que .Status ClusterStatus et AutoScaling .Status s'affichent InService.

1. Enregistrez l’ARN du cluster pour les opérations suivantes.

   ```
   HP_CLUSTER_ARN=$(aws sagemaker describe-cluster --cluster-name $HP_CLUSTER_NAME \
      --output text --query ClusterArn)
   ```

**Activation de la mise à l’échelle automatique de Karpenter**

1. Exécutez la commande suivante pour activer la mise à l’échelle automatique basée sur Karpenter sur tout cluster préexistant doté d’un mode de provisionnement continu des nœuds.

   ```
   aws sagemaker update-cluster \
       --cluster-name $HP_CLUSTER_NAME \
       --auto-scaling Mode=Enable,AutoScalerType=Karpenter \
       --cluster-role $HP_CLUSTER_ROLE
   ```

1. Vérifiez que Karpenter a bien été activé :

   ```
   aws sagemaker describe-cluster --cluster-name $HP_CLUSTER_NAME --query 'AutoScaling'
   ```

1. Sortie attendue :

   ```
   {
       "Mode": "Enable",
       "AutoScalerType": "Karpenter",
       "Status": "InService"
   }
   ```

Attendez que le `Status` s'affiche `InService` avant de procéder à la configuration NodeClass et NodePool.

# Créez un NodeClass
<a name="sagemaker-hyperpod-eks-autoscaling-nodeclass"></a>

**Important**  
Vous devez commencer avec 0 nœud dans votre groupe d’instances et laisser Karpenter gérer la mise à l’échelle automatique. Si vous commencez avec plus de 0 nœud, Karpenter les réduira verticalement à 0.

Une classe de nœuds (`NodeClass`) définit les paramètres au niveau de l’infrastructure qui s’appliquent aux groupes de nœuds de votre cluster Amazon EKS, notamment la configuration réseau, les paramètres de stockage et le balisage des ressources. A `HyperPodNodeClass` est une personnalisation `NodeClass` qui correspond à des groupes d'instances précréés dans SageMaker HyperPod, définissant des contraintes concernant les types d'instances et les zones de disponibilité pris en charge pour les décisions de Karpenter en matière de dimensionnement automatique.

**Considérations relatives à la création d’une classe de nœuds**
+ Vous pouvez spécifier jusqu’à 10 groupes d’instances dans un élément `NodeClass`.
+ Lorsque vous utilisez le partitionnement GPU avec MIG (GPU multi-instance), Karpenter peut automatiquement approvisionner les nœuds avec des groupes d'instances compatibles MIG. Assurez-vous que vos groupes d'instances incluent les types d'instances pris en charge par MIG (ml.p4d.24xlarge, ml.p5.48xlarge ou ml.p5e/p5en.48xlarge) et configurez les étiquettes MIG appropriées lors de la création du cluster. Pour plus d'informations sur la configuration du partitionnement du GPU, consultez[Utilisation de partitions GPU dans Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-gpu-partitioning.md).
+ Si des étiquettes personnalisées sont appliquées à des groupes d'instances, vous pouvez les afficher dans le `desiredLabels` champ lorsque vous demandez le `HyperpodNodeClass` statut. Cela inclut les étiquettes de configuration MIG telles que`nvidia.com/mig.config`. Lorsque des tâches entrantes demandent des ressources MIG, Karpenter redimensionne automatiquement les instances en appliquant les étiquettes MIG appropriées.
+ Si vous choisissez de supprimer un groupe d'instances, nous vous recommandons de le supprimer de votre cluster `NodeClass` avant de le supprimer de votre HyperPod cluster. Si un groupe d’instances est supprimé alors qu’il est utilisé dans un élément `NodeClass`, l’élément `NodeClass` sera marqué comme n’étant pas `Ready` pour le provisionnement et ne sera pas utilisé pour les opérations ultérieures de mise à l’échelle tant que le groupe d’instances ne sera pas supprimé de `NodeClass`.
+ Lorsque vous supprimez des groupes d’instances d’un élément `NodeClass`, Karpenter détecte une dérive sur les nœuds qui étaient gérés par Karpenter dans le ou les groupes d’instances et interrompt les nœuds en fonction des contrôles de votre budget dédié aux interruptions.
+ Les sous-réseaux utilisés par le groupe d’instances doivent appartenir à la même zone de disponibilité. Les sous-réseaux sont spécifiés en utilisant `OverrideVpcConfig` au niveau du groupe d’instances ou du cluster. `VpcConfig` est utilisé par défaut.
+ Seule la capacité à la demande est prise en charge pour le moment. Les groupes d’instances dotés d’un plan d’entraînement ou d’une capacité réservée ne sont pas pris en charge.
+ Les groupes d’instances avec `DeepHealthChecks (DHC)` ne sont pas pris en charge. En effet, une vérification de surveillance approfondie de l’état (DHC) prend environ de 60 à 90 minutes et les pods resteront à l’état d’attente pendant cette période, ce qui peut entraîner un surprovisionnement.

Les étapes suivantes décrivent comment créer un élément `NodeClass`.

1. Créez un fichier YAML (par exemple, nodeclass.yaml) avec votre configuration `NodeClass`.

1. Appliquez la configuration à votre cluster en utilisant kubectl.

1. Référencez l’élément `NodeClass` dans votre configuration de `NodePool`.

1. Voici un exemple de `NodeClass` qui utilise les types d’instance ml.c5.xlarge et ml.c5.4xlarge :

   ```
   apiVersion: karpenter.sagemaker.amazonaws.com/v1
   kind: HyperpodNodeClass
   metadata:
     name: sample-nc
   spec:
     instanceGroups:
       # name of InstanceGroup in HyperPod cluster. InstanceGroup needs to pre-created
       # MaxItems: 10
       - auto-c5-xaz1
       - auto-c5-4xaz2
   ```

1. Appliquez la configuration :

   ```
   kubectl apply -f nodeclass.yaml
   ```

1. Surveillez l' NodeClass état pour vous assurer que la condition Prêt est définie sur True :

   ```
   kubectl get hyperpodnodeclass sample-nc -o yaml
   ```

   ```
   apiVersion: karpenter.sagemaker.amazonaws.com/v1
   kind: HyperpodNodeClass
   metadata:
     creationTimestamp: "<timestamp>"
     name: sample-nc
     uid: <resource-uid>
   spec:
     instanceGroups:
     - auto-c5-az1
     - auto-c5-4xaz2
   status:
     conditions:
     // true when all IGs in the spec are present in SageMaker cluster, false otherwise
     - lastTransitionTime: "<timestamp>"
       message: ""
       observedGeneration: 3
       reason: InstanceGroupReady
       status: "True"
       type: InstanceGroupReady
     // true if subnets of IGs are discoverable, false otherwise
     - lastTransitionTime: "<timestamp>"
       message: ""
       observedGeneration: 3
       reason: SubnetsReady
       status: "True"
       type: SubnetsReady
     // true when all dependent resources are Ready [InstanceGroup, Subnets]
     - lastTransitionTime: "<timestamp>"
       message: ""
       observedGeneration: 3
       reason: Ready
       status: "True"
       type: Ready
     instanceGroups:
     - desiredLabels:
       - key: <custom_label_key>
         value: <custom_label_value>
       - key: nvidia.com/mig.config
         value: all-1g.5gb
       instanceTypes:
       - ml.c5.xlarge
       name: auto-c5-az1
       subnets:
       - id: <subnet-id>
         zone: <availability-zone-a>
         zoneId: <zone-id-a>
     - instanceTypes:
       - ml.c5.4xlarge
       name: auto-c5-4xaz2
       subnets:
       - id: <subnet-id>
         zone: <availability-zone-b>
         zoneId: <zone-id-b>
   ```

# Créez un NodePool
<a name="sagemaker-hyperpod-eks-autoscaling-nodepool"></a>

L’élément `NodePool` définit des contraintes sur les nœuds qui peuvent être créés par Karpenter et les pods qui peuvent s’exécuter sur ces nœuds. L’élément `NodePool` peut être configuré pour faire des choses comme :
+ Limiter la création de nœuds à certaines zones, à certains types d’instances et à certaines architectures informatiques.
+ Définir des étiquettes ou des rejets pour limiter le nombre de pods pouvant fonctionner sur les nœuds créés par Karpenter.

**Note**  
HyperPod le fournisseur prend en charge un ensemble limité d'exigences bien connues de Kubernetes et Karpenter expliquées ci-dessous. 

Les étapes suivantes décrivent comment créer un élément `NodePool`.

1. Créez un fichier YAML nommé nodepool.yaml contenant la configuration `NodePool` que vous souhaitez.

1. Vous pouvez utiliser l’exemple de configuration ci-dessous.

   Recherchez `Ready` sous `Conditions` pour indiquer que toutes les ressources dépendantes fonctionnent correctement.

   ```
   apiVersion: karpenter.sh/v1
   kind: NodePool
   metadata:
    name: sample-np
   spec:
    template:
      spec:
        nodeClassRef:
         group: karpenter.sagemaker.amazonaws.com
         kind: HyperpodNodeClass
         name: multiazc5
        expireAfter: Never
        requirements:
           - key: node.kubernetes.io/instance-type
             operator: Exists
   ```

1. Appliquez l’élément `NodePool` à votre cluster :

   ```
   kubectl apply -f nodepool.yaml
   ```

1. Surveillez le statut de `NodePool` pour vous assurer que la condition `Ready` de statut est définie sur `True` :

   ```
   kubectl get nodepool sample-np -oyaml
   ```

   ```
   apiVersion: karpenter.sh/v1
   kind: NodePool
   metadata:
     name: <nodepool-name>
     uid: <resource-uid>
     ...
   spec:
     disruption:
       budgets:
       - nodes: 90%
       consolidateAfter: 0s
       consolidationPolicy: WhenEmptyOrUnderutilized
     template:
       spec:
         expireAfter: 720h
         nodeClassRef:
           group: karpenter.sagemaker.amazonaws.com
           kind: HyperpodNodeClass
           name: <nodeclass-name>
         requirements:
         - key: node.kubernetes.io/instance-type
           operator: Exists
   status:
     conditions:
     - lastTransitionTime: "<timestamp>"
       message: ""
       observedGeneration: 2
       reason: ValidationSucceeded
       status: "True"
       type: ValidationSucceeded
     - lastTransitionTime: "<timestamp>"
       message: ""
       observedGeneration: 2
       reason: NodeClassReady
       status: "True"
       type: NodeClassReady
     - lastTransitionTime: "<timestamp>"
       message: ""
       observedGeneration: 2
       reason: Ready
       status: "True"
       type: Ready
   ```

**Étiquettes compatibles pour Karpenter Provider HyperPod**

Il s’agit des contraintes et exigences facultatives que vous pouvez spécifier dans votre configuration de `NodePool`.


|  Type d’exigence  |  Objectif  |   Case/Supported Valeurs d'utilisation  |  Recommendation  | 
| --- | --- | --- | --- | 
|  Types d’instances (`node.kubernetes.io/instance-type`)  |  Contrôle les types d' SageMaker instances parmi lesquels Karpenter peut choisir  |  Au lieu de vous limiter à ml.c5.xlarge, laissez Karpenter choisir parmi tous les types disponibles dans vos groupes d’instances.  |  Laissez ce paramètre non défini ou utilisez l’opérateur Exists pour donner à Karpenter une flexibilité maximale dans le choix de types d’instances économiques.  | 
|  Zones de disponibilité (`topology.kubernetes.io/zone`)  |  Contrôle les zones de AWS disponibilité dans lesquelles les nœuds peuvent être créés  |  Noms de zone spécifiques comme us-east-1c. À utiliser lorsque vous avez besoin que les pods s’exécutent dans des zones spécifiques pour des raisons de latence ou de conformité.  | N/A | 
|  Architecture (`kubernetes.io/arch`)  |  Spécifie l’architecture des CPU  |  Uniquement amd64 (aucune prise en charge ARM actuellement)  |  N/A  | 

# Déploiement d’une charge de travail
<a name="sagemaker-hyperpod-eks-autoscaling-workload"></a>

Les exemples suivants montrent comment la HyperPod mise à l'échelle automatique avec Karpenter provisionne automatiquement les nœuds en réponse aux demandes de charge de travail. Ces exemples montrent le comportement de mise à l’échelle de base et les modèles de distribution à plusieurs zones de disponibilité.

**Déploiement d’une charge de travail simple**

1. Le déploiement Kubernetes suivant inclut des pods qui demandent 1 CPU et 256 Mo de mémoire par réplica ou par pod. Dans ce scénario, les pods ne sont pas encore activés.

   ```
   kubectl apply -f https://raw.githubusercontent.com/aws/karpenter-provider-aws/refs/heads/main/examples/workloads/inflate.yaml
   ```

1. Pour tester le processus d’augmentation verticale, exécutez la commande suivante. Karpenter ajoutera de nouveaux nœuds au cluster.

   ```
   kubectl scale deployment inflate --replicas 10
   ```

1. Pour tester le processus de réduction verticale, exécutez la commande suivante. Karpenter supprimera des nœuds du cluster.

   ```
   kubectl scale deployment inflate --replicas 0
   ```

**Déployer une charge de travail sur plusieurs AZs**

1. Exécutez la commande suivante pour déployer une charge de travail qui exécute un déploiement Kubernetes dans lequel les pods en déploiement doivent être répartis uniformément entre les différentes zones de disponibilité avec une asymétrie maximale de 1.

   ```
   kubectl apply -f https://raw.githubusercontent.com/aws/karpenter-provider-aws/refs/heads/main/examples/workloads/spread-zone.yaml
   ```

1. Exécutez la commande suivante pour ajuster le nombre de pods :

   ```
   kubectl scale deployment zone-spread --replicas 15
   ```

   Karpenter ajoutera de nouveaux nœuds au cluster avec au moins un nœud dans une zone de disponibilité différente.

Pour plus d'exemples, consultez les exemples de [charges de travail de Karpenter](https://github.com/aws/karpenter-provider-aws/tree/main/examples/workloads) sur. GitHub