在 Kubernetes cronjobs 中，limitations section 中表示
如果 CronJob 控制器在从 CronJob 开始时间到开始时间加上startingDeadlineSeconds 之前的一段时间内未运行或中断，或者如果跨度涵盖多个开始时间并且concurrencyPolicy 不允许并发，则作业可能无法运行.
我从中了解到的是，如果 startingDeadlineSeconds 设置为 10 并且 cronjob 由于某种原因无法在其预定时间启动，那么它仍然可以尝试重新启动，只要那些10秒还没有过去，但是，在10秒之后，它肯定不会启动，对吗？
另外，如果我将concurrencyPolicy 设置为Forbid，如果一个cronjob 已经在运行，K8s 是否会将其视为失败？
【问题讨论】：
标签： kubernetes kubernetes-cronjob
在调查了Kubernetes repo 的代码库之后，CronJob 控制器是这样工作的：
CronJob 控制器 will check the every 10 seconds 给定 Kubernetes 客户端中的 cronjobs 列表。
对于每个 CronJob，它会检查从 lastScheduleTime 到现在的持续时间内错过了多少计划。如果超过100 missed schedules，则不启动作业并记录事件：
"FailedNeedsStart", "Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew."
重要要注意，如果设置了startingDeadlineSeconds 字段（不是nil），它将统计从startingDeadlineSeconds 的值到现在发生了多少错过的工作。例如，如果startingDeadlineSeconds = 200，它将计算在最后200 秒内发生了多少错过的作业。计算错过的时间表的具体实现可以在here找到。
如果上一步错过的计划不超过 100 个，CronJob 控制器将检查时间 now 是否不晚于其 scheduledTime + startingDeadlineSeconds 的时间，即现在开始工作（通过了最后期限）。如果还不算太晚，作业将继续尝试由 CronJob 控制器启动。但是，如果已经太晚了，那么它就不会开始工作并记录事件：
"Missed starting window for {cronjob name}. Missed scheduled time to start a job {scheduledTime}"
还有一点重要需要注意，如果startingDeadlineSeconds这个字段没有设置，那么就意味着根本没有截止日期。这意味着作业将由 CronJob 控制器尝试启动，而不检查它是否更晚。
因此回答以上问题：
1.如果 startDeadlineSeconds 设置为 10 并且 cronjob 由于某种原因无法在其预定时间启动，那么只要这 10 秒还没有过去，它仍然可以尝试再次启动，但是，在 10 秒之后，它肯定不会启动，这样对吗？
CronJob 控制器将尝试启动作业，如果在其调度时间之后的 10 秒内尚未过去，它将被成功调度。但是，如果截止日期已过，则不会在本次运行中启动它，并且在以后的执行中将被计为错过的时间表。
2。如果我将 concurrencyPolicy 设置为 Forbid，如果一个 cronjob 尝试被调度，而 K8s 是否会将其视为失败，而此时已经有一个 cronjob 正在运行？
是的，这将被计为错过的时间表。由于错过的时间表是按照我在上面第 2 点中所述的方式计算的。
【讨论】：