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.

# Dépannage
<a name="sagemaker-hyperpod-eks-operate-console-ui-governance-troubleshoot"></a>

La page suivante contient des solutions connues pour le dépannage de vos clusters HyperPod EKS.

**Topics**
+ [Onglet Dashboard (Tableau de bord)](#hp-eks-troubleshoot-dashboard)
+ [Onglet Tâches](#hp-eks-troubleshoot-tasks)
+ [Stratégies](#hp-eks-troubleshoot-policies)
+ [Suppression de clusters](#hp-eks-troubleshoot-delete-policies)
+ [Partage de ressources non allouées](#hp-eks-troubleshoot-unallocated-resource-sharing)

## Onglet Dashboard (Tableau de bord)
<a name="hp-eks-troubleshoot-dashboard"></a>

**Échec de l’installation du module complémentaire EKS**

Pour que l’installation du module complémentaire EKS réussisse, vous devez disposer d’une version de Kubernetes >= 1.30. Pour effectuer une mise à jour, consultez [Mise à jour de la version de Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html).

Pour que l’installation du module complémentaire EKS réussisse, tous les nœuds doivent présenter le statut **Prêt** et tous les pods doivent présenter le statut **En cours d’exécution**. 

Pour vérifier l'état de vos nœuds, utilisez la [https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-cluster-nodes.html](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-cluster-nodes.html) AWS CLI commande ou accédez à votre cluster EKS dans la [console EKS](https://console.aws.amazon.com/eks/home#/clusters) et consultez l'état de vos nœuds. Résolvez le problème pour chaque nœud ou contactez votre administrateur. Si le statut du nœud est **Inconnu**, supprimez le nœud. Une fois que le statut de tous les nœuds **est prêt**, réessayez d'installer le module complémentaire EKS HyperPod depuis la console [Amazon SageMaker AI](https://console.aws.amazon.com/sagemaker/).

Pour vérifier le statut de vos pods, utilisez la commande [CLI Kubernetes](https://kubernetes.io/docs/reference/kubectl/) `kubectl get pods -n cloudwatch-agent` ou accédez à votre cluster EKS dans la [console EKS](https://console.aws.amazon.com/eks/home#/clusters) et consultez le statut de vos pods avec l’espace de noms `cloudwatch-agent`. Résolvez le problème relatif aux pods ou contactez votre administrateur pour le résoudre. Une fois que tous les statuts des pods sont **actifs**, réessayez d'installer le module complémentaire EKS HyperPod depuis la console [Amazon SageMaker AI](https://console.aws.amazon.com/sagemaker/).

Pour plus de résolution des problèmes, consultez la section [Résolution des problèmes liés au module complémentaire Amazon CloudWatch Observability EKS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html#Container-Insights-setup-EKS-addon-troubleshoot).

## Onglet Tâches
<a name="hp-eks-troubleshoot-tasks"></a>

Si le message d’erreur indiquant que la **définition de ressource personnalisée (CRD) n’est pas configurée sur le cluster** s’affiche, accordez les politiques `EKSAdminViewPolicy` et `ClusterAccessRole` à votre rôle d’exécution de domaine. 
+ Pour en savoir plus sur la façon d’obtenir votre rôle d’exécution, consultez [Obtention de votre rôle d’exécution](sagemaker-roles.md#sagemaker-roles-get-execution-role).
+ Pour découvrir comment attacher des politiques à un utilisateur ou à un groupe IAM, consultez [Ajout et suppression d’autorisations basées sur l’identité IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).

## Stratégies
<a name="hp-eks-troubleshoot-policies"></a>

La liste suivante répertorie les solutions aux erreurs liées aux politiques utilisant la console HyperPod APIs or.
+ Si la politique présente le statut `CreateFailed` ou `CreateRollbackFailed`, vous devez supprimer la politique qui a échoué, puis en créer une nouvelle.
+ Si la politique présente le statut `UpdateFailed`, réessayez la mise à jour avec le même ARN de politique.
+ Si la politique présente le statut `UpdateRollbackFailed`, vous devez supprimer la politique qui a échoué, puis en créer une nouvelle.
+ Si la politique présente le statut `DeleteFailed` ou `DeleteRollbackFailed`, réessayez la suppression avec le même ARN de politique.
  + Si vous avez rencontré une erreur en essayant de supprimer la **priorisation de calcul**, ou la politique de cluster, à l'aide de la HyperPod console, essayez de la supprimer à l'`cluster-scheduler-config`aide de l'API. Pour vérifier le statut de la ressource, accédez à la page de détails d’une allocation de calcul.

Pour en savoir plus sur l’échec, utilisez l’API de description.

## Suppression de clusters
<a name="hp-eks-troubleshoot-delete-policies"></a>

Les solutions connues aux erreurs liées à la suppression de clusters sont répertoriées ci-dessous.
+ Lorsque la suppression du cluster échoue en raison des politiques de gouvernance des SageMaker HyperPod tâches associées, vous devez le faire[Suppression de politiques](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-delete.md).
+ Lorsque la suppression du cluster échoue en raison de l’absence des autorisations suivantes, vous devez mettre à jour votre ensemble minimal d’autorisations d’administrateur de cluster. Consultez l’onglet **Amazon EKS** dans la section [Utilisateurs IAM pour l’administrateur de cluster](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin).
  + `sagemaker:ListComputeQuotas`
  + `sagemaker:ListClusterSchedulerConfig`
  + `sagemaker:DeleteComputeQuota`
  + `sagemaker:DeleteClusterSchedulerConfig`

## Partage de ressources non allouées
<a name="hp-eks-troubleshoot-unallocated-resource-sharing"></a>

Si la capacité de votre pool de ressources non allouées est inférieure à celle prévue :

1. **Vérifier l'état de préparation du nœud**

   ```
   kubectl get nodes
   ```

   Vérifiez que tous les nœuds affichent `Ready` leur statut dans la colonne STATUS.

1. **Vérifier l'état planifiable du nœud**

   ```
   kubectl get nodes -o custom-columns=NAME:.metadata.name,UNSCHEDULABLE:.spec.unschedulable
   ```

   Vérifiez que les nœuds s'affichent `<none>` ou `false` non`true`.

1. **Répertorier le partage ClusterQueues de ressources non allouées :**

   ```
   kubectl get clusterqueue | grep hyperpod-ns-idle-resource-sharing
   ```

   Cela montre tous les partages ClusterQueues de ressources non alloués. S'ils ne s' ClusterQueues affichent pas, vérifiez la ClusterSchedulerConfig politique `FailureReason` ci-dessous pour voir s'il existe des messages d'échec pour poursuivre le débogage.

1. **Vérifiez le quota de partage des ressources non allouées :**

   ```
   kubectl describe clusterqueue hyperpod-ns-idle-resource-sharing-<index>
   ```

   Consultez la `spec.resourceGroups[].flavors[].resources` section pour voir le quota alloué à chaque type de ressource.

   Plusieurs partages de ressources non allouées ClusterQueues peuvent exister en fonction du nombre de types de ressources dans votre cluster. 

1. **Vérifiez l'état de la configuration MIG (nœuds GPU) :**

   ```
   kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.nvidia\.com/mig\.config\.state}{"\n"}{end}'
   ```

   Vérifiez que les nœuds compatibles MiG affichent `success` leur état.