【メモ】CronJobについてざっくり概要を見ていった

業務で今VMのCronで動いているあるバッチをKubernetesのCronJobに移せないか検証するため、まずはCronJobについてざっくり概要を学んでいきたいと思います。

構築時に気をつけておきたい設定などをメモしていきます。

Kubernetesドキュメント

cronジョブは一度のスケジュール実行につき、 おおよそ 1つのジョブオブジェクトを作成します。ここで おおよそ と言っているのは、ある状況下では2つのジョブが作成される、もしくは1つも作成されない場合があるためです。通常、このようなことが起こらないようになっていますが、完全に防ぐことはできません。したがって、ジョブは 冪等 であるべきです。

まずは、移行対象のジョブが冪等であるか確認した方が良さそう。

Google Kubernetes Engineドキュメント

concurrencyPolicyがForbidに設定されている場合、前回のスケジュールがまだ実行中にCronJobをスケジュールしようとすると、CronJobは作成されません。

同時実行ポリシーは、Allow, Forbid, Replace何が適切なのかは構築前に検証した方がよいですね。

Kubernetes道場 14日目 - Job / CronJobについて

Jobが失敗して再起動処理を無限に続けないように、 backoffLimit というフィールドで制限回数を設けることが出来る。デフォルトは6回となっている。Podが失敗してbackoffする際に指数関数的に遅延を入れてから再度実行される。 Podが失敗してbackoffする際に指数関数的に遅延を入れてから再度実行される。

リトライどうするか設計もしなくては。

メルカリのエンジニアブログ Kubernetes CronJobと仲良くなりたい

failedJobsHistoryLimitは失敗終了したJobを指します。Jobが残るということはPodも残るので、特に失敗したJobからPodを特定しログを見ることで失敗原因を掴むことができます。

failedJobsHistoryLimitはデフォルト1のようですが、失敗原因を調べるのに情報が多い方が良いと思うので、増やしておいても良いかも。

100回スケジュールされる時間が経つと、CronJobはJobを生成できなくなるためCronJobの再作成が必要になります。

これは注意ですね。 動いていることを検知する仕組みがないと、動かないまま放置されてしまいそう。

ざっくり見て行ったので、次回は実際に手元で動かしてきます。