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

# Gestione dei carichi di lavoro Ray con kubectl
<a name="sagemaker-hyperpod-ray-manage-kubectl"></a>

Ray on utilizza le risorse personalizzate originali senza modifiche. HyperPod KubeRay Se utilizzi già Ray su Kubernetes, i tuoi manifesti esistenti rimangono invariati e la documentazione di Ray è il riferimento per ogni campo. Questa pagina illustra le specifiche di. HyperPod

L'accesso alle risorse Ray è garantito dalle politiche di HyperPod accesso al cluster. Usa `AmazonSagemakerHyperpodTrainingPolicy` per`RayCluster`,`RayJob`, e`RayCronJob`, o `AmazonSagemakerHyperpodInferencePolicy` per `RayCluster` e. `RayService` Associa la policy alla voce di accesso Amazon EKS per il tuo principale IAM, con ambito a un namespace quando i team condividono un cluster.

Se il tuo principale è un ruolo di esecuzione di un dominio SageMaker AI, la HyperPod console concede la policy e crea la voce di accesso per te. Per ulteriori informazioni, consulta [Configurare Studio per Ray](sagemaker-hyperpod-ray-studio-setup.md).

## Risorse personalizzate supportate
<a name="sagemaker-hyperpod-ray-manage-kubectl-resources"></a>


| Risorsa | Usalo per | Documentazione di riferimento | 
| --- | --- | --- | 
| RayCluster | Un cluster di lunga durata a cui invii il lavoro. | [RayCluster Guida introduttiva ](https://docs.ray.io/en/latest/cluster/kubernetes/getting-started/raycluster-quick-start.html) nella documentazione di Ray | 
| RayJob | Un solo lavoro. KubeRay crea un cluster, esegue il lavoro e scompone il cluster quando lo shutdownAfterJobFinishes ètrue. | [RayJob Guida introduttiva ](https://docs.ray.io/en/latest/cluster/kubernetes/getting-started/rayjob-quick-start.html) nella documentazione di Ray | 
| RayCronJob | Un lavoro ricorrente in base a una pianificazione cron, come l'inferenza notturna dei batch. Se spec.timeZone è impostato su un nome IANA, la pianificazione segue il fuso orario locale del controller. | [RayCronJob Guida introduttiva ](https://docs.ray.io/en/latest/cluster/kubernetes/getting-started/raycronjob-quick-start.html) nella documentazione di Ray | 
| RayService | Un'applicazione Ray Serve, dichiarata inserveConfigV2, con aggiornamenti senza tempi di inattività. Per HyperPod esempi funzionanti, vedere e. [Implementazione di un modello con Ray Serve](sagemaker-hyperpod-ray-deploy-model.md) [Implementazione di un JumpStart modello con Ray Serve](sagemaker-hyperpod-ray-deploy-jumpstart-model.md) | [RayService Guida introduttiva ](https://docs.ray.io/en/latest/cluster/kubernetes/getting-started/rayservice-quick-start.html) nella documentazione di Ray | 

**Nota**  
`RayCronJob`richiede la versione KubeRay 1.6.0 o successiva. Su un operatore precedente il tipo di risorsa non esiste. Per ulteriori informazioni, consulta [Installazione KubeRay su HyperPod Amazon EKS](sagemaker-hyperpod-ray-install-kuberay.md).

## Creazione di un cluster
<a name="sagemaker-hyperpod-ray-manage-kubectl-create"></a>

Il seguente manifest crea un head pod e un gruppo di lavoro GPU sui HyperPod nodi.

```
apiVersion: ray.io/v1
kind: RayCluster
metadata:
  name: {{my-cluster}}
  namespace: {{my-namespace}}
spec:
  rayVersion: "2.55.1"
  headGroupSpec:
    rayStartParams:
      dashboard-host: "0.0.0.0"
    template:
      spec:
        containers:
          - name: ray-head
            image: rayproject/ray:2.55.1
            ports:
              - { containerPort: 6379, name: gcs-server }
              - { containerPort: 8265, name: dashboard }
              - { containerPort: 10001, name: client }
            resources:
              requests: { cpu: "2", memory: "4Gi" }
  workerGroupSpecs:
    - groupName: gpu-workers
      replicas: 2
      rayStartParams: {}
      template:
        spec:
          nodeSelector:
            node.kubernetes.io/instance-type: ml.g5.xlarge
          containers:
            - name: ray-worker
              image: rayproject/ray:2.55.1-gpu
              resources:
                limits: { nvidia.com/gpu: "1" }
                requests: { cpu: "4", memory: "16Gi", nvidia.com/gpu: "1" }
```

```
kubectl apply -f my-cluster.yaml -n {{my-namespace}}
kubectl get raycluster {{my-cluster}} -n {{my-namespace}}
```

**Importante**  
`dashboard-host`Impostato `0.0.0.0` su nel gruppo principale. Il Ray Endpoint Operator ne ha bisogno per servire il pannello di controllo esterno all'headpod e l'accesso autenticato al dashboard non funziona senza di esso.

Il cluster è pronto quando l'head pod e almeno un worker pod sono in funzione. `RayJob``RayCronJob`, e `RayService` seguono lo stesso schema di applicazione e verifica, e ognuno incorpora un oggetto `rayClusterSpec` con la stessa forma di quello precedente. `spec`

Per ogni campo accettato da queste risorse, vedi [ RayCluster Configurazione ](https://docs.ray.io/en/latest/cluster/kubernetes/user-guides/config.html) nella documentazione di Ray.

## Invio di lavori a un cluster in esecuzione
<a name="sagemaker-hyperpod-ray-manage-kubectl-submit"></a>

L'applicazione di a `RayJob` crea un cluster per quel lavoro. Per inviare a un cluster già in esecuzione, usa il `toolkit-for-ray-on-sagemaker-ai` pacchetto. Per ulteriori informazioni, consulta [Invio di lavori in remoto con la libreria del toolkit](sagemaker-hyperpod-ray-remote-job-submission.md).