Ray on Kubernetes 实战指南：用 KubeRay Operator 部署与管理分布式 Ray 集群

Ray on Kubernetes 实战指南用 KubeRay Operator 部署与管理分布式 Ray 集群【免费下载链接】rayRay is an AI compute engine. Ray consists of a core distributed runtime and a set of AI Libraries for accelerating ML workloads.项目地址: https://gitcode.com/gh_mirrors/ra/ray导读本文基于 Ray 官方文档中Ray on Kubernetes章节doc/source/cluster/kubernetes/index.md系统讲解如何在 Kubernetes 集群上运行分布式 Ray 程序以KubeRay Operator为核心通过RayCluster、RayJob、RayService以及新增的RayCronJob四类 Kubernetes 自定义资源CRD实现集群的声明式创建、作业提交、服务发布与自动伸缩。读完本文你将掌握从零搭建 Kind 本地集群、安装 KubeRay Operator、运行首个 Ray 应用到使用 RayJob 完成批处理、使用 RayService 上线 Ray Serve 应用、使用 RayCronJob 做定时调度的完整实战链路并了解如何进一步深入该章节下的用户指南与故障排查文档。KubeRay在 Kubernetes 上运行 Ray 的推荐方式KubeRay 是 Ray 项目官方推荐的 Kubernetes 集成方案。它采用Kubernetes 原生Kubernetes-native的方式管理 Ray 集群KubeRay 把每一个 Ray 节点Node建模为一个 Kubernetes Pod因此一个 Ray 集群由 1 个Head Pod和一组Worker Pod组成集群的创建、扩缩容、故障恢复全部交由 Kubernetes 调度器与 KubeRay 控制器协作完成。从 doc/source/cluster/kubernetes/index.md 的架构说明可以归纳出 KubeRay 的核心能力可选自动伸缩AutoscalingKubeRay 可以根据 Ray 工作负载的实际资源需求动态增加或移除 Worker Pod把集群规模始终对齐任务要求避免资源浪费。异构计算节点支持包括 GPU、TPU 等异构资源同一集群内可以混合调度不同类型与规格的节点。多版本共存可以在同一个 Kubernetes 集群中同时运行多个不同 Ray 版本的 Ray 集群互不干扰。声明式管理用户只需要通过kubectl apply提交自定义资源KubeRay Operator 即负责将期望状态desired state落实为实际的 Pod、Service 等对象。下图展示了 KubeRay 的整体工作方式图片来源doc/source/cluster/kubernetes/images/ray_on_kubernetes.png四大 CRDRayCluster、RayJob、RayService 与 RayCronJobKubeRay 通过以下自定义资源定义CRD把集群与作业/服务两类关注点分开针对不同使用场景提供不同的管理粒度CRD管理对象典型场景RayCluster一组 Ray 节点1 个 head Pod 多个 worker Pod长期存活的交互式集群手动/自动扩缩容RayJobRayCluster Ray 作业通过 submitter 提交一次性批处理、训练任务作业结束可自动回收集群RayServiceRayCluster Ray Serve 应用在线推理/服务支持零停机升级与高可用RayCronJob按 cron 调度创建 RayJobKubeRay v1.6.0alpha定时重训练、夜间批量推理、周期数据处理其中RayCronJob是对原生 KubernetesCronJob的启发式扩展它本身不直接执行负载而是作为控制器按计划周期性地创建RayJob自定义资源。环境准备与 KubeRay Operator 安装在动手之前需要准备以下工具详见 RayCluster 快速开始 的 Preparation 部分kubectl 1.23helm v3.4若走 Helm 安装方式kind与docker用于创建本地集群本机或集群至少有4 CPU 与 4 GB RAM的可用资源第一步创建 Kubernetes 集群官方快速开始使用 Kind 创建本地集群。如果你已有 Kubernetes 集群可以跳过此步kind create cluster --imagekindest/node:v1.26.0第二步安装 KubeRay OperatorKubeRay Operator 是控制面的核心组件它监听上述 CRD 的变化并驱动集群达到期望状态。官方提供两种安装方式完整步骤见 KubeRay Operator 安装指南。方式一Helm官方推荐建议把 Operator 安装到独立的ray-system命名空间而非default这样可以将 Operator 的服务账号与工作负载 Pod 隔离helm repo add kuberay https://ray-project.github.io/kuberay-helm/ helm repo update kubectl create namespace ray-system helm install kuberay-operator kuberay/kuberay-operator --version 1.7.0 -n ray-system方式二Kustomize# 安装 CRD 与 KubeRay Operator 到 ray-system 命名空间 kubectl create namespace ray-system kubectl create -k github.com/ray-project/kuberay/ray-operator/config/default?refv1.7.0 -n ray-system第三步验证安装确认 Operator 已正常运行。若安装在ray-system需要加-n ray-systemkubectl get pods -n ray-systemNAME READY STATUS RESTARTS AGE kuberay-operator-6bc45dd644-gwtqv 1/1 Running 0 24sRayCluster 实战部署交互式 Ray 集群RayCluster是另外三类 CRD 的底座——RayJob、RayService 最终都是通过管理一个 RayCluster 来工作的。以下是完整流程对应 RayCluster 快速开始。部署一个 RayCluster 自定义资源Operator 就绪后在default命名空间创建 RayCluster CR。官方样例可以直接从 KubeRay Helm chart 仓库安装# 从 KubeRay Helm chart 仓库部署一个样例 RayCluster CR helm install raycluster kuberay/ray-cluster --version 1.7.0查看 RayCluster 状态kubectl get rayclustersNAME DESIRED WORKERS AVAILABLE WORKERS CPUS MEMORY GPUS STATUS AGE raycluster-kuberay 1 1 2 3G 0 ready 55sKubeRay Operator 检测到 RayCluster 对象后会自动创建 head Pod 与 worker Pod。用标签选择器查看集群 Podkubectl get pods --selectorray.io/clusterraycluster-kuberayNAME READY STATUS RESTARTS AGE raycluster-kuberay-head 1/1 Running 0 XXs raycluster-kuberay-worker-workergroup-xvfkr 1/1 Running 0 XXs等待 Pod 进入Running可能需要几分钟大部分时间消耗在拉取 Ray 镜像上。若 Pod 一直停留在Pending可执行kubectl describe pod raycluster-kuberay-xxxx-xxxxx排查错误并确认 Docker 资源配额满足要求。在 RayCluster 上运行应用的两种方式方式一在 head Pod 内直接执行这是最直接的实验方式。先定位 head Podexport HEAD_POD$(kubectl get pods --selectorray.io/node-typehead -o custom-columnsPOD:metadata.name --no-headers) echo $HEAD_PODraycluster-kuberay-head然后在 head Pod 内初始化 Ray 并打印集群资源kubectl exec -it $HEAD_POD -- python -c import ray; ray.init(); print(ray.cluster_resources())2023-04-07 10:57:46,472 INFO worker.py:1243 -- Using address 127.0.0.1:6379 set in the environment variable RAY_ADDRESS 2023-04-07 10:57:46,472 INFO worker.py:1364 -- Connecting to existing Ray cluster at address: 10.244.0.6:6379... 2023-04-07 10:57:46,482 INFO worker.py:1550 -- Connected to Ray cluster. View the dashboard at http://10.244.0.6:8265 {CPU: 2.0, memory: 3000000000.0, node:10.244.0.6: 1.0, node:10.244.0.7: 1.0, node:__internal_head__: 1.0, object_store_memory: 749467238.0}方式二通过 Ray Job Submission SDK 提交作业这种方式不需要进入 head Pod。KubeRay Operator 会为 head Pod 配置一个 Kubernetes Service其中 8265 端口即 Ray DashboardJob 提交入口端口。先查看该 Servicekubectl get service raycluster-kuberay-head-svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE raycluster-kuberay-head-svc ClusterIP None none 10001/TCP,8265/TCP,6379/TCP,8080/TCP,8000/TCP 57s使用端口转发把 8265 端口暴露到本地在单独的 shell 中执行kubectl port-forward service/raycluster-kuberay-head-svc 8265:8265 /dev/null 然后通过ray job submit提交作业输出的日志会显示集群总资源容量含 2 个 CPUray job submit --address http://localhost:8265 -- python -c import ray; ray.init(); print(ray.cluster_resources())Job submission server address: http://localhost:8265 ------------------------------------------------------- Job raysubmit_8vJ7dKqYrWKbd17i submitted successfully ------------------------------------------------------- ... {CPU: 2.0, memory: 3000000000.0, node:10.244.0.6: 1.0, node:10.244.0.7: 1.0, node:__internal_head__: 1.0, object_store_memory: 749467238.0} ------------------------------------------ Job raysubmit_8vJ7dKqYrWKbd17i succeeded ------------------------------------------访问 Ray Dashboard 与清理浏览器访问${YOUR_IP}:8265例如127.0.0.1:8265即可打开 Ray Dashboard在Recent jobs面板中可以看到刚才提交的作业实验结束后清理资源# 终止之前的 kubectl port-forward 后台进程 killall kubectl kind delete clusterRayJob 实战作业完成即回收集群的批处理模式RayJob面向跑完即走的批处理场景它同时管理两件事详见 RayJob 快速开始RayCluster由rayClusterSpec定义负责管理集群内所有 PodJob一个 Kubernetes Job 执行ray job submit把 Ray 作业提交到该 RayCluster。需要区分的三个概念RayJobKubeRay 提供的 Kubernetes 自定义资源Ray job一个打包好的 Ray 应用可以运行在远程 Ray 集群上Submitter运行ray job submit的 Kubernetes Job负责把 Ray job 提交进 RayCluster。RayJob 配置参数详解以下是RayJobspec 中按功能分组的核心字段以当前文档所对应的 KubeRay v1.7.0 语义为准RayCluster 配置字段说明rayClusterSpec定义承载该 Ray 作业的 RayCluster 自定义资源clusterSelector复用已存在的 RayCluster 而非新建此时不指定rayClusterSpecRay job 配置字段说明entrypointsubmitter 执行ray job submit --address ... --submission-id ... -- $entrypoint提交的作业命令runtimeEnvYAML可选KubeRay v1.0.0 新增以多行 YAML 字符串描述作业依赖的运行时环境pip 包、环境变量等jobId可选作业的 submission ID未指定时由 KubeRay 自动生成metadata可选传给ray job submit --metadata-json的元数据entrypointNumCpus/entrypointNumGpus/entrypointResources可选entrypoint 运行时申请的资源backoffLimit可选v1.2.0 新增标记 RayJob 失败前的重试次数每次重试都会新建 RayCluster默认值为 0runtimeEnvYAML的示例结构spec: runtimeEnvYAML: | pip: - requests2.26.0 - pendulum2.1.2 env_vars: KEY: VALUE提交方式submissionMode可选默认K8sJobMode取值行为K8sJobModeOperator 创建一个 submitter Kubernetes Job 来提交 Ray 作业HTTPModeOperator 直接向 RayCluster 发送 HTTP 请求创建 Ray 作业InteractiveModeOperator 等待用户手动向集群提交作业alphaKubeRay kubectl 插件依赖此模式SidecarModeOperator 在 head Pod 中注入一个 sidecar 容器提交作业不支持clusterSelector与submitterPodTemplate并要求 head Pod 的 restart policy 为Never配套字段还有submitterPodTemplate仅K8sJobMode生效Operator 会注入RAY_DASHBOARD_ADDRESS与RAY_JOB_SUBMISSION_ID两个环境变量以及submitterConfig.backoffLimitsubmitter 失败前的重试次数默认 2。此外SidecarSubmitterRestart特性门控v1.7 为 alpha、默认关闭允许 submitter 容器在瞬时失败时原地重启需要 Kubernetes v1.35 与 Ray v2.54.0。自动资源回收字段说明preRunningDeadlineSeconds可选RayJob 未在限定秒数内进入Running时JobDeploymentStatus置为Failed原因PreRunningDeadlineExceeded默认 0不限制shutdownAfterJobFinishes可选作业结束后是否回收 RayCluster默认 falsettlSecondsAfterFinished可选仅在shutdownAfterJobFinishes为 true 时生效作业结束后延迟多少秒删除 RayCluster 与 submitter默认 0activeDeadlineSeconds可选RayJob 未在限定秒数内进入Complete/Failed时置为Failed原因DeadlineExceededDELETE_RAYJOB_CR_AFTER_JOB_FINISHES可选v1.2.0 新增在 KubeRay Operator 上设置的环境变量为 true 且shutdownAfterJobFinishes为 true 时连同 RayJob CR 本身一起删除其他suspend可选为 true 时 KubeRay 删除 RayCluster 与 submitter。注意 Kueue 也通过修改此字段实现调度策略若使用 Kueue 调度 RayJob 请勿手动修改deletionStrategyv1.5.1 alpha / v1.6.0 beta需启用RayJobDeletionPolicy特性门控作业进入终态后的自动清理策略支持规则式推荐与旧式两种互斥写法。规则式通过deletionRules定义每条规则包含policyDeleteCluster/DeleteWorkers/DeleteSelf/DeleteNone与condition基于jobStatus与可选ttlSeconds触发可实现多阶段清理规则式与shutdownAfterJobFinishes、全局ttlSecondsAfterFinished不兼容。旧式onSuccess/onFailure已废弃建议迁移。完整示例部署一个 RayJob前置条件是 Kind 集群与 KubeRay Operator 已就绪操作同上一节随后应用官方样例kubectl apply -f https://raw.githubusercontent.com/ray-project/kuberay/v1.7.0/ray-operator/config/samples/ray-job.sample.yaml验证状态# 列出 default 命名空间下所有 RayJob 自定义资源 kubectl get rayjob # NAME JOB STATUS DEPLOYMENT STATUS RAY CLUSTER NAME START TIME END TIME AGE # rayjob-sample SUCCEEDED Complete rayjob-sample-qnftt 2025-06-25T16:21:21Z 2025-06-25T16:22:35Z 6m53s # 列出 RayCluster 自定义资源 kubectl get raycluster # NAME DESIRED WORKERS AVAILABLE WORKERS CPUS MEMORY GPUS STATUS AGE # rayjob-sample-qnftt 1 1 400m 0 0 ready 7m48s # 查看 jobStatus 与 jobDeploymentStatus kubectl get rayjobs.ray.io rayjob-sample -o jsonpath{.status.jobStatus} # SUCCEEDED kubectl get rayjobs.ray.io rayjob-sample -o jsonpath{.status.jobDeploymentStatus} # Complete该样例中entrypoint为python /home/ray/samples/sample_code.py脚本存放在挂载到 head Pod 的 ConfigMap 中由于shutdownAfterJobFinishes默认为 false作业结束后 RayCluster 与 submitter 都不会被删除。查看作业输出sample_code.py是一个把计数器递增函数执行 5 次的简单 Ray 脚本kubectl logs -ljob-namerayjob-sample # 2025-06-25 09:22:27,977 INFO worker.py:1832 -- Connected to Ray cluster. View the dashboard at 10.244.0.6:8265 # test_counter got 1 # test_counter got 2 # ... # Job rayjob-sample-zdxm6 succeeded接着用ray-job.shutdown.yaml验证自动回收该样例设置shutdownAfterJobFinishes: true与ttlSecondsAfterFinished: 10因此 Operator 会在作业结束后 10 秒删除 RayClustersubmitter 不会被删除它保存着作业日志且完成后不占用集群资源RayJob 被删除时会通过 owner reference 级联清理 submitter。kubectl apply -f https://raw.githubusercontent.com/ray-project/kuberay/v1.7.0/ray-operator/config/samples/ray-job.shutdown.yaml kubectl get raycluster # 关联的 RayCluster 应已被删除清理kubectl delete -f https://raw.githubusercontent.com/ray-project/kuberay/v1.7.0/ray-operator/config/samples/ray-job.shutdown.yaml helm uninstall kuberay-operator kind delete clusterRayService 实战零停机部署 Ray Serve 应用RayService把 RayCluster 与 Ray Serve 应用的管理合并到一个 CR 中详见 RayService 快速开始主要提供四类能力Kubernetes 原生支持用一份 Kubernetes 配置同时定义 Ray 集群与 Ray Serve 应用kubectl一键创建Ray Serve 应用就地更新in-place updatingRay 集群零停机升级新老集群平滑切换升级过程不中断服务高可用服务故障时自动恢复。部署与验证本示例以 KubeRay v1.7.0 与 Ray 2.46.0 的行为为准部署两个简单的 Ray Serve 应用。Kind 集群与 Operator 就绪后kubectl apply -f https://raw.githubusercontent.com/ray-project/kuberay/v1.7.0/ray-operator/config/samples/ray-service.sample.yaml该样例使用serveConfigV2指定多应用 Serve 配置KubeRay v0.6.0 起支持。验证状态kubectl get rayservice # NAME SERVICE STATUS NUM SERVE ENDPOINTS # rayservice-sample Running 2 kubectl get pods -lray.io/is-ray-nodeyes # NAME READY STATUS RESTARTS AGE # rayservice-sample-cxm7t-head 1/1 Running 0 3m5s # rayservice-sample-cxm7t-small-group-worker-8hrgg 1/1 Running 0 3m5s # Ready 条件为 True 时表示 RayService 可以开始服务请求 kubectl describe rayservices.ray.io rayservice-sample # Conditions: # Message: Number of serve endpoints is greater than 0 # Reason: NonZeroServeEndpoints # Status: True # Type: Ready当 Serve 应用健康就绪后KubeRay 会为 RayService 创建两个 Service见 RayService 文档 的详细说明kubectl get services # NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) ... # rayservice-sample-cxm7t-head-svc ClusterIP None none 10001/TCP,8265/TCP,6379/TCP,8080/TCP,8000/TCP # rayservice-sample-head-svc ClusterIP None none 10001/TCP,8265/TCP,6379/TCP,8080/TCP,8000/TCP # rayservice-sample-serve-svc ClusterIP 10.96.125.107 none 8000/TCP这两个 Service 的分工是rayservice-sample-head-svc指向活跃 RayCluster 的 head Pod通常用于访问 Ray Dashboard端口 8265rayservice-sample-serve-svc暴露 Ray Serve 的 HTTP 接口默认端口 8000REST API、ML 推理等 HTTP 请求都走这个地址。查看 Serve 应用状态并发送请求端口转发后可在http://localhost:8265/#/serve查看 Serve 页面更完整的可观测性说明见 RayService 故障排查kubectl port-forward svc/rayservice-sample-head-svc 8265:8265启动一个临时的 curl Pod通过 Serve Service 调用应用kubectl run curl --imagecurlimages/curl:latest -i --tty -- sh # 请求 fruit stand 应用 curl -X POST -H Content-Type: application/json rayservice-sample-serve-svc:8000/fruit/ -d [MANGO, 2] # [Expected output]: 6 # 请求 calculator 应用 curl -X POST -H Content-Type: application/json rayservice-sample-serve-svc:8000/calc/ -d [MUL, 3] # [Expected output]: 15 pizzas please!清理kubectl delete -f https://raw.githubusercontent.com/ray-project/kuberay/v1.7.0/ray-operator/config/samples/ray-service.sample.yaml helm uninstall kuberay-operator kubectl delete pod curlRayCronJob 实战定时调度 Ray 作业RayCronJob允许你按 cron 时间表周期性运行 RayJob 负载适合定时模型重训练、夜间批量推理、周期性数据处理等任务详见 RayCronJob 快速开始。该特性需要 KubeRay v1.6.0 以上且处于 alpha 阶段。核心配置字段字段说明schedulecron 调度字符串如* * * * *表示每分钟触发一次jobTemplate包裹一个标准 RayJob spec支持的字段与 RayJob 完全一致suspend可选为 true 时暂停未来作业的调度不影响已创建且正在运行的 RayJobtimeZone可选IANA 时区格式如America/Los_Angeles省略时使用 Operator 本地时区且不要在schedule里写TZ/CRON_TZ配置结构示例apiVersion: ray.io/v1 kind: RayCronJob metadata: name: example-raycronjob spec: schedule: */5 * * * * # 每 5 分钟运行一次 timeZone: America/Los_Angeles # 可选默认使用 Operator 本地时区 jobTemplate: # 以下全部是标准 RayJob spec entrypoint: python /home/ray/samples/sample_code.py # ... (RayCluster spec, runtimeEnv, etc.)启用特性门控并安装 Operatorv1.7.0 示例helm repo add kuberay https://ray-project.github.io/kuberay-helm/ helm repo update helm install kuberay-operator kuberay/kuberay-operator \ --version 1.7.0 \ --set featureGates[0].nameRayCronJob \ --set featureGates[0].enabledtrue部署与监控kubectl apply -f https://raw.githubusercontent.com/ray-project/kuberay/v1.7.0/ray-operator/config/samples/ray-cronjob.sample.yaml kubectl get raycronjob raycronjob-sample # NAME SCHEDULE LAST SCHEDULE AGE SUSPEND # raycronjob-sample * * * * * 10s # 观察每个周期自动创建的 RayJob kubectl get rayjob -w # NAME JOB STATUS DEPLOYMENT STATUS RAY CLUSTER NAME START TIME END TIME AGE # raycronjob-sample-l76h8 Initializing raycronjob-sample-l76h8-hjtrs 2026-04-03T05:57:00Z 2s # raycronjob-sample-l76h8 RUNNING Running raycronjob-sample-l76h8-hjtrs 2026-04-03T05:57:00Z 48s # raycronjob-sample-l76h8 SUCCEEDED Complete raycronjob-sample-l76h8-hjtrs 2026-04-03T05:57:00Z 2026-04-03T05:58:02Z 62s查看某个周期任务的输出时用 RayJob 名称过滤 submitter Pod 日志即可kubectl logs -ljob-namerayjob-name。进阶KubeRay Dashboard实验性组件从 KubeRay v1.4.0 起可以使用开源的 KubeRay Dashboard UI实验性不建议用于生产。它不同于 Ray Dashboard后者是 Ray 集群自身的组件提供的是集群中所有 KubeRay 资源的集中视图安装步骤见 KubeRay Dashboard 指南# 安装依赖的 kuberay-apiserver本示例禁用安全代理并放开 CORS 来源 helm install kuberay-apiserver kuberay/kuberay-apiserver --version v1.7.0 --set security --set cors.allowOrigin* # Dashboard 目前请求 http://localhost:31888需要端口转发 apiserver kubectl port-forward svc/kuberay-apiserver-service 31888:8888 # 启动 Dashboard kubectl run kuberay-dashboard --imagequay.io/kuberay/dashboard:v1.7.0 kubectl port-forward kuberay-dashboard 3000:3000访问http://localhost:3000/ray/jobs即可看到 RayJob 列表。KubeRay Dashboard 只展示由 KubeRay API server 创建的 RayJob可以通过给自定义资源打标签来模拟kubectl apply -f https://raw.githubusercontent.com/ray-project/kuberay/v1.7.0/ray-operator/config/samples/ray-job.sample.yaml kubectl label rayjob rayjob-sample app.kubernetes.io/managed-bykuberay-apiserver学习路线图从快速开始到生产级实践Ray on Kubernetes章节doc/source/cluster/kubernetes/index.md除了上述四个快速开始外还按主题组织了系统化的文档地图Getting Started入门KubeRay Operator 安装RayCluster 快速开始RayJob 快速开始RayService 快速开始RayCronJob 快速开始User Guides用户指南索引见 user-guides.md覆盖生产化所需的全部主题集群配置与调度config.md、scheduling.md、label-based-scheduling.md、pod-command.md、k8s-cluster-setup.md、uv.md自动伸缩configuring-autoscaling.md、configuring-ippr.md、k8s-autoscaler.mdGPU / TPUgpu.rst、tpu.md以及各云厂商的实操指南 aws-eks-gpu-cluster.md、gcp-gke-gpu-cluster.md、gcp-gke-tpu-cluster.md、azure-aks-gpu-cluster.md、ack-gpu-cluster.mdRayService 深入rayservice.md、rayservice-high-availability.md、rayservice-incremental-upgrade.md、rayservice-no-ray-serve-replica.md、kuberay-serve-high-throughput.md容错与存储kuberay-gcs-ft.md、kuberay-gcs-persistent-ft.md、kuberay-gcs-rocksdb-ft.md、storage.md、gke-gcs-bucket.md可观测性observability.md、kuberay-history-server.md、k8s-events.md、persist-kuberay-custom-resource-logs.md、persist-kuberay-operator-logs.md安全与网络kuberay-auth.md、kuberay-auth-rbac.md、helm-chart-rbac.md、tls.md、kuberay-mtls.md、network-policy.md运维工具与优化kubectl-plugin.md、kuberay-dashboard.md、upgrade-guide.md、reduce-image-pull-latency.md、resource-isolation-with-writable-cgroups.md、rayjob-sidecar-submitter-restart.md。更多资源Examplesexamples.md 提供可动手尝试的示例负载Ecosystemk8s-ecosystem.md 介绍 KubeRay 与第三方 Kubernetes 生态工具的集成如 Kueue、Istio、Kubeflow 等Benchmarksbenchmarks.md 提供 KubeRay 基准测试结果Troubleshootingtroubleshooting.md 汇总常见问题排查指南Referencesreferences.md 提供 CRD API 参考等资料。在 Ray 仓库中验证与进一步探索Ray 仓库本身也对 Kubernetes 支持进行了系统性验证与压测可以作为深入学习的补充证据CI 基础设施ci/k8s/目录提供了 Kubernetes 测试环境准备与执行脚本包括 install-k8s-tools.sh安装 k8s 工具链、prep-k8s-environment.sh准备测试环境、run-operator-tests.sh运行 KubeRay Operator 测试与 run-chaos-test.sh混沌测试直观展示了 Ray 项目如何在 CI 中演练 Kubernetes 场景发布级测试release/k8s_tests/下包含面向 Kubernetes 的发布测试用例例如 run_ray_gcs_ft_on_k8s.pyGCS 故障转移测试、ray_rayservice_template.yamlRayService 模板、prepare.sh 与 locustfile.py压测脚本可用于参考生产级 RayService 配置的写法KubeRay 本身KubeRay 的 Operator 控制器、CRD 定义与 Helm chart 在独立的 KubeRay 仓库ray-project 组织下中开发维护。官方文档建议通过该仓库跟踪进展、报告 bug、提出新特性或参与贡献。关于 KubeRay起源与定位Ray 的 Kubernetes 支持由 KubeRay 项目承载它隶属于更广泛的 Ray 项目生态已被多家公司用于生产环境中的 Ray 部署见 index.md 的 About KubeRay 一节。对于希望跳过自建集群、直接在 EKS、GKE、AKS 或自托管 Kubernetes 上运行 Ray 的用户也可关注由 Ray 团队开发的托管 Ray 平台 Anyscale不过官方文档中 KubeRay 始终是推荐的 Kubernetes 原生方案。小结至此你已经完整走通了 KubeRay 的四大核心工作流用RayCluster管理交互式集群、用RayJob处理跑完即走的批处理作业、用RayService零停机发布 Ray Serve 在线服务、用RayCronJob定时调度作业并掌握了 Operator 安装、状态验证、Dashboard 访问与资源清理的完整闭环。下一步建议从 user-guides.md 中挑选与你实际场景最贴近的主题自动伸缩、GPU/TPU、GCS 容错、安全加固等继续深入并结合 examples.md 中的示例负载动手实践。【免费下载链接】rayRay is an AI compute engine. Ray consists of a core distributed runtime and a set of AI Libraries for accelerating ML workloads.项目地址: https://gitcode.com/gh_mirrors/ra/ray创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考