Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Risoluzione dei problemi
<a name="sagemaker-hyperpod-eks-operate-console-ui-governance-troubleshoot"></a>

La pagina seguente contiene soluzioni note per la risoluzione dei problemi dei cluster EKS. HyperPod

**Topics**
+ [Scheda Pannello di controllo](#hp-eks-troubleshoot-dashboard)
+ [Scheda Attività](#hp-eks-troubleshoot-tasks)
+ [Policy](#hp-eks-troubleshoot-policies)
+ [Eliminazione dei cluster](#hp-eks-troubleshoot-delete-policies)
+ [Condivisione di risorse non allocate](#hp-eks-troubleshoot-unallocated-resource-sharing)

## Scheda Pannello di controllo
<a name="hp-eks-troubleshoot-dashboard"></a>

**Installazione non riuscita del componente aggiuntivo EKS**

Per installare correttamente il componente aggiuntivo EKS, è necessaria una versione di Kubernets >= 1.30. Per l’aggiornamento, consulta [Update Kubernetes version](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html).

Per installare correttamente il componente aggiuntivo EKS, tutti i nodi devono essere in stato **Pronto** e tutti i pod devono essere in stato **In esecuzione**. 

Per verificare lo stato dei nodi, utilizza il [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 comando o accedi al cluster EKS nella [console EKS](https://console.aws.amazon.com/eks/home#/clusters) e visualizza lo stato dei nodi. Risolvi il problema per ogni nodo o contatta il tuo amministratore. Se lo stato del nodo è **Sconosciuto**, elimina il nodo. Una volta che tutti gli stati dei nodi sono **pronti**, riprova a installare il componente aggiuntivo EKS HyperPod dalla console [Amazon SageMaker ](https://console.aws.amazon.com/sagemaker/) AI.

Per controllare lo stato dei pod, utilizza il comando della [CLI di Kubernetes](https://kubernetes.io/docs/reference/kubectl/) `kubectl get pods -n cloudwatch-agent` o accedi al cluster EKS nella [console EKS](https://console.aws.amazon.com/eks/home#/clusters) e visualizza lo stato dei pod con il namespace `cloudwatch-agent`. Risolvi il problema dei pod o contatta il tuo amministratore. Una volta che tutti gli stati del pod sono **in esecuzione**, riprova a installare il componente aggiuntivo EKS HyperPod dalla console [Amazon SageMaker ](https://console.aws.amazon.com/sagemaker/) AI.

Per ulteriori informazioni sulla risoluzione dei problemi, consulta [Risoluzione dei problemi del componente aggiuntivo Amazon CloudWatch Observability EKS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html#Container-Insights-setup-EKS-addon-troubleshoot).

## Scheda Attività
<a name="hp-eks-troubleshoot-tasks"></a>

Se viene visualizzato il messaggio di errore relativo alla **mancata configurazione della Definizione di risorse personalizzate (CRD) nel cluster**, assegna le policy `EKSAdminViewPolicy` e `ClusterAccessRole` al ruolo di esecuzione del dominio. 
+ Per informazioni su come ottenere il ruolo di esecuzione, consulta [Acquisizione del ruolo di esecuzione](sagemaker-roles.md#sagemaker-roles-get-execution-role).
+ Per informazioni su come collegare le policy a un utente o a un gruppo IAM, consulta [Adding and removing IAM identity permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).

## Policy
<a name="hp-eks-troubleshoot-policies"></a>

Di seguito sono elencate le soluzioni agli errori relativi alle politiche che utilizzano le HyperPod API o la console.
+ Se la policy è in stato `CreateFailed` o `CreateRollbackFailed`, devi eliminare la policy non riuscita e crearne una nuova.
+ Se la policy è in stato `UpdateFailed`, prova a eseguire di nuovo l’aggiornamento con lo stesso ARN della policy.
+ Se la policy è in stato `UpdateRollbackFailed`, devi eliminare la policy non riuscita e crearne una nuova.
+ Se la policy è in stato `DeleteFailed` o `DeleteRollbackFailed`, prova a eliminarla di nuovo con lo stesso ARN della policy.
  + Se hai riscontrato un errore durante il tentativo di eliminare la **prioritizzazione di Compute**, o la policy del cluster, utilizzando la HyperPod console, prova a eliminarlo utilizzando l'`cluster-scheduler-config`API. Per verificare lo stato della risorsa, vai alla pagina dei dettagli di un’allocazione delle risorse di calcolo.

Per visualizzare maggiori dettagli sull’errore, utilizza l’API describe.

## Eliminazione dei cluster
<a name="hp-eks-troubleshoot-delete-policies"></a>

Di seguito sono elencate le soluzioni note per gli errori relativi all’eliminazione dei cluster.
+ Se l'eliminazione del cluster fallisce a causa delle politiche di governance delle SageMaker HyperPod attività allegate, dovrai farlo. [Eliminazione delle policy](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-delete.md)
+ Se l’eliminazione del cluster non riesce perché mancano le autorizzazioni seguenti, devi aggiornare il set minimo di autorizzazioni dell’amministratore del cluster. Consulta la scheda **Amazon EKS** nella sezione [Utenti IAM per l’amministratore del cluster](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin).
  + `sagemaker:ListComputeQuotas`
  + `sagemaker:ListClusterSchedulerConfig`
  + `sagemaker:DeleteComputeQuota`
  + `sagemaker:DeleteClusterSchedulerConfig`

## Condivisione di risorse non allocate
<a name="hp-eks-troubleshoot-unallocated-resource-sharing"></a>

Se la capacità del pool di risorse non allocate è inferiore al previsto:

1. **Verifica lo stato di disponibilità del nodo**

   ```
   kubectl get nodes
   ```

   Verifica che tutti i nodi mostrino `Ready` lo stato nella colonna STATUS.

1. **Controlla lo stato di pianificazione del nodo**

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

   Verifica che i nodi mostrino `<none>` o `false` (no`true`).

1. **Elenca la condivisione di risorse non allocate: ClusterQueues**

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

   Questo mostra tutte le condivisioni di risorse non allocate. ClusterQueues Se non ClusterQueues vengono visualizzati, controlla la ClusterSchedulerConfig politica `FailureReason` sottostante per vedere se ci sono messaggi di errore per continuare il debug.

1. **Verifica la quota di condivisione delle risorse non allocate:**

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

   Controlla la `spec.resourceGroups[].flavors[].resources` sezione per vedere la quota assegnata per ogni tipo di risorsa.

   È ClusterQueues possibile che esista una condivisione multipla di risorse non allocate a seconda del numero di tipologie di risorse presenti nel cluster. 

1. **Verifica lo stato della configurazione MIG (nodi GPU):**

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

   Verifica lo stato MIG-enabled dei nodi. `success`