你正在查看的文档所针对的是 Kubernetes 版本: v1.27

Kubernetes v1.27 版本的文档已不再维护。你现在看到的版本来自于一份静态的快照。如需查阅最新文档,请点击 最新版本。

已完成 Job 的自动清理

一种用于清理已完成执行的旧 Job 的 TTL 机制。
特性状态: Kubernetes v1.23 [stable]

当你的 Job 已结束时,将 Job 保留在 API 中(而不是立即删除 Job)很有用, 这样你就可以判断 Job 是成功还是失败。

Kubernetes TTL-after-finished 控制器提供了一种 TTL 机制来限制已完成执行的 Job 对象的生命期。

清理已完成的 Job

TTL-after-finished 控制器只支持 Job。你可以通过指定 Job 的 .spec.ttlSecondsAfterFinished 字段来自动清理已结束的 Job(CompleteFailed), 如示例所示。

TTL-after-finished 控制器假设 Job 能在执行完成后的 TTL 秒内被清理。一旦 Job 的状态条件发生变化表明该 Job 是 CompleteFailed,计时器就会启动;一旦 TTL 已过期,该 Job 就能被级联删除。 当 TTL 控制器清理作业时,它将做级联删除操作,即删除 Job 的同时也删除其依赖对象。

Kubernetes 尊重 Job 对象的生命周期保证,例如等待 Finalizer

你可以随时设置 TTL 秒。以下是设置 Job 的 .spec.ttlSecondsAfterFinished 字段的一些示例:

  • 在 Job 清单(manifest)中指定此字段,以便 Job 在完成后的某个时间被自动清理。
  • 手动设置现有的、已完成的 Job 的此字段,以便这些 Job 可被清理。
  • 在创建 Job 时使用修改性质的准入 Webhook 动态设置该字段。集群管理员可以使用它对已完成的作业强制执行 TTL 策略。
  • 使用修改性质的准入 Webhook 在 Job 完成后动态设置该字段,并根据 Job 状态、标签等选择不同的 TTL 值。 对于这种情况,Webhook 需要检测 Job 的 .status 变化,并且仅在 Job 被标记为已完成时设置 TTL。
  • 编写你自己的控制器来管理与特定选择算符匹配的 Job 的清理 TTL。

警告

更新已完成 Job 的 TTL

在创建 Job 或已经执行结束后,你仍可以修改其 TTL 周期,例如 Job 的 .spec.ttlSecondsAfterFinished 字段。 如果你在当前 ttlSecondsAfterFinished 时长已过期后延长 TTL 周期, 即使延长 TTL 的更新得到了成功的 API 响应,Kubernetes 也不保证保留此 Job,

时间偏差

由于 TTL-after-finished 控制器使用存储在 Kubernetes Job 中的时间戳来确定 TTL 是否已过期, 因此该功能对集群中的时间偏差很敏感,这可能导致控制平面在错误的时间清理 Job 对象。

时钟并不总是如此正确,但差异应该很小。 设置非零 TTL 时请注意避免这种风险。

接下来