主题
任务创建字段
创建任务时，可以用本页把表单字段与 YAML 预览中的 rlinf.io/v1alpha1 Job 对照起来。RLark Job 定义资源和运行结构；RLinf/Hydra 配置随镜像、配置文件或运行命令进入工作负载。YAML 预览只显示即将提交给 RLark 的资源定义。
首次提交前，先准备启动清单，再向平台管理员取得部署参数。不要自行猜测集群、选择器、资源或存储默认值。
核对 Job 级字段
| 控制台字段 | 写入位置 | 表单行为和使用限制 |
|---|---|---|
| 任务名称 | metadata.name | 必须是 1–63 位小写 DNS 名称。 |
| 任务类型 | 不写入 CRD | 只决定弹窗最初添加哪些角色。RL、数据采集、评测和自定义不是 Job API 中的类型字段。 |
| Header 角色 | 对应模板的 spec.tasks[].head | 只有选中的角色为 true。Head 标记会作用于该 Task 的所有副本，因此该角色必须只有 1 个副本。 |
| 网络域 | spec.domain | 可选，由各 Task 继承。选择 Domain 不会替应用设置通信网卡。 |
| SSH 公钥 | spec.sshPublicKey | 可选，同一公钥会注入所有角色的 Pod。 |
| 运行脚本 | Header 模板的 runScript | 只写入 Head Task，但该 Task 的每个副本都会执行，因此必须保持单副本。 |
| TensorBoard 日志目录 | Header 模板的 tensorBoardDir | 用于配置代理和 sidecar 的容器路径。训练程序把 event 文件写入该目录后，TensorBoard 才能读取。 |
核对每个角色的字段
| 控制台字段 | 写入位置 | 表单行为和使用限制 |
|---|---|---|
| 角色显示名称 | spec.tasks[].name、RLARK_TASK_ROLE | 显示名称会转换为小写 Task 名，并按名称映射为 Actor、Rollout 或 Env。自定义名称不会创建新的 API 角色。 |
| 集群 | 不写入独立字段 | 用于筛选弹窗中的 Node、设备和 StorageClass。Task 命名空间由全部 Node 中的 nodeSelector 匹配结果决定。 |
| 节点选择 | nodeSelector | 只使用管理员在全部 Node 中验证过、由不同标签键组成且只命中预期集群的单值条件。 |
| 已选节点数 | StatefulSet replicas | 根据所选集群内的匹配节点数自动计算，不是可编辑的 Worker 数。还需确认其他集群中没有同标签节点。 |
| GPU | 主容器 resources requests 和 limits 中的 nvidia.com/gpu | 非零值同时写入 request 和 limit。只有界面计算出大于 0 的上限时，才会阻止超额输入。 |
| 设备资源 | 主容器 resources requests 和 limits 中的 rlinf.io/* | 非零值同时写入 request 和 limit。表单不会检查每个实际落点能否满足请求。 |
| CPU、内存 | 表单没有输入项 | Job 的 Pod 模板可以表达，但控制台创建器不会生成。必须声明时，请停止使用该弹窗并向平台管理员取得受支持的配置方式。 |
| 镜像 | main 容器的 image | 只检查非空。提交前还要验证仓库权限、digest、镜像内容和多角色兼容性。 |
| 准备脚本 | prepareScript | 在每个副本启动 Ray 前，由同一个 bash 包装进程执行。 |
| 环境变量 | main 容器的 env | 只属于对应角色，不会自动覆盖 Hydra 字段。不要填写敏感值。 |
| 主机目录 | Pod hostPath volume 和 volumeMount | 每个实际节点都必须存在相同路径，并具备正确内容和权限。 |
| 对象存储 | PVC volume、volumeMount 和 pvcStorageMap | Task 启动时确保对应 PVC。容器通过挂载路径读写，不直接使用 Bucket 名称。 |
控制台还会固定生成：
agentType: Kubernetes；kind: StatefulSet工作负载；- 名为
main的业务容器； - 平台生成的
RLARK_TASK_ROLE； - Ray Head 或 Worker 包装脚本及平台环境变量。
Task API 还可以表达其他 Kubernetes 工作负载、Docker 和 Raw 类型，但控制台没有对应的创建流程。
分别映射 RLark 和 Hydra 配置
RLark Job 定义资源和运行结构，RLinf 工作负载带入 Hydra 应用配置。创建 Job 时，需要把两侧配置逐项映射；平台不会自动转换。
| RLinf/Hydra 内容 | RLark 中最接近的表达 | 提交前核对 |
|---|---|---|
cluster.node_groups | 角色、nodeSelector 和副本数 | 确认节点数量、GPU 拓扑和进程布局一致；RLark 不导入 Node Group。 |
cluster.component_placement | 角色级资源和落点 | 确认每个角色对应正确的 RLinf placement strategy；角色名称不会自动转换。 |
node_groups[].env_configs | 角色环境变量、准备脚本或外部配置文件 | 确认脚本或应用读取对应值；RLark 不读取这些 Hydra 字段，也不会在两处之间同步。 |
| hardware rank | 平台生成的 RLINF_NODE_RANK | 核对 Task 顺序、副本数和 StatefulSet Pod 序号是否与 Hydra placement 的顺序一致。 |
runner.resume_dir、logger 和算法参数 | 外部 Hydra 文件或经过验证的运行脚本 override | 在 RLinf 配置或运行脚本中固定这些值；Job CRD 不包含对应字段。 |
迁移任务时，分别检查：
- RLark 的角色、节点、资源、脚本和挂载是否表达了正确的基础设施要求。
- 目标镜像中的 RLinf/Hydra 配置是否表达了正确的应用要求。
- 进程数量、rank、路径和网络假设是否逐项对齐。
YAML 预览正确，只能确认 Job CRD 的内容，不能确认 RLinf 配置已经兼容。
保存实际使用的运行配置
任务运行时需要分别核对以下来源：
- 镜像提供代码、Python/Ray 环境、默认文件和系统依赖。RLark 会覆盖主容器
ENTRYPOINT，不要依赖原入口产生的副作用。 - 外部 Hydra YAML由镜像中的 RLinf 入口按对应版本组合和插值；RLark 不读取它。
- Pod 环境变量只有被 Hydra、脚本或应用显式读取时，才会影响业务配置。
- 准备脚本可以在 Ray 启动前激活环境或准备文件。
- 运行脚本中的命令行 override由应用解释，RLark 按表单内容执行脚本文本。
这些来源的优先级由 RLinf、Hydra 和脚本决定，控制台不会把它们合并成统一的覆盖顺序。例如，同名环境变量是否覆盖 Hydra 值，取决于应用自己的配置逻辑。
控制台的 YAML 预览只显示 Job CRD，不会导入或解析 Hydra YAML。提交前，按训练任务启动前检查生成并保存脱敏的 RLinf 最终配置，再与镜像 digest、Hydra 输入和 Job YAML 一并归档。比较两次运行时，请使用各自保存的最终配置和运行记录。