View a markdown version of this page

Dépannage - Amazon SageMaker AI

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

La page suivante contient des solutions connues pour résoudre les problèmes liés à vos clusters HyperPod EKS.

Onglet Dashboard (Tableau de bord)

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

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 list-cluster-nodes AWS CLI commande ou accédez à votre cluster EKS dans la console EKS et visualisez 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 l'état de tous les nœuds est prêt, réessayez d'installer le module complémentaire EKS HyperPod depuis la console Amazon SageMaker AI.

Pour vérifier le statut de vos pods, utilisez la commande CLI Kubernetes kubectl get pods -n cloudwatch-agent ou accédez à votre cluster EKS dans la console EKS 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 états des pods sont en cours d'exécution, réessayez d'installer le module complémentaire EKS HyperPod depuis la console Amazon SageMaker AI.

Pour en savoir plus sur la résolution des problèmes, consultez Résolution des problèmes liés au module complémentaire Amazon CloudWatch Observability EKS.

Onglet Tâches

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.

Stratégies

La liste suivante répertorie les solutions aux erreurs liées aux politiques à l'aide des HyperPod API ou de la console.

  • 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-configaide 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

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 faireSuppression de politiques.

  • 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:ListComputeQuotas

    • sagemaker:ListClusterSchedulerConfig

    • sagemaker:DeleteComputeQuota

    • sagemaker:DeleteClusterSchedulerConfig

Partage de ressources non allouées

Si la capacité de votre pool de ressources non allouées est inférieure aux attentes :

  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.

  2. 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 sont false affichés <none> ou nontrue.

  3. Répertorier le partage ClusterQueues de ressources non alloué :

    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 FailureReason ClusterSchedulerConfig politique ci-dessous pour voir s'il existe des messages d'échec vous empêchant de poursuivre le débogage.

  4. Vérifiez le quota de partage de ressources non alloué :

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

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

    Le partage de plusieurs ressources non allouées ClusterQueues peut exister en fonction du nombre de types de ressources de votre cluster.

  5. 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 l'successétat MIG-enabled des nœuds est affiché.

Add-on échec de la mise à niveau de la version 1.3.x vers la version 1.5.0

Symptôme : lors de la mise à niveau du module complémentaire de gouvernance des tâches directement de la version 1.3.x (Kueue v0.12) à la version 1.5.0 (Kueue v0.18)aws eks update-addon, l'extension passe à l'état avec l'erreur suivante : UPDATE_FAILED

CustomResourceDefinition.apiextensions.k8s.io "cohorts.kueue.x-k8s.io" is invalid: status.storedVersions[0]: Invalid value: "v1alpha1": missing from spec.versions; v1alpha1 was previously a storage version, and must remain in spec.versions until a storage migration ensures no data remains persisted in v1alpha1 and removes v1alpha1 from status.storedVersions

Résolution : utilisez l'option de mise à niveau dans la HyperPod console SageMaker AI. La console gère automatiquement la migration du CRD en sauvegardant les ressources existantes, en migrant les versions stockées, en mettant à niveau le module complémentaire et en restaurant les ressources. Pour effectuer la migration manuellement via l'interface du module complémentaire Amazon EKS, consultezMise à niveau de la version 1.3.x vers la version 1.5.