Job 一直 ImagePullBackOff 不结束：backoffLimit 不限制拉取次数

批处理 Job 引用了不存在的镜像，Pod 已调度到节点，却反复出现 ErrImagePull、ImagePullBackOff 和 Back-off pulling image。即使 Job 设置了 backoffLimit，任务也可能长时间不结束：镜像拉取重试不等于 Job 已产生了失败的 Pod。

如果目标是让这种部署错误在限定时间内结束，应在 Job 的 spec.activeDeadlineSeconds 设置整个任务的期限，同时修复镜像引用或仓库访问。期限让任务失败退出，不会把错误镜像变成可拉取的镜像。

镜像没启动，Job 可能还没有可计数的失败

以下命令用于查看实际对象，命名空间和名称都是示例：

kubectl -n batch get job report-task -o yaml
kubectl -n batch describe job report-task
kubectl -n batch describe pod report-task-abc123

核对 Pod 的 ownerReferences 指向该 Job，再看 Pod phase、容器 state 和拉取事件。容器处于 Waiting、Pod 仍是 Pending，与容器启动后非零退出是不同结果。

普通 Job 的 backoffLimit 根据失败 Pod 计数；采用 restartPolicy: OnFailure 时，还会考虑相关 Pod 中容器重启次数。拉取镜像失败时，容器尚未启动，不能把每条 Failed 拉取事件都当成一次容器运行失败。因此把 backoffLimit 改成 0，也不等于“镜像只尝试拉一次”。

事件中的具体错误仍需单独处理。不存在的仓库或标签、授权失败、TLS 或网络错误，都可能进入 ImagePullBackOff；不要把退避状态直接解释成凭据一定错了。

期限写在 Job 层，覆盖整个任务

下面是非暂停、单次任务的清单结构示例。镜像为占位值，需替换成已验证、符合任务用途的镜像，并补回应用需要的参数、权限和挂载：

apiVersion: batch/v1
kind: Job
metadata:
  name: report-task
  namespace: batch
spec:
  completions: 1
  parallelism: 1
  backoffLimit: 2
  activeDeadlineSeconds: 180
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: task
          image: registry.example.com/team/report:tested

这里的 180 秒是整个 Job 的时间预算，不是一次下载超时，也不是业务程序启动后的专属运行时长。调度、拉取镜像和后续运行都会占用任务时间。需要把正常镜像下载与业务耗时一起纳入预算，不能给所有任务套同一个值。

Job 和内部 Pod 模板都存在名为 activeDeadlineSeconds 的字段。写到 spec.template.spec 只约束单个 Pod，不能代替 Job 自己的 spec.activeDeadlineSeconds。Job 可能创建多个 Pod；限制每个 Pod，并不天然限制整个 Job 的累计持续时间。

Job 期限优先于 backoffLimit。到期后控制器终止相关工作，不会因为还剩重试次数就继续创建 Pod；失败原因应体现 DeadlineExceeded。控制器处理和 Pod 终止有延迟，不能把配置理解为严格在第 180 秒瞬间完成全部清理。

TTL 和拉取超时解决不了同一个问题

ttlSecondsAfterFinished 用于清理已经完成或失败的 Job。还在等待镜像、没有进入结束状态的任务，不会仅因这个字段就被判定失败。排查期间也不宜设成结束后立即删除，以免丢失对象和事件线索。

单次拉取的超时或节点退避参数属于另一层。它们可能改变一次尝试花多久，却不能表达“这个 Job 总共最多等待和运行多久”。不应为了一个批任务修改整个集群的 kubelet 行为。

如果工作负载受更高层控制器或平台管理，还要检查它是否会在 Job 失败后重新创建新任务。当前 Job 已超时，与平台永远重试新的 Job，可以同时发生；整体失败策略需要在原管理入口配置。

到期失败后，保留证据再安排重跑

变更前保存 Job 清单与事件，确认允许中断的工作范围。时间期限也会终止已经启动但尚未结束的业务程序，可能留下部分文件或外部写入。任务需要自行处理幂等、检查点或重跑去重。

验证时检查该 Job 的失败原因和所属 Pod 的终止情况。Kubernetes 1.31 及以后的常规行为会等待全部 Job Pod 终止后才添加最终 Failed 条件；宽限终止期间不能仅因最终条件尚未出现，就立即创建可能重叠的替代任务。

超时失败的 Job 不会因为后来修正仓库就自动恢复。修复镜像或认证配置后，通过原批任务入口创建新的执行，并检查它能拉取镜像、完成业务和产物校验。

回退期限设置时恢复原配置并核对实际对象，不直接删除正在写数据的任务来试参数。已经发生的终止和业务写入不会随 YAML 回退撤销；需要重跑的任务应按业务记录单独安排。