Ray 与 Kubernetes 的调度边界是什么

当前假设

Kubernetes 主要管理集群级容器与服务生命周期，Ray 主要管理应用级任务、Actor 与资源调度；两者可以分层协作。

验证路径

  • 分别列出调度对象、时间尺度和故障恢复边界
  • 用一个 Ray on Kubernetes 部署追踪两层控制流

可证伪的边界

若 Pod 被驱逐或节点故障，Kubernetes 应负责重新调度容器；若 actor 重启、task 重试或 placement group 无法满足，Ray 应在已获得的资源内处理。把同一故障分别注入两层，记录恢复时间、重试次数、状态是否丢失和 GPU 是否泄漏，就能验证“集群生命周期”和“应用任务生命周期”是否真的分离。

相关工具：Kubernetes、Ray。

两层控制器实际看见的对象不同

Kubernetes 的期望状态通常是“某 Deployment 有 N 个 Pod、每个 Pod 请求多少 GPU、是否通过 readiness”；Ray 的期望状态则可能是“某个 placement group 同时拿到 4 张 GPU、learner 与 rollout actor 保持角色关系、某个 task 的 object reference 可用”。因此一个 Ray worker Pod 处于 Running，并不代表 Ray actor 已注册、对象存储有空间或训练角色已经配齐。

1
2
3
4
5
6
Kubernetes scheduler
→ node / Pod / container / device plugin
→ Ray head + worker processes
→ Ray scheduler
→ task / actor / placement group / object
→ application checkpoint or result

失败注入矩阵

注入点 第一责任层 需要观察的跨层现象
节点断电或 Pod 被驱逐 Kubernetes Pod 重建后 Ray worker 是否重新加入，actor state 是否从 checkpoint 恢复
actor 进程崩溃 Ray Kubernetes Pod 仍 Running 时，Ray 是否重启 actor，object reference 是否失效
GPU 资源声明错误 两层接口 Pod 看似有 GPU 但 placement group 永远 pending，是否能从 device plugin/请求规格定位
head service 不可达 Kubernetes 网络/服务 worker 重连、任务重试和应用超时是否互相放大

如果 Kubernetes 和 Ray 都配置自动重试，单次故障可能先由 Ray 重试 task，再由 Kubernetes 重启 Pod，形成重复计算或重复副作用。应用层需保留 task id、checkpoint 版本和幂等写入；不能把“最终 Pod Running”当作业务恢复。

最小部署实验

用一个 learner、两个 rollout actor 和一个 checkpoint writer 的小工作流，分别杀 actor 进程、驱逐 worker Pod、断开 head service。记录从故障到可继续产出轨迹的时间、重复任务数、GPU 空闲时间、object store 拷贝量和 checkpoint 是否单调递增。实验能清楚显示：Kubernetes 解决的是进程/资源可用性，Ray 解决的是应用角色和任务关系；二者的交界是 worker 注册、资源声明、checkpoint 与重试策略。