已完成作业的自动清理

当你的 Job 执行完成后，将该 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 就符合被清除的条件。当 Job 的状态条件变为 Complete 或 Failed 时，计时器就开始计时；一旦 TTL 到期，该 Job 就符合进行级联删除的条件。当 TTL-after-finished 控制器清除 Job 时，它会级联删除，也就是说它会连同其依赖对象一起删除。

Kubernetes 遵守 Job 上的对象生命周期保证，例如等待finalizers。

你可以在任何时候设置 TTL 秒数。以下是一些设置 Job 的 .spec.ttlSecondsAfterFinished 字段的示例

• 在 Job 清单文件中指定此字段，以便 Job 在完成一段时间后能自动清除。
• 手动设置现有的、已完成的 Job 的此字段，以便它们符合被清除的条件。
• 在 Job 创建时使用修改性准入 Webhook 动态设置此字段。集群管理员可以使用此方法对已完成的 Job 强制执行 TTL 策略。
• 在 Job 完成后使用修改性准入 Webhook 动态设置此字段，并根据 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 时请注意此风险。

下一步

• 阅读自动清除 Job

• 参考关于添加此机制的Kubernetes 增强提案 (KEP)。