翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
トラブルシューティング
次のページには、HyperPod EKS クラスターのトラブルシューティングに関する既知のソリューションが記載されています。
[Dashboard] (ダッシュボード) タブ
EKS アドオンのインストールに失敗しました
EKS アドオンのインストールを正常に完了するには、Kubernetes バージョン 1.30 以降が必要です。更新するには、「Kubernetes バージョンを更新する」を参照してください。
EKS アドオンのインストールを正常に完了するには、すべてのノードが [準備完了] ステータスで、すべてのポッドが [実行中] ステータスである必要があります。
ノードのステータスを確認するには、 list-cluster-nodes AWS CLI コマンドを使用するか、EKS コンソールで EKS
ポッドのステータスを確認するには、Kubernetes CLIkubectl get pods -n cloudwatch-agent を使用するか、EKS コンソールcloudwatch-agent を持つポッドのステータスを表示します。ポッドの問題を解決するか、管理者に連絡して問題を解決してください。すべてのポッドのステータスが [実行中] になったら、Amazon SageMaker AI コンソール
トラブルシューティングの詳細については、「Amazon CloudWatch オブザーバビリティ EKS アドオンのトラブルシューティング」を参照してください。
タスクタブ
クラスターでカスタムリソース定義 (CRD) が設定されていないというエラーメッセージが表示された場合は、ドメイン実行ロールに EKSAdminViewPolicy ポリシーと ClusterAccessRole ポリシーを付与します。
-
実行ロールを取得する方法の詳細については、「実行ロールを取得する」を参照してください。
-
IAM ユーザーまたはグループにポリシーをアタッチする方法については、「IAM ID のアクセス許可の追加および削除」を参照してください。
ポリシー
HyperPod API またはコンソールを使用したポリシー関連エラーのソリューション一覧は、以下のとおりです。
-
ポリシーのステータスが
CreateFailedまたはCreateRollbackFailedの場合、失敗したポリシーを削除して新しいポリシーを作成する必要があります。 -
ポリシーのステータスが
UpdateFailedの場合、同じポリシー ARN を使用して更新を再試行します。 -
ポリシーのステータスが
UpdateRollbackFailedの場合、失敗したポリシーを削除して新しいポリシーを作成する必要があります。 -
ポリシーのステータスが
DeleteFailedまたはDeleteRollbackFailedの場合、同じポリシー ARN を使用して削除を再試行します。-
HyperPod コンソールを使用してコンピューティング優先順位付けまたはクラスターポリシーを削除しようとしてエラーが発生した場合は、API を使用して
cluster-scheduler-configを削除してみます。リソースのステータスを確認するには、コンピューティング割り当ての詳細ページに移動します。
-
失敗の詳細を確認するには、describe API を使用します。
クラスターの削除
クラスターの削除に関連するエラーの既知のソリューションは、以下のとおりです。
-
SageMaker HyperPod タスクガバナンスポリシーがアタッチされたためにクラスターの削除に失敗した場合、ポリシーを削除する が必要です。
-
以下のアクセス許可がないためにクラスターの削除に失敗した場合、クラスター管理者のアクセス許可の最小限のセットを更新する必要があります。「クラスター管理者の IAM ユーザー」セクションの [Amazon EKS] タブを参照してください。
-
sagemaker:ListComputeQuotas -
sagemaker:ListClusterSchedulerConfig -
sagemaker:DeleteComputeQuota -
sagemaker:DeleteClusterSchedulerConfig
-
未割り当てのリソース共有
未割り当てのリソースプール容量が想定よりも小さい場合:
-
ノードの準備完了ステータスを確認する
kubectl get nodesSTATUS 列にすべてのノード
Readyのステータスが表示されていることを確認します。 -
ノードのスケジュール可能なステータスを確認する
kubectl get nodes -o custom-columns=NAME:.metadata.name,UNSCHEDULABLE:.spec.unschedulableノードに
<none>またはfalse( ではなく) が表示されていることを確認しますtrue。 -
未割り当てのリソース共有 ClusterQueues を一覧表示します。
kubectl get clusterqueue | grep hyperpod-ns-idle-resource-sharingこれにより、未割り当てのリソース共有 ClusterQueues がすべて表示されます。ClusterQueues が表示されない場合は、ClusterSchedulerConfig ポリシー
FailureReasonの で、デバッグを続行する失敗メッセージがあるかどうかを確認してください。 -
未割り当てのリソース共有クォータを確認します。
kubectl describe clusterqueue hyperpod-ns-idle-resource-sharing-<index>spec.resourceGroups[].flavors[].resourcesセクションをチェックして、各リソースフレーバーに割り当てられたクォータを確認します。クラスター内のリソースフレーバーの数によっては、複数の未割り当てのリソース共有 ClusterQueues が存在する場合があります。
-
MIG 設定ステータス (GPU ノード):
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.nvidia\.com/mig\.config\.state}{"\n"}{end}'MIG 対応ノード
successの状態が表示されていることを確認します。
