已完成作业的自动清理

当您的 Job 完成后，将该 Job 保留在 API 中（而不是立即删除它）非常有用，这样您就可以判断该 Job 是成功还是失败。

Kubernetes 的 TTL-after-finished 控制器 提供了一种 TTL（生存时间）机制，以限制已完成执行的 Job 对象的生存期。

清理已完成的 Job

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

TTL-after-finished 控制器假设 Job 在 Job 完成后 TTL 秒内有资格被清理。计时器在 Job 的状态条件更改为显示 Job 处于 Complete 或 Failed 状态后开始；一旦 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 创建或完成之后修改 TTL 周期，例如 Job 的 .spec.ttlSecondsAfterFinished 字段。如果您在现有 ttlSecondsAfterFinished 周期到期后延长 TTL 周期，Kubernetes 不保证保留该 Job，即使延长 TTL 的更新返回成功 API 响应。

时间偏差

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

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

下一步

• 阅读 自动清理 Job

• 请参阅 Kubernetes 增强提案（KEP），了解添加此机制的详细信息。