在 k8s 中Cron Job Limitations 提到不能保证一个作业会执行一次：
一个 cron 作业大约每执行一次就创建一个作业对象 日程。我们说“约”是因为在某些情况下 可能会创建两个作业，也可能不会创建作业。我们试图 使这些变得罕见，但不要完全阻止它们。因此，就业 应该是幂等的
谁能解释一下：
【问题讨论】：
标签： cron kubernetes distributed-computing jobs
控制器：
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.
Periodically 表示每 10 秒一次：
在引用的限制之后的文档在某些情况下也有一些有用的颜色，在特定的时间表上可能会启动 2 个作业或没有作业：
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 的某个合理的未来修复吗？
k8s repo 中的 area/batch 标签下没有与幂等性相关的问题，所以人们猜不到。
https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Aarea%2Fbatch
是否有任何解决方法来防止这种行为（如果正在运行的作业不能实现为幂等）？
更多地考虑幂等的具体定义，以及工作中存在提交的特定点。例如，如果作业将状态保存到暂存区，则可以使作业支持多次执行，然后有一个选举过程来确定谁的工作获胜。
其他与 cron 相关的服务也会遇到同样的问题吗？也许是核心 cron 问题？
是的，这是一个核心分布式系统问题。
对于大多数用户来说，k8s 文档提供的答案可能比需要的更精确和细致入微。如果您计划的工作是控制一些关键的医疗程序，那么计划失败案例非常重要。如果它只是进行一些系统清理，那么错过预定的运行并不重要。根据定义，几乎所有 k8s CronJobs 的用户都属于后者。
【讨论】：