Kubernetes中的Job 的自动清理-Kubernetes中文教程(二)

当前位置:　首页>> 技术小册>> Kubernetes中文教程(二)

当你的 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 控制器清理作业时，它将做级联删除操作，即删除 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 时请注意避免这种风险。

* 阅读[自动清理 Job]

* 参阅 [Kubernetes 增强提案]
   了解此机制的演进过程。

该分类下的相关小册推荐：

Kubernets合辑15-持续部署

Kubernetes中文教程(六)

Kubernets合辑5-Pod控制器

Kubernets合辑13-集群监控

Kubernets合辑7-存储

Kubernetes中文教程(三)

Kubernetes中文教程(五)

Kubernets合辑10-网络

Kubernetes中文教程(四)

云原生-K8S入门实战

Kubernets合辑6-服务发现

Kubernets合辑2-部署Ingress