已完成作业的自动清理

一种用于清理已完成执行的旧作业的生存时间机制。
功能状态： Kubernetes v1.23 [稳定]

当你的作业完成后，将该作业保留在 API 中（而不是立即删除该作业）是很有用的，这样你就可以知道该作业是成功还是失败。

Kubernetes 的完成 TTL 控制器 提供了一种 TTL（生存时间）机制来限制已完成执行的作业对象的生存期。

清理已完成的作业

完成 TTL 控制器仅支持作业。你可以使用此机制通过指定作业的 .spec.ttlSecondsAfterFinished 字段来自动清理已完成的作业（Complete 或 Failed），如本 示例 所示。

完成 TTL 控制器假定作业在作业完成后 TTL 秒后有资格被清理。一旦作业的状态条件更改为显示作业为 Complete 或 Failed，计时器就会启动；一旦 TTL 过期，该作业就有资格进行 级联 删除。当完成 TTL 控制器清理作业时，它将级联删除它，也就是说它将与其一起删除其依赖对象。

Kubernetes 遵守作业上的对象生命周期保证，例如等待 终结器。

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

  • 在作业清单中指定此字段，以便作业在完成后的一段时间后自动清理。
  • 手动设置现有、已完成作业的此字段，以便它们有资格进行清理。
  • 使用 变更准入 Webhook 在作业创建时动态设置此字段。集群管理员可以使用此功能对已完成的作业强制执行 TTL 策略。
  • 在作业完成后使用 变更准入 Webhook 动态设置此字段，并根据作业状态、标签选择不同的 TTL 值。对于这种情况，Webhook 需要检测对作业 .status 的更改，并且仅在作业被标记为已完成时才设置 TTL。
  • 编写你自己的控制器来管理与特定 选择器 匹配的作业的清理 TTL。

注意事项

更新已完成作业的 TTL

你可以在作业创建或完成后修改 TTL 周期，例如作业的 .spec.ttlSecondsAfterFinished 字段。如果在现有 ttlSecondsAfterFinished 周期过期后延长 TTL 周期，Kubernetes 不保证保留该作业，即使更新以延长 TTL 返回成功的 API 响应也是如此。

时间偏差

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

时钟并不总是准确的，但差异应该非常小。设置非零 TTL 时请注意此风险。

下一步

上次修改时间：2023 年 1 月 29 日下午 2:06 PST：修复指向 mutatingadmissionwebhook 的链接 (54e010c731)