KubeRay 与 Apache YuniKorn 集成指南Kubernetes 多租户环境下的 Ray 集群细粒度调度与 Gang Scheduling【免费下载链接】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 的 Kubernetes 生态KubeRay中接入 Apache YuniKorn——一个轻量、通用、面向云原生环境的容器编排资源调度器为 Ray head/worker Pod 提供多租户环境下的细粒度资源共享与**全有或全无All-or-Nothing的 gang scheduling成组调度**能力。读完本文你将掌握 YuniKorn 的安装、KubeRay operator 的启用方式、队列queue配置、必要的标签设置以及如何通过 YuniKorn 仪表盘观察 Ray 应用从 Accepted 到 Running 的完整调度过程并理解为什么宁可排队等待全部资源、也不部分调度的语义能避免分布式训练集群出现资源碎片化。为什么需要 YuniKorn多租户与成组调度Apache YuniKorn 是一个轻量级、通用的容器编排系统资源调度器。它面向大规模、多租户、云原生环境能够为混合负载包括无状态的批处理负载与有状态的服务提供统一、跨平台的调度体验对各类工作负载进行细粒度的资源共享。在 Ray 的场景中一个 RayCluster 通常由一个 head Pod 和若干 worker Pod 组成。默认的 Kubernetes 调度器逐 Pod 独立调度这会导致一个问题当集群剩余资源只够放下 head 或部分 worker 时Pod 会被部分调度整个 RayCluster 处于不完整状态分布式训练任务如依赖全部节点到齐的 Horovod 等只能空等资源。YuniKorn 通过 gang scheduling 语义解决了这一问题要么整个 RayCluster 的 Pod 全部获得资源要么一个都不调度直到队列中有足够容纳全部 Pod 的资源为止。KubeRay 对 Apache YuniKorn 的集成正是为了让 Ray 的 head/worker Pod 在多租户 Kubernetes 环境中获得这种更高效、更可预期的调度行为。注意该特性要求 KubeRay 版本为 1.2.2 或更新目前处于 alpha 测试阶段。Step 1使用 Kind 创建 Kubernetes 集群在终端中执行以下命令创建一个本地 Kubernetes 集群用于实验kind create clusterStep 2安装 Apache YuniKorn在启用 KubeRay 与 YuniKorn 的集成之前需要先在 Kubernetes 集群上成功安装 Apache YuniKorn。安装完成后YuniKorn 会通过 Helm 在yunikorn命名空间下创建若干组件其中包括后续配置队列时需要用到的 ConfigMapyunikorn-defaults。请参考 Apache YuniKorn 官方文档中的 Get Started 部分完成安装。Step 3安装带 Apache YuniKorn 支持的 KubeRay operator使用 Helm 安装 KubeRay operator 时通过命令行参数指定批量调度器batch scheduler为 YuniKornhelm install kuberay-operator kuberay/kuberay-operator --version 1.7.0 --set batchScheduler.nameyunikorn--set batchScheduler.nameyunikorn这一参数让 KubeRay operator 在创建 RayCluster 的 Pod 时自动为它们打上与 YuniKorn 协作所需的标签与注解详见 Step 4从而将调度权交给 YuniKorn。从 KubeRay 的配置惯例看可对比同一文档目录下的 volcano.md批量调度器是在operator 级别统一配置的v1.3.0 之后无需再在 RayCluster 上单独添加ray.io/scheduler-name标签调度器选择完全由 operator 启动参数或 Helm values 控制。如果你更习惯声明式配置也可以在 Helm values 中设置batchScheduler.name: yunikorn效果等价。Step 4使用 Apache YuniKorn 实现 Gang Scheduling以下示例演示 KubeRay 如何配合 YuniKorn 对 RayCluster 自定义资源进行 gang scheduling。自 KubeRay 1.6.0 起KubeRay 同样支持对 RayJob 自定义资源进行 gang scheduling。4.1 创建容量为 4 CPU / 6Gi 内存的队列执行以下命令编辑 YuniKorn 的配置 ConfigMapkubectl edit configmap -n yunikorn yunikorn-defaults该 ConfigMap 由 Apache YuniKorn Helm chart 在安装时自动创建。在data键下新增一个queues.yaml配置项编辑后的 ConfigMap 应如下所示apiVersion: v1 kind: ConfigMap metadata: # ConfigMap 的元数据此处省略 data: queues.yaml: | partitions: - name: default queues: - name: root queues: - name: test submitacl: * parent: false resources: guaranteed: memory: 6G vcore: 4 max: memory: 6G vcore: 4保存并退出编辑器。该配置创建了一个名为root.test的队列容量为 4 CPU 与 6Gi 内存。配置要点说明submitacl: *允许所有用户向该队列提交应用便于测试环境快速验证parent: false该队列不是父队列可以直接承载应用resources.guaranteedYuniKorn 为队列预留的保证资源量此处为 6G 内存 4 vcore只要集群资源允许队列总能获得这部分资源resources.max队列可使用的资源上限硬约束本例与 guaranteed 一致表示该队列独占这 4 CPU / 6Gi 资源。4.2 创建第一个 RayCluster接下来创建一个 RayClusterhead 节点 1 CPU 2GiB 内存两个 worker 各 1 CPU 1GiB 内存合计 3 CPU 与 4GiB 内存# 路径kuberay/ray-operator/config/samples # 在 RayCluster 自定义资源上配置供 Apache YuniKorn 调度器进行 gang scheduling 的标签 # - ray.io/gang-scheduling-enabled设为 true 以启用 gang scheduling。 # - yunikorn.apache.org/app-id设置为该应用在 Kubernetes 中的唯一标识跨命名空间唯一。 # - yunikorn.apache.org/queue设置为 Apache YuniKorn 中某个队列的名称。 wget https://raw.githubusercontent.com/ray-project/kuberay/master/ray-operator/config/samples/ray-cluster.yunikorn-scheduler.yaml kubectl apply -f ray-cluster.yunikorn-scheduler.yaml查看 KubeRay operator 创建的 RayCluster$ kubectl describe raycluster test-yunikorn-0 Name: test-yunikorn-0 Namespace: default Labels: ray.io/gang-scheduling-enabledtrue yunikorn.apache.org/app-idtest-yunikorn-0 yunikorn.apache.org/queueroot.test Annotations: none API Version: ray.io/v1 Kind: RayCluster Metadata: Creation Timestamp: 2024-09-29T09:52:30Z Generation: 1 Resource Version: 951 UID: cae1dbc9-5a67-4b43-b0d9-be595f21ab85 # 其余字段省略注意 RayCluster 上的三个标签这是 KubeRay 与 YuniKorn 协作的关键契约标签取值示例作用ray.io/gang-scheduling-enabledtrue是否启用 gang schedulingyunikorn.apache.org/app-idtest-yunikorn-0应用的全局唯一标识用于将同一 Ray 集群的多个 Pod 归组yunikorn.apache.org/queueroot.test应用提交到的 YuniKorn 队列注意只有当你需要 gang scheduling 时才需要设置ray.io/gang-scheduling-enabled标签。如果未设置该标签YuniKorn 仍会正常调度该 Ray 集群只是不强制执行 gang scheduling即退化为普通逐 Pod 调度。由于队列容量为 4 CPU 与 6GiB 内存而该集群只需要 3 CPU 与 4GiB 内存资源应能顺利调度成功$ kubectl get pods NAME READY STATUS RESTARTS AGE test-yunikorn-0-head-98fmp 1/1 Running 0 67s test-yunikorn-0-worker-worker-42tgg 1/1 Running 0 67s test-yunikorn-0-worker-worker-467mn 1/1 Running 0 67s4.3 通过 YuniKorn 仪表盘验证调度结果通过端口转发访问 Apache YuniKorn 仪表盘kubectl port-forward svc/yunikorn-service 9889:9889 -n yunikorn然后在浏览器中访问http://localhost:9889/#/applications查看正在运行的应用4.4 添加第二个 RayCluster观察 Gang Scheduling 排队接下来添加另一个 RayClusterhead 与 worker 配置完全一致仅更换名称# 将名称替换为 test-yunikorn-1 sed s/test-yunikorn-0/test-yunikorn-1/ ray-cluster.yunikorn-scheduler.yaml | kubectl apply -f-现在test-yunikorn-1的所有 Pod 都处于Pending状态$ kubectl get pods NAME READY STATUS RESTARTS AGE test-yunikorn-0-head-98fmp 1/1 Running 0 4m22s test-yunikorn-0-worker-worker-42tgg 1/1 Running 0 4m22s test-yunikorn-0-worker-worker-467mn 1/1 Running 0 4m22s test-yunikorn-1-head-xl2r5 0/1 Pending 0 71s test-yunikorn-1-worker-worker-l6ttz 0/1 Pending 0 71s test-yunikorn-1-worker-worker-vjsts 0/1 Pending 0 71s tg-test-yunikorn-1-headgroup-vgzvoot0dh 0/1 Pending 0 69s tg-test-yunikorn-1-worker-eyti2bn2jv 1/1 Running 0 69s tg-test-yunikorn-1-worker-k8it0x6s73 0/1 Pending 0 69s观察点Apache YuniKorn 会为 gang scheduling 创建带tg-前缀的 Pod。这些tg-前缀 Pod 是 YuniKorn 用于跟踪应用成组状态的内部标记出现它们即表示 YuniKorn 正在对该 Ray 集群执行成组调度逻辑。回到http://localhost:9889/#/applications可以看到test-yunikorn-1处于Accepted状态但尚未运行为什么第二个集群的 Pod 不调度新集群总共需要 3 CPU 与 4GiB 内存而队列剩余容量只有 1 CPU 与 2GiB 内存。虽然理论上可以放下其中的一个 Pod但 YuniKorn 在队列有足够空间容纳全部Pod 之前不会放置该集群的任何 Pod。这正是 gang scheduling 的价值所在如果不使用 YuniKorn 的 gang schedulingKubeRay 会先放置其中一个 Pod导致集群被部分分配而部分分配的 Ray 集群无法真正对外提供服务反而白白占用资源。4.5 释放资源观察第二个集群恢复调度删除第一个 RayCluster释放队列资源kubectl delete raycluster test-yunikorn-0现在有足够的资源调度整个 Pod 集合第二个集群的所有 Pod 全部转为Running状态$ kubectl get pods NAME READY STATUS RESTARTS AGE test-yunikorn-1-head-xl2r5 1/1 Running 0 3m34s test-yunikorn-1-worker-worker-l6ttz 1/1 Running 0 3m34s test-yunikorn-1-worker-worker-vjsts 1/1 Running 0 3m34s4.6 清理资源删除第二个 RayCluster完成实验清理kubectl delete raycluster test-yunikorn-1深入理解KubeRay 双调度器分层与排障思路要正确使用 YuniKorn 集成需要理解 Ray on Kubernetes 中存在的两层调度器详见 scheduling.mdKubernetes / YuniKorn 层决定每个 Pod 跑在哪台机器上读取容器 spec 中的资源请求、节点选择器、污点、亲和性以及队列容量等约束。当 Pod 无法被放置时表现为Pending。Ray 层决定每个 task 与 actor 运行在哪个 Ray 节点上读取ray.remote中声明的逻辑资源。当 task/actor 无法放置时表现为任务挂起而 Pod 正常运行。两层是堆叠而非并列关系Ray 只能分配 Kubernetes 已经授予 Pod 的容量。因此在 YuniKorn 集成环境下排查调度问题时可以从 Pod 状态入手快速定位Pod 全部 Running 但 task/actor 挂起问题在 Ray 层Pod 卡在Pending问题在 Kubernetes/YuniKorn 层此时应执行kubectl describe pod pod-name查看调度事件或到 YuniKorn 仪表盘检查应用是否因队列容量不足而处于Accepted/Queued状态。另外需要注意 KubeRay 派生逻辑资源的方式KubeRay 读取主 Ray 容器的 CPU、内存、GPUlimits作为 Pod 的逻辑容量CPU 向上取整为整数500m会被视为 1 个逻辑 CPU并忽略内存与 GPU 的 requests。因此在使用 YuniKorn 队列做容量规划时建议将容器的 requests 与 limits 设为一致使两层调度器看到相同的资源数值避免出现Kubernetes 认为健康、YuniKorn 队列认为已满的认知偏差。总结关键项配置/行为前置条件KubeRay ≥ 1.2.2alpha已安装 Apache YuniKorn启用方式helm install kuberay-operator kuberay/kuberay-operator --version 1.7.0 --set batchScheduler.nameyunikorn队列配置编辑yunikorn-defaultsConfigMap 中的queues.yaml定义guaranteed/max资源启用 gang scheduling设置ray.io/gang-scheduling-enabledtrue可选app-id、queue标签RayJob 支持KubeRay ≥ 1.6.0 支持对 RayJob 的 gang scheduling验证手段kubectl get pods、YuniKorn 仪表盘kubectl port-forward svc/yunikorn-service 9889:9889 -n yunikorn核心价值队列级细粒度资源共享 成组调度避免 Ray 集群被部分调度而浪费资源通过本指南的四个步骤你可以在多租户 Kubernetes 集群中让 YuniKorn 接管 Ray Pod 的调度用队列实现租户间资源隔离与配额用 gang scheduling 保证 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考