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
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 perRayCluster,RayJob, eRayCronJob, 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.
Risorse personalizzate supportate
| Risorsa | Usalo per | Documentazione di riferimento |
|---|---|---|
RayCluster |
Un cluster di lunga durata a cui invii il lavoro. | RayCluster Guida introduttiva |
RayJob |
Un solo lavoro. KubeRay crea un cluster, esegue il lavoro e scompone il cluster quando lo shutdownAfterJobFinishes ètrue. |
RayJob Guida introduttiva |
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 |
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 Implementazione di un JumpStart modello con Ray Serve |
RayService Guida introduttiva |
Nota
RayCronJobrichiede 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.
Creazione di un cluster
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-clusternamespace:my-namespacespec: 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 -nmy-namespacekubectl get rayclustermy-cluster-nmy-namespace
Importante
dashboard-hostImpostato 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. RayJobRayCronJob, 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
Invio di lavori a un cluster in esecuzione
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.