cron - 为什么在 kubernetes cron 作业中可能会创建两个作业，或者可能不会创建作业？

Question

在 k8s 中 Cron Job Limitations提到不能保证作业只会执行一次:

A cron job creates a job object about once per execution time of its schedule. We say “about” because there are certain circumstances where two jobs might be created, or no job might be created. We attempt to make these rare, but do not completely prevent them. Therefore, jobs should be idempotent

谁能解释一下:

• 为什么会发生这种情况？
• 发生这种情况的概率/统计数据是多少？
• 它会在 k8s 的某个合理的 future 得到修复吗？
• 是否有任何解决方法可以防止这种行为(如果正在运行的作业无法实现幂等)？
• 其他cron 相关服务是否也遇到同样的问题？也许这是一个核心的 cron 问题？

Answer 1

Controller :

https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/cronjob/cronjob_controller.go

以一条评论开头，为解释奠定基础:

I did not use watch or expectations. Those add a lot of corner cases, and we aren't expecting a large volume of jobs or scheduledJobs. (We are favoring correctness over scalability.)  

If we find a single controller thread is too slow because there are a lot of Jobs or CronJobs, we we can parallelize by Namespace. If we find the load on the API server is too high, we can use a watch and UndeltaStore.) 

Just periodically list jobs and SJs, and then reconcile them.

定期意味着每 10 秒一次:

https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/cronjob/cronjob_controller.go#L105

遵循所引用的限制的文档对于某些情况也有一些有用的说明，在这些情况下，可能会在特定的时间表上启动 2 个作业或不启 Action 业:

If startingDeadlineSeconds is set to a large value or left unset (the default) and if concurrentPolicy is set to AllowConcurrent, the jobs will always run at least once.

Jobs may fail to run if the CronJob controller is not running or broken for a span of time from before the start time of the CronJob to start time plus startingDeadlineSeconds, or if the span covers multiple start times and concurrencyPolicy does not allow concurrency. For example, suppose a cron job is set to start at exactly 08:30:00 and its startingDeadlineSeconds is set to 10, if the CronJob controller happens to be down from 08:29:00 to 08:42:00, the job will not start. Set a longer startingDeadlineSeconds if starting later is better than not starting at all.

更高层次，在分布式系统中只解决一次是很困难的:

https://bravenewgeek.com/you-cannot-have-exactly-once-delivery/

分布式系统中的时钟和时间同步也很困难:

https://8thlight.com/blog/rylan-dirksen/2013/10/04/synchronization-in-a-distributed-system.html

对于问题:

• 为什么会发生这种情况？

  例如，托管 CronJobController 的节点在作业应该运行时发生故障。

• 这种情况发生的概率/统计数据是多少？

  对于任何给定的运行来说都不太可能。对于足够多的运行次数，不太可能避免面对这个问题。

• 它会在 k8s 的某个合理的 future 得到修复吗？

  k8s 存储库中的区域/批处理标签下没有与幂等性相关的问题，所以人们会猜测不会。

  https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Aarea%2Fbatch

• 是否有任何解决方法可以防止这种行为(如果正在运行的作业无法实现为幂等)？

  更多地考虑幂等的具体定义，以及作业中存在提交的特定点。例如，如果作业将状态保存到暂存区域，则可以使作业支持多次执行，然后有一个选举过程来确定谁的作业获胜。

• 其他 cron 相关服务是否也遇到同样的问题？也许这是一个核心的 cron 问题？

  是的，这是一个核心的分布式系统问题。

  对于大多数用户来说，k8s 文档可能给出了比必要的更加精确和细致的答案。如果您的预定工作是控制一些关键的医疗程序，那么为失败案例做好计划就非常重要。如果只是进行一些系统清理，错过预定的运行并没有多大关系。根据定义，几乎所有 k8s CronJobs 用户都属于后一类。