Solución de problemas - Amazon SageMaker AI
Pestaña PanelPestaña TareasPolíticasEliminación de clústeresUso compartido de recursos no asignados

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Solución de problemas

La siguiente página contiene soluciones conocidas para solucionar problemas de sus clústeres de HyperPod EKS.

Pestaña Panel

El complemento de EKS no se instala

Para que la instalación del complemento de EKS se realice correctamente, necesita una versión de Kubernets >= 1.30. Para actualizar, consulte Actualización del clúster existente a la nueva versión de Kubernetes.

Para que la instalación del complemento de EKS se realice correctamente, todos los nodos deben tener el estado Listo y todos los pods deben tener el estado En ejecución.

Para comprobar el estado de los nodos, utilice el list-cluster-nodes AWS CLI comando o navegue hasta el clúster de EKS en la consola de EKS y consulte el estado de los nodos. Resuelva el problema de cada nodo o póngase en contacto con su administrador. Si el estado del nodo es Desconocido, elimínelo. Cuando todos los estados de los nodos estén listos, vuelva a intentar instalar el complemento EKS HyperPod desde la consola Amazon SageMaker AI.

Para comprobar el estado de los pods, utilice el comando kubectl get pods -n cloudwatch-agent de la CLI de Kubernetes o navegue hasta el clúster de EKS en la consola de EKS y consulte el estado de los pods con el espacio de nombres cloudwatch-agent. Resuelve el problema de los pods o contacte con su administrador para resolverlo. Cuando todos los estados de los pods estén en ejecución, vuelve a intentar instalar el complemento EKS HyperPod desde la consola Amazon SageMaker AI.

Para obtener más información sobre la solución de problemas, consulte Solución de problemas del complemento Amazon CloudWatch Observability EKS.

Pestaña Tareas

Si aparece un mensaje de error que indica que la definición de recurso personalizada (CRD) no está configurada en el clúster, asígnele las políticas EKSAdminViewPolicy y ClusterAccessRole a su rol de ejecución de dominio.

Políticas

A continuación se enumeran las soluciones a los errores relacionados con las políticas que utilizan la consola HyperPod APIs o.

  • Si la política tiene los estados CreateFailed o CreateRollbackFailed, deberá eliminar la política fallida y crear una nueva.

  • Si la política tiene el estado UpdateFailed, vuelva a intentar la actualización con el mismo ARN de política.

  • Si la política tiene el estado UpdateRollbackFailed, deberá eliminar la política fallida y crear una nueva.

  • Si la política tiene los estados DeleteFailed y DeleteRollbackFailed, vuelva a intentar la eliminación con el mismo ARN de política.

    • Si se ha producido un error al intentar eliminar la política de clústeres o de priorización de procesamiento mediante la HyperPod consola, intente eliminarla cluster-scheduler-config mediante la API. Para comprobar el estado del recurso, vaya a la página de detalles de una asignación de recursos de computación.

Para ver más detalles sobre el error, usa la API de descripción.

Eliminación de clústeres

A continuación se enumeran las soluciones conocidas a los errores relacionados con la eliminación de clústeres.

  • Si se produce un error al eliminar un clúster debido a las políticas de control de SageMaker HyperPod tareas adjuntas, tendrás que hacerloEliminación de políticas.

  • Si se produce un error al eliminar el clúster debido a la falta de los siguientes permisos, tendrá que actualizar el conjunto mínimo de permisos del administrador del clúster. Consulte la pestaña Amazon EKS en la sección Usuarios de IAM para la administración de clústeres.

    • sagemaker:ListComputeQuotas

    • sagemaker:ListClusterSchedulerConfig

    • sagemaker:DeleteComputeQuota

    • sagemaker:DeleteClusterSchedulerConfig

Uso compartido de recursos no asignados

Si la capacidad de su fondo de recursos no asignado es inferior a la esperada:

  1. Compruebe el estado del nodo listo

    kubectl get nodes

    Compruebe que todos los nodos muestren Ready su estado en la columna STATUS.

  2. Compruebe el estado programable del nodo

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

    Compruebe si los nodos se muestran <none> o false notrue.

  3. Listar el uso compartido ClusterQueues de recursos no asignados:

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

    Muestra todos los recursos compartidos no asignados. ClusterQueues Si no ClusterQueues aparecen, compruebe la FailureReason siguiente ClusterSchedulerConfig política para ver si hay algún mensaje de error para continuar con la depuración.

  4. Compruebe la cuota de uso compartido de recursos no asignada:

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

    Consulte la spec.resourceGroups[].flavors[].resources sección para ver la cuota asignada a cada tipo de recurso.

    ClusterQueues Es posible que se compartan varios recursos no asignados en función del número de tipos de recursos del clúster.

  5. Compruebe el estado de la configuración de MIG (nodos de GPU):

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

    Compruebe que los nodos habilitados para MIG muestren su estado. success