View a markdown version of this page

疑難排解 - Amazon SageMaker AI
儀表板索引標籤任務索引標籤政策刪除叢集未配置的資源共用

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

疑難排解

以下頁面包含針對 HyperPod EKS 叢集進行疑難排解的已知解決方案。

儀表板索引標籤

無法安裝 EKS 附加元件

若要讓 EKS 附加元件安裝成功，您將需要 Kubernets 版本 >= 1.30。若要更新，請參閱更新 Kubernetes 版本。

若要讓 EKS 附加元件安裝成功，所有節點都必須處於備妥狀態，且所有 Pod 都必須處於執行中狀態。

若要檢查節點的狀態，請使用 list-cluster-nodes AWS CLI 命令或導覽至 EKS 主控台中的 EKS 叢集，並檢視節點的狀態。解決每個節點的問題，或聯絡您的管理員。如果節點狀態為不明，請刪除節點。一旦所有節點狀態都是備妥，請從 Amazon SageMaker AI 主控台重試在 HyperPod 中安裝 EKS 附加元件。

若要檢查 Pod 的狀態，請使用 Kubernetes CLI 命令 kubectl get pods -n cloudwatch-agent，或在 EKS 主控台中導覽至您的 EKS 叢集，並使用命名空間 cloudwatch-agent 檢視 Pod 的狀態。解決 Pod 的問題，或聯絡您的管理員以解決問題。一旦所有 Pod 狀態都是執行中，請從 Amazon SageMaker AI 主控台重試在 HyperPod 中安裝 EKS 附加元件。

如需更多疑難排解，請參閱針對 Amazon CloudWatch 可觀測性 EKS 附加元件進行疑難排解。

任務索引標籤

如果您看到有關為何未在叢集上設定自訂資源定義 (CRD) 的錯誤訊息，請將 EKSAdminViewPolicy 和 ClusterAccessRole 政策授予您的網域執行角色。

政策

以下列出了使用 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

未配置的資源共用

如果您未配置的資源集區容量低於預期：

  1. 檢查節點就緒狀態

    kubectl get nodes

    驗證所有節點是否在 STATUS 欄中顯示Ready狀態。

  2. 檢查節點可排程狀態

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

    驗證節點是否顯示 <none>或 false（而非 true)。

  3. 列出未配置的資源共用 ClusterQueues：

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

    這會顯示所有未配置的資源共用 ClusterQueues 如果 ClusterQueues 未顯示，請檢查 ClusterSchedulerConfig 政策FailureReason下的 ，以查看是否有任何失敗訊息以繼續偵錯。

  4. 驗證未配置的資源共用配額：

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

    檢查 spec.resourceGroups[].flavors[].resources區段以查看為每個資源口味配置的配額。

    視叢集中的資源樣式而定，可能會有多個未配置的資源共用 ClusterQueues。

  5. 檢查 MIG 組態狀態 (GPU 節點）：

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

    驗證啟用 MIG 的節點會顯示success狀態。