Kubernetesでは cronjobs 、 limitations section に記載されています
CronJobの開始時刻より前から開始時刻とstartingDeadlineSecondsまでの期間CronJobコントローラーが実行または破損していない場合、またはスパンが複数の開始時間をカバーし、concurrencyPolicyが並行性を許可しない場合、ジョブの実行に失敗することがあります。
これから私が理解しているのは、startingDeadlineSeconds
が10
に設定されていて、cronjobがそのスケジュールされた時間に何らかの理由で開始できなかった場合、それが再び開始を試みることができるということです10
秒が経過していないため、10
秒が経過した後、確実に開始されません。これは正しいですか?
また、concurrencyPolicy
をForbid
に設定している場合、すでに実行されているcronjobをスケジュールしようとすると、K8はそれを失敗としてカウントしますか?
Kubernetes repo のコードベースを調査した後、これがCronJobコントローラーの仕組みです:
すべてのCronJobについて、lastScheduleTime
から現在までの期間に見逃したスケジュールの数をチェックします。 100件のスケジュールの欠落 を超える場合、ジョブは開始されず、イベントが記録されます。
"FailedNeedsStart", "Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew."
重要なのはimportantです。フィールドstartingDeadlineSeconds
が設定されている場合(nil
ではなく)、これまでstartingDeadlineSeconds
の値から多くの失業したジョブが発生しました。たとえば、startingDeadlineSeconds
= 200
の場合、最後の200
秒で発生したジョブのミス数をカウントします。検出されなかったスケジュールの数をカウントする正確な実装 here 。
前のステップから100を超えてスケジュールが欠落していない場合、CronJobコントローラーは、now
がscheduledTime + startingDeadlineSeconds
の時間より後ではないか、つまり遅すぎないかどうかをチェックしますジョブを開始します(期限を過ぎました)。遅すぎなかった場合、ジョブは引き続きCronJob Controllerによって開始されようとします。ただし、すでに遅すぎる場合は、ジョブを開始せずにイベントを記録します。
"Missed starting window for {cronjob name}. Missed scheduled time to start a job {scheduledTime}"
また、importantであり、フィールドstartingDeadlineSeconds
が(nil
ではなく)設定されている場合、すべてのセットに期限はありません。これは、ジョブがCronJobコントローラーによって開始されるかどうかを確認することなく、後で開始しようとすることを意味しています。
したがって、上記の質問に答えるには:
1。 startingDeadlineSecondsが10に設定されていて、cronjobがスケジュールされた時間に何らかの理由で開始できなかった場合、10秒が経過していなければ再び開始を試みることができますが、10秒後、確かに起動しません、これは正しいですか?
CronJobコントローラーはジョブを開始しようとしますが、スケジュール時間の10秒がまだ経過していない場合は正常にスケジュールされます。ただし、期限が過ぎている場合、この実行は開始されず、後の実行でスケジュールの欠落としてカウントされます。
2。 concurrencyPolicyをForbidに設定している場合、すでに実行されているcronjobがスケジュールされている場合、K8はそれを失敗としてカウントしますか?
はい、それは見逃されたスケジュールとしてカウントされます。上記のポイント2で述べたように、見逃したスケジュールが計算されるためです。