已完成作业的自动清理

用于清理已完成执行的旧 Job 的存活时间机制。
特性状态: Kubernetes v1.23 [stable]

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

Kubernetes 的 TTL-after-finished 控制器 提供了一种 TTL(存活时间)机制,以限制已完成执行的 Job 对象的生命周期。

清理已完成的 Job

TTL-after-finished 控制器仅支持 Job。你可以通过指定 Job 的 .spec.ttlSecondsAfterFinished 字段来自动清理已完成的 Job(无论是 Complete 还是 Failed),如本示例所示。

TTL-after-finished 控制器假定 Job 在完成 TTL 秒后即可清理。计时器在 Job 的状态条件变为 CompleteFailed 时开始;一旦 TTL 到期,该 Job 将有资格进行级联移除。当 TTL-after-finished 控制器清理 Job 时,它将级联删除它,也就是说,它将同时删除其依赖对象。

Kubernetes 遵守 Job 上的对象生命周期保证,例如等待终结器

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

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

注意事项

更新已完成 Job 的 TTL

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

时间偏差

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

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

下一步

上次修改时间为 2024 年 10 月 14 日下午 3:21 PST:修复选择器-选择器中的拼写错误 (4d9b8d0c8c)