Cronjob

CronJob 本身不跑你的任务：它创建一个 Job，Job 再创建 Pod。Pod 跑完之后，Job 和 Pod 都不会自动消失。Pod 是故意留着的，好让你事后还能读到它的日志；Job 留着，是为了让你还能看到这次运行的状态。 这份默认对一次运行是对的，对一万次运行就是错的。每一个已完成的 Job 都是 etcd 里的一个对象、每次列表响应里的一行，以及所有关心 Job 的控制器都会收到的一次 watch 事件。给这堆东西设边界的有两套彼此独立的机制：CronJob 控制器按数量裁的历史上限，和 TTL 控制器按时间裁的 TTL。 已完成的 Job 并不免费 已完成的 Job 会留住它的 Pod，而 Pod 只要还在，容器日志就还在。于是保留策略成了你和“命名空间堆满墓碑”之间唯一的东西。按小时调度跑三十天就是 720 次运行：720 个 Job 加 720 个 Pod，每个都有自己的名字、状态、owner reference，以及你每次 kubectl get jobs 输出里的一行。已完成的 Job 也不是完全静止的：它的 status conditions 一直留在 API 里，被每个 watcher 反复读取。单个对象的开销微不足道，但它是随时间线性增长的，所以它长期保持隐形，直到某天突然变成问题。 ...

CronJob 就是一份 Job 模板加一条 cron 表达式。表达式每次匹配，控制器就新建一个 Job，由它把 Pod 跑到完成再停掉。两轮之间没有任何常驻进程，这正是它吸引人的地方：批处理任务直接继承集群的重试、资源与调度机制，不需要谁养一个守护进程来触发它。 代价是时间表只被“近似”兑现。Kubernetes 承诺每个执行时刻“大约”创建一个 Job，这句措辞把两个方向的偏差都包了进去——同一时刻冒出两个 Job，或者一个都没有。凡是被排进 CronJob 的活都必须能安全跑两遍，因为你真正拿到的保证是至少一次，而不是恰好一次。 一张时间表催生一个 Job schedule 用熟悉的五个字段——分、时、日、月、星期——支持 Vixie cron 的区间与步长写法，所以 */10 * * * * 每十分钟触发一次，*/15 9-17 * * mon-fri 只落在工作时段内。? 与 * 等价，@daily、@hourly 这类宏会展开成对应的表达式。没有设置 timeZone 的 CronJob 跟随控制器管理器所在时区的本地时钟，控制面一换地方，任务的执行时刻就跟着变。少写一个字段是校验错误，这也让它成为 CronJob 少数会大声失败的配置错误之一。 ...