任务创建字段

控制台中的创建任务会提交一个 rlinf.io/v1alpha1 Job。可以用本页把表单字段与 YAML 预览逐项对照。RLark Job 定义资源和运行结构；RLinf/Hydra 配置随镜像、配置文件或运行命令进入工作负载。

spec.tasks[] 中的条目是 Task 模板，对应控制台中的角色。Job 提交后，RLark 才根据这些模板创建 Task 资源和 Worker。YAML 预览只显示将要提交的 Job，不表示 Task 或 Worker 已经存在。

cluster.num_nodes: 1 且一个 GPU 节点能够提供全部运行条件时，请先按照在单个 GPU 节点上运行 RLinf完成常见填写。多节点、多个 node_groups 或不同 Worker 需要不同运行条件时，再阅读规划多节点和异构 Worker。需要进一步核对镜像、资源、存储或外部依赖时，参见提交训练任务前检查。

单节点任务的常见角色配置

选择自定义任务，添加一个名为 worker 的角色，让它只匹配 1 个 Node，并把它设为 Header。GPU 填写该工作负载实际需要的数量；Actor、Rollout、Env 等组件仍由 RLinf 配置中的 component_placement 放置。

核对 Job 级字段

控制台字段	写入位置	表单行为和使用限制
任务名称	metadata.name	必须是 1–63 位小写 DNS 名称。
任务类型	不写入 CRD	只决定弹窗最初添加哪些角色。RL、数据采集、评测和自定义不是 Job API 中的类型字段；提交后不会保留这次选择，控制台再次读取 Job 时会根据 Task 模板的角色推断显示类型。
Header 角色	对应模板的 spec.tasks[].head	只有选中的角色为 true。Head 标记会作用于该模板创建的所有 Worker，因此该角色必须只有 1 个副本。
网络域	spec.domain	可选，由各 Task 继承。选择 Domain 不会替应用设置通信网卡。
SSH 公钥	spec.sshPublicKey	可选，同一公钥会注入所有角色的 Pod。
运行脚本	Header 模板的 runScript	只写入 Header 角色对应的 Task 模板，但该模板创建的每个 Worker 都会执行，因此必须保持单副本。
TensorBoard 日志目录	Header 模板的 tensorBoardDir	用于配置代理和 sidecar 的容器路径。训练程序把 event 文件写入该目录后，TensorBoard 才能读取。

核对每个角色的字段

控制台字段	写入位置	表单行为和使用限制
角色显示名称	spec.tasks[].name、RLARK_TASK_ROLE	显示名称会转换为小写 Task 模板名称，并按名称映射为 Actor、Rollout 或 Env。自定义名称不会创建新的 API 角色。
集群	不写入独立字段	用于筛选弹窗中的 Node、设备和 StorageClass。Job 提交后，Task 所在命名空间由全部 Node 中的 nodeSelector 匹配结果决定。
节点选择	nodeSelector	只使用管理员在全部 Node 中验证过、由不同标签键组成且只命中预期集群的单值条件。
已选节点数	StatefulSet replicas	根据所选集群内的匹配节点数按角色单独计算，不是可编辑的 Worker 数。同一个 Node 匹配多个角色时，会在每个角色中分别计数，不会跨角色去重。还需确认其他集群中没有同标签节点。
GPU	主容器 resources requests 和 limits 中的 nvidia.com/gpu	非零值同时写入 request 和 limit。只有界面计算出大于 0 的上限时，才会阻止超额输入。
设备资源	主容器 resources requests 和 limits 中的 rlinf.io/*	非零值同时写入 request 和 limit。表单不会检查每个实际落点能否满足请求。
CPU、内存	表单没有输入项	Job 的 Pod 模板可以表达，但创建任务弹窗不会生成。必须声明时，请停止使用该弹窗并向平台管理员取得受支持的配置方式。
镜像	main 容器的 image	只检查非空。提交前还要验证仓库权限、镜像版本、镜像内容和多角色兼容性。版本 tag 与 digest 的选择见创建训练任务。
准备脚本	prepareScript	在每个副本启动 Ray 前，由同一个 bash 包装进程执行。
环境变量	main 容器的 env	只属于对应角色，不会自动覆盖 Hydra 字段。不要填写敏感值。
主机目录	Pod hostPath volume 和 volumeMount	源路径属于 Worker 所在节点；每个实际落点都必须存在相同路径，并具备正确内容、空间和权限。训练程序使用 volumeMount 的容器路径。
对象存储	PVC volume、volumeMount 和 pvcStorageMap	StorageClass 必须可用于目标集群。Task 启动时确保对应 PVC；创建表单不直接填写 Bucket 或对象键，训练程序使用容器挂载路径及其下的相对对象路径。

填写这两个选项前，先按照在训练任务中使用存储确认数据位置、容器路径、StorageClass 和多 Worker 访问方式。

各角色的数量和资源分别累计：计划创建的 Worker 总数是所有角色的已选节点数之和；某个角色的 GPU 申请量是该角色的已选节点数 × 单个 Worker GPU 数量。多个角色选择同一批 Node 时，也按这两个规则计算。提交前请在 YAML 预览中逐个核对 Task 模板的副本数，并确认重叠节点能够满足这些角色合计的资源需求。

控制台还会固定生成：

• agentType: Kubernetes；
• kind: StatefulSet 工作负载；
• 名为 main 的业务容器；
• 平台生成的 RLARK_TASK_ROLE；
• Ray Head 或 Worker 包装脚本及平台环境变量。

Task API 还可以表达其他 Kubernetes 工作负载、Docker 和 Raw 类型，但控制台没有对应的创建流程。

对齐 RLark 资源和 RLinf 配置

RLark Job 定义 Worker 使用的节点、GPU、镜像和挂载；RLinf 工作负载带入 Hydra 应用配置，并通过 component_placement 决定组件进程如何使用这些资源。控制台不会导入或改写 RLinf 配置。

下表用于区分 RLinf 配置中的不同编号和控制台字段，避免把组件名称或资源编号直接当作 RLark 角色。

RLinf/Hydra 内容	表示什么	在 RLark 中如何对齐
runner.task_type、算法和执行模式	RLinf 运行方式	保留在 RLinf 配置中。控制台的任务类型只预填角色列表，不设置这些值。
cluster.num_nodes	Ray 节点总数	应等于所有 Task 模板的副本数之和，也就是预期 RLark Worker 总数。多个角色命中同一个物理 Node 时仍分别计入，不能用去重后的物理节点数代替。
node_groups[].node_ranks	按 RLINF_NODE_RANK 分组的 Ray 节点	根据 Job 中 Task 模板的顺序和各模板副本数确定连续编号范围；RLark 不导入 Node Group。
component_placement 的 resource rank	组件进程使用的 GPU、机器人或节点等资源编号	核对节点组中的 Worker 数量和顺序，以及每个 Worker 的 GPU/设备数量，能够组成配置所需的资源范围；RLinf 再把资源编号映射到具体 Worker 及其本地设备。该编号不是 RLINF_NODE_RANK，控制台没有直接对应字段。
component_placement 的 process rank	Actor、Rollout、Env 等组件内部的进程编号	由 RLinf 创建和管理，不对应 RLark Worker 或 Task。
node_groups[].env_configs	指定一部分节点编号上的 RLinf 组件使用哪些变量和 Python 解释器	保留在 RLinf YAML 中。RLark 的环境变量和准备脚本在 Ray 启动前生效，作用阶段和范围与 env_configs 不同；两边都需要配置时，分别填写并核对节点编号。
runner.resume_dir、logger 和算法参数	checkpoint、日志和训练行为	在 RLinf 配置或运行脚本中固定这些值；Job CRD 不包含对应字段。

迁移任务时，分别检查：

1. RLark 的控制台角色是否对应计划的 Ray 节点和 Worker 分组，而不是按 RLinf 组件名称机械拆分。
2. 目标镜像中的 RLinf/Hydra 配置是否表达了正确的应用要求。
3. Worker 数量、节点编号、资源编号、进程编号、路径和网络假设是否逐项对齐。

YAML 预览正确，只能确认 Job CRD 的内容，不能确认 RLinf 配置已经兼容。

保存实际使用的运行配置

任务运行时需要分别核对以下来源：

1. 镜像提供代码、Python/Ray 环境、默认文件和系统依赖。RLark 会覆盖主容器 ENTRYPOINT，不要依赖原入口产生的副作用。
2. 外部 Hydra YAML由镜像中的 RLinf 入口按对应版本组合和插值；RLark 不读取它。
3. Pod 环境变量只有被 Hydra、脚本或应用显式读取时，才会影响业务配置。
4. 准备脚本可以在 Ray 启动前激活环境或准备文件。
5. 运行脚本中的命令行 override由应用解释，RLark 按表单内容执行脚本文本。

这些来源的优先级由 RLinf、Hydra 和脚本决定，控制台不会把它们合并成统一的覆盖顺序。例如，同名环境变量是否覆盖 Hydra 值，取决于应用自己的配置逻辑。

控制台的 YAML 预览只显示 Job CRD，不会导入或解析 Hydra YAML。需要重现运行或比较两次结果时，请按提交训练任务前检查保存脱敏的 RLinf 最终配置，并把镜像地址、版本 tag 及其实际 digest 与 Hydra 输入和 Job YAML 一并归档。