RLark Web 控制台文档

主题

Job、Task 与 Worker ​

创建任务后，可以沿着 Job、Task 和 Worker 三层查看配置是否落地、实例是否运行。Job 保存任务定义，Task 描述每个角色的执行单元，Worker 则显示实际运行的 Pod。

text
1 个 Job
├── 1 个 Head Task（必须只有 1 个 Worker）
├── 0..N 个其他 Task
└── 每个 Task 通过工作负载副本产生 0..N 个 Worker

查看 Job 定义 ​

Job 是集群级资源，主要保存：

  • 所属 Domain；
  • 是否停止的 stopped 标志；
  • 一组 Task 模板；
  • 可选的 SSH 公钥。

在控制台中，用户按角色配置镜像、资源、节点、挂载和环境变量，并指定一个 Head 角色。提交后，RLark 会为每个模板创建对应的 Task。

核对每个 Task ​

Task 是命名空间级资源，记录：

  • Actor、Rollout 或 Env 之一的角色；
  • Kubernetes、Docker 或 Raw 接入形态；
  • Domain、数据平面名称和 nodeSelector；
  • 工作负载、副本、Pod 模板和存储映射；
  • 准备脚本、运行脚本和可选的 TensorBoard 目录。

Web 控制台创建的是 Kubernetes StatefulSet Task。每个角色的副本数来自创建器在所选集群内计算出的匹配节点数，Task 的命名空间则由全部 Node 中的 nodeSelector 匹配结果决定。提交前，请管理员确认选择器只包含单值条件，并且只命中预期集群。

准备脚本会在 Ray 启动前执行。运行脚本写入 Head Task；如果配置了 TensorBoard 目录，该 Task 还会提供 TensorBoard 代理入口。脚本输出和故障通常要从 Worker 日志、Pod 阶段和持久输出中判断。

Head Task 必须只有一个副本

Head 包装脚本会在 Head Task 的每个 Pod 中启动 Ray Head，并执行同一份运行脚本。提交前必须确认 Head 角色的完整选择器在全部 Node 中恰好匹配 1 个节点，并在 YAML 预览中确认副本数为 1。

在 Worker 视图检查运行实例 ​

Worker 是控制台对 Task 下实际 Pod 的展示，不是独立的 RLark CRD。展开 Worker 后可以查看：

  • 所属角色和 Task；
  • 阶段、节点和 IP；
  • 数据面 Pod 名称；
  • 日志、WebTerminal 和其他运行时入口。

如果工作负载还没有产生 Pod，页面可能只显示 Task 级状态，此时节点、Pod 名称和终端入口尚不可用。

结合各层状态判断进展 ​

状态会按以下顺序汇总：

  1. 数据面工作负载和 Pod 产生运行状态。
  2. Agent 把状态同步到 Task 和 Pod 资源。
  3. RLark 汇总各 Task 阶段并更新 Job。
  4. 控制台把 Job、Task 和最近上报的 Pod 状态组合成 Worker 视图。

刚提交、停止或恢复任务后，各层显示可能短暂不同步。先等待一次正常协调，再结合 Task 消息、Worker 日志和业务输出判断。

StatefulSet Task 不会上报 Failed。运行脚本结束、容器重启或日志报错时，Job 和 Task 仍可能显示 Running；控制台未展示的容器终止原因和重启详情需要由获授权的运维人员在数据面 Kubernetes 中检查。

迁移旧版任务定义 ​

旧版文档中的 JobSpec、Worker Group 和 node_names 属于旧平台模型。迁移时，应分别把它们重新表达为 Job 的 Task 模板、Task 角色、节点选择和工作负载副本，不要直接复制旧字段。