Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Verwaltung von Ray-Workloads mit kubectl
<a name="sagemaker-hyperpod-ray-manage-kubectl"></a>

Ray on HyperPod verwendet die benutzerdefinierten Upstream-Ressourcen ohne Änderung. KubeRay Wenn Sie Ray bereits auf Kubernetes ausführen, gelten Ihre vorhandenen Manifeste unverändert, und die Ray-Dokumentation ist die Referenz für jedes Feld. Diese Seite behandelt, was spezifisch für ist. HyperPod

Der Zugriff auf Ray-Ressourcen wird durch die HyperPod Cluster-Zugriffsrichtlinien gewährt. Verwenden Sie `AmazonSagemakerHyperpodTrainingPolicy` für `RayCluster``RayJob`, und`RayCronJob`, oder `AmazonSagemakerHyperpodInferencePolicy` für `RayCluster` und. `RayService` Ordnen Sie die Richtlinie dem Amazon EKS-Zugriffseintrag für Ihren IAM-Principal zu, der auf einen Namespace beschränkt ist, wenn Teams einen Cluster gemeinsam nutzen.

Wenn Ihr Principal eine SageMaker AI-Domain-Ausführungsrolle hat, erteilt die HyperPod Konsole die Richtlinie und erstellt den Zugriffseintrag für Sie. Weitere Informationen finden Sie unter [Studio für Ray einrichten](sagemaker-hyperpod-ray-studio-setup.md).

## Unterstützte benutzerdefinierte Ressourcen
<a name="sagemaker-hyperpod-ray-manage-kubectl-resources"></a>


| Ressource | Benutze es für | Referenz | 
| --- | --- | --- | 
| RayCluster | Ein Cluster mit langer Laufzeit, an den Sie Arbeiten einreichen. | [RayCluster Schnellstart ](https://docs.ray.io/en/latest/cluster/kubernetes/getting-started/raycluster-quick-start.html) in der Ray-Dokumentation | 
| RayJob | Ein einziger Job. KubeRay erstellt einen Cluster, führt den Job aus und zerreißt den Cluster, wenn er fertig shutdownAfterJobFinishes isttrue. | [RayJob Schnellstart ](https://docs.ray.io/en/latest/cluster/kubernetes/getting-started/rayjob-quick-start.html) in der Ray-Dokumentation | 
| RayCronJob | Ein wiederkehrender Job nach einem Cron-Zeitplan, z. B. nächtliche Batch-Inferenz. Auf einen IANA-Namen gesetztspec.timeZone, oder der Zeitplan folgt der lokalen Zeitzone des Controllers. | [RayCronJob Schnellstart ](https://docs.ray.io/en/latest/cluster/kubernetes/getting-started/raycronjob-quick-start.html) in der Ray-Dokumentation | 
| RayService | Eine Ray Serve-Anwendung, deklariert inserveConfigV2, mit Upgrades ohne Ausfallzeiten. Praktische HyperPod Beispiele finden Sie unter [Bereitstellung eines Modells mit Ray Serve](sagemaker-hyperpod-ray-deploy-model.md) und. [Bereitstellung eines JumpStart Modells mit Ray Serve](sagemaker-hyperpod-ray-deploy-jumpstart-model.md) | [RayService Schnellstart ](https://docs.ray.io/en/latest/cluster/kubernetes/getting-started/rayservice-quick-start.html) in der Ray-Dokumentation | 

**Anmerkung**  
`RayCronJob`benötigt KubeRay 1.6.0 oder höher. Bei einem früheren Operator existiert der Ressourcentyp nicht. Weitere Informationen finden Sie unter [Installation KubeRay auf HyperPod Amazon EKS](sagemaker-hyperpod-ray-install-kuberay.md).

## Einen Cluster erstellen
<a name="sagemaker-hyperpod-ray-manage-kubectl-create"></a>

Das folgende Manifest erstellt einen Head-Pod und eine GPU-Worker-Gruppe auf HyperPod Knoten.

```
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}}
```

**Wichtig**  
Setzen Sie `dashboard-host` diese `0.0.0.0` Option in der Head-Gruppe auf. Der Ray Endpoint Operator benötigt es, um das Dashboard außerhalb des Head-Pods zu bedienen, und der authentifizierte Dashboard-Zugriff schlägt ohne ihn fehl.

Der Cluster ist bereit, wenn der Head-Pod und mindestens ein Worker-Pod ausgeführt werden. `RayJob``RayCronJob`, und `RayService` folgen dem gleichen Muster zum Anwenden und Prüfen, und in jedem wird ein Objekt `rayClusterSpec` mit derselben Form wie oben eingebettet. `spec`

Für jedes Feld, das diese Ressourcen akzeptieren, siehe [ RayCluster Konfiguration ](https://docs.ray.io/en/latest/cluster/kubernetes/user-guides/config.html) in der Ray-Dokumentation.

## Senden von Aufträgen an einen laufenden Cluster
<a name="sagemaker-hyperpod-ray-manage-kubectl-submit"></a>

Wenn Sie einen anwenden, `RayJob` wird ein Cluster für diesen Job erstellt. Verwenden Sie das `toolkit-for-ray-on-sagemaker-ai` Paket, um an einen Cluster zu senden, der bereits ausgeführt wird. Weitere Informationen finden Sie unter [Senden von Aufträgen aus der Ferne mit der Toolkit-Bibliothek](sagemaker-hyperpod-ray-remote-job-submission.md).