状态与生命周期

创建、停止、恢复或删除任务后，Job、Task 和 Worker 的状态会逐层同步，页面可能短暂显示不同结果。先确认要回答的问题，再查看对应层级。

按问题选择查看位置

要确认的内容	先查看	还需要结合
Job 期望运行还是停止	Job spec 和操作结果	spec.stopped: false 不代表 Pod 已经运行。
每个角色应创建什么工作负载	Task spec	期望副本数不代表实际副本已经就绪。
Pod 位于哪个节点、使用哪个 IP、处于什么阶段	Worker 展开区中的 Pod 信息	页面显示的是最近一次上报结果，不包含完整事件或重试历史。
Ray 是否包含全部预期节点	Head 的 ray status、各 Worker 的连接日志和 Pod 阶段	Job 或 Task 为 Running 不代表 Ray 成员完整。
RLinf 是否开始、完成或失败	工作负载日志、指标、checkpoint 和持久输出	StatefulSet Task 不会可靠上报业务成功或失败。

需要容器重启次数、终止原因、previous logs 或实时 Kubernetes 事件时，请获授权的运维人员在数据面检查。

查看 Job 状态

状态	含义
Pending	Job 已接受，Task 正在创建或尚未进入运行阶段
Running	至少一个 Task 已进入运行协调过程
Succeeded	所有 Task 上报成功后记录的终态
Failed	至少一个 Task 上报失败后记录的终态
Stopped	spec.stopped 为 true，Job 已停止

创建 → Pending → Running → Succeeded
                  └──────→ Failed
Pending / Running → Stopped → Pending

停止 Job 会把控制台生成的 Kubernetes Task 期望副本数调整为 0。恢复会清除停止标志，使 Job 回到 Pending，再按原模板创建 Task。Stopped 不是删除，Job 配置和状态记录仍然保留。

Succeeded 和 Failed 都是终态。控制台不会为 Succeeded 提供停止或恢复操作。Failed 行可能仍显示停止操作，但它不会让 Job 重新协调或转换为 Stopped。失败后应先保存日志和输出，修正配置，再克隆为新的 Job 进行验证。

不要等待 StatefulSet Job 自动显示成功或失败

Web 控制台只创建 StatefulSet Task。这类 Task 只会上报 Pending、Running 或 Stopped，不会上报 Succeeded 或 Failed。因此，运行脚本结束、容器重启或日志报错时，Task 和 Job 仍可能显示 Running。

请用工作负载自己的完成信号、日志、指标和持久输出判断训练结果。保存所需记录后，主动停止不再需要的 Job。

删除是独立且不可撤销的操作，参见停止、恢复或删除任务。

查看 Task 状态

状态	含义
Pending	工作负载尚未满足运行条件，或所需副本尚未就绪
Running	工作负载已达到运行条件
Succeeded	Task API 中的成功终态；StatefulSet Task 不会上报该状态
Failed	Task API 中的失败终态；StatefulSet Task 不会上报该状态
Stopped	工作负载期望副本数为 0

Job 会汇总各 Task 的阶段和消息。对于 StatefulSet，Task 为 Running 只表示期望副本已经就绪；业务进程失败可能只出现在 Pod 阶段或日志中。容器重启次数和终止详情需要由获授权的运维人员在数据面 Kubernetes 中检查。

查看 Pod 和 Worker 状态

Worker 是控制台把 Task 和 Pod 组合后的视图，不是独立的状态资源。Pod 有 Pending、Running、Succeeded 和 Failed 四个阶段，没有 Stopped。停止 Job 后，Pod 会被缩容并可能从页面消失。

Pod 状态	含义
Pending	Pod 已创建但尚未运行，例如正在等待调度、拉取镜像或挂载卷
Running	Pod 已在节点上运行；应用仍可能正在初始化或等待其他组件
Succeeded	Pod 中所有容器已成功结束，且不会重启
Failed	至少一个容器失败结束，且不会按现有策略恢复

Running 只表示 Pod 阶段，不能确认训练已经产生有效进展。还要检查日志和业务输出。需要重启次数、终止原因或 previous logs 时，请运维人员到数据面检查。

不要把 Worker 行当作重试历史

Worker 列表显示数据面 Pod 名称、节点、IP 和阶段，但不显示 Pod UID、attempt 编号、终止时间或实例替换关系。页面中的 Worker 创建时间由 Job 开始时间和行顺序计算，也不是 Pod 的创建时间。

因此：

• 同名 Worker 出现多行时，无法仅凭页面确定它们的重试顺序；
• 同名但不同 IP 或阶段，可能来自 Pod 重建、状态同步延迟或尚未清理的旧记录；
• Worker 行消失不能替代终止事件或历史审计记录；
• Task 中的 retry 相关值不能补全页面没有提供的逐实例 attempt 关系。

排查时记录 Job、Task、数据面 Pod 名称、节点、IP、阶段和查看时间。需要确认实例替换顺序时，请管理员结合 Pod UID、创建时间、终止时间和事件建立时间线。

查看 Workflow 状态

状态	含义
Pending	还没有可执行的子 Job 进入运行
Running	至少一个子 Job 正在执行
Succeeded	所有子 Job 均成功完成
Failed	子 Job 失败，Workflow 无法按定义完成

Workflow 会根据子 Job 和 DAG 依赖汇总状态。由于控制台生成的 StatefulSet Job 无法可靠上报 Succeeded 或 Failed，Workflow 也可能无法自动进入终态。参见工作流。

查看 Node 和 Addon 状态

• Node 只有 Online 和 Offline 两种阶段。可调度性由 spec.unschedulable 单独控制，因此 Online 节点仍可能不接收新任务。
• Addon 可以处于 Pending、Installing、Ready、Failed 或 Upgrading。Ready 表示 Addon 已达到期望版本；使用它的业务链路还要单独验证。

排查长时间不变的状态

先等待一次正常协调，再按顺序检查：

1. Job 的 Task 状态和消息。
2. Task 的目标集群、节点选择和工作负载状态。
3. Worker/Pod 的阶段、节点、IP 和日志。
4. 镜像、资源、存储和网络依赖。

不要只看列表颜色判断原因。状态长时间不变时，按训练任务与 Worker 排障记录信息并逐层定位。