Kubernetes のジョブと Cron ジョブ__HTMLTAG_66___
Kubernetes では、__HTMLTAG_68___Deployments および StatefulSets は継続的に実行されるワークロード向けに設計されており、常に一定数のポッドを維持しようとします。しかし、実際のタスクの多くは、データのバッチ処理、データベース移行の実行、ML モデルのトレーニング、大量の電子メールの送信など、永久に実行する必要はありません。ここで__HTMLTAG_72___ジョブと__HTMLTAG_74___Cronジョブが登場します。
1.仕事とは何ですか?バッチ ワークロードと実行から完了まで
Kubernetes の
A Job は、特定のタスクを完了することを目的として 1 つ以上のポッドを作成します。デプロイメントとは異なり、ジョブは正常に完了した数を追跡します。十分なポッドが完了すると、ジョブは完了したとみなされます。
重要なジョブ機能:
- 実行から完了まで: ポッドは実行を終了し、成功を意味するコード 0 で終了しました
- 自動再試行: ポッドが失敗した場合、ジョブは__HTMLTAG_93___backoffLimit に従って新しいポッドを自動的に作成します。
- 完了の追跡: ジョブは、必要な合計のうち何件が完了したかを把握します
- 並列性: 複数のポッドを並列実行してスループットを向上させる
簡単なジョブの例 — 円周率の計算:
コードブロック_0
注 restartPolicy: Never — ジョブでは、__HTMLTAG_110___Never または OnFailure のみを使用でき、使用されません常に.
2.ジョブ完了モード
Kubernetes は、さまざまなユースケースに適したジョブの 3 つの完了モードをサポートしています。
2.1 インデックスなし (デフォルト)
_ジョブは、十分な数の成功が完了すると完了します。ポッドには順序がありません。ポッドはすべて同じジョブを実行し、ジョブが成功するには十分な completions ポッドが必要です。
コードブロック_1
2.2 インデックス付きジョブ
インデックス付きジョブ は非常に強力な機能です。各ポッドは、環境変数 JOB_COMPLETION_INDEX を介して、0 から completions-1 までの一意のインデックスを受け取ります。これは__HTMLTAG_136___データ パーティショニング に最適です。各ポッドはデータの定義された部分を処理します。
コードブロック_2
Kubernetes は、変数 JOB_COMPLETION_INDEX を各ポッドに自動的に挿入します。ポッド 0 はパーティション 0 を処理し、ポッド 1 はパーティション 1 を処理します。 — ポッドが再起動しても重複することはありません。
2.3 作業キュー
ワーク キュー パターンでは、複数のポッドが 1 つのキュー (Redis、RabbitMQ、SQS) からタスクを取得します。キューが空になり、処理中のポッドがなくなると、ジョブは完了します。
コードブロック_3
3.ジョブパラメータの詳細
ジョブ パラメータを理解すると、各ユースケースに合わせて最適化するのに役立ちます:
- completions: 正常に完了する必要があるポッドの合計数。デフォルトは 1.
- 並列処理: 同時に実行されるポッドの最大数。デフォルトは 1.
- backoffLimit: ジョブが失敗とマークされるまでの再試行回数。デフォルトは 6.
- activeDeadlineSeconds: ジョブの実行が許可される最大時間 (秒)。超過 → ジョブは終了しました。
- ttlSecondsAfterFinished: 完了から N 秒後にジョブ (およびポッド) を削除します。
コードブロック_4
4.ポッド障害ポリシー (K8s 1.31 以降)
Kubernetes 1.31 以降、__HTMLTAG_176___ポッド障害ポリシー を使用すると、ポッドが失敗したときの詳細な動作を定義できます。再試行は常に推奨されるわけではありません。
コードブロック_5
__HTMLTAG_180___アクションは使用できます:
- FailJob: ジョブ全体を直ちに停止し、失敗としてマーク
- 無視: backoffLimit にはカウントされません。新しいポッドを作成
- Count: 通常どおり backoffLimit にカウントされます (デフォルトの動作)
5.ジョブ TTL — 自動クリーンアップ
ジョブとそのポッドは、クリーンアップ メカニズムなしで完了後も永久に存続します。 ttlSecondsAfterFinished を使用して、
コードブロック_6
既存のジョブにパッチを適用することもできます: kubectl patch job old-job -p '{"spec":{"ttlSecondsAfterFinished":0}}' — これにより、ジョブがすぐに削除されます。
6. CronJob — タスクのスケジュール
CronJob は、使い慣れた cron 構文を使用して、定期的なスケジュールでジョブを自動的に作成します。
コードブロック_7
6.1 CronJob タイムゾーンのサポート (GA K8s 1.27)
K8s 1.27 より前は、すべての CronJob はコントローラーの UTC を使用していました。 K8s 1.27 以降、__HTMLTAG_216___timeZone フィールドが GA になりました。IANA タイムゾーン データベースに従って任意のタイムゾーンを指定できます:
コードブロック_8
人気のタイムゾーン:
アジア/ホーチミン— ベトナム (UTC+7)アジア/シンガポール— シンガポール (UTC+8)アメリカ/ニューヨーク— 米国東部ヨーロッパ/ロンドン— 英国UTC— 協定世界時
6.2 同時実行ポリシー
重要な決定事項: 新しいジョブの実行がスケジュールされているときに古いジョブが完了していない場合はどうすればよいですか?
- 許可 (デフォルト): 古いジョブが実行中であっても新しいジョブを作成します。競合状態に注意してください
- 禁止: 新しいジョブをスキップします。古いジョブは引き続き続行されます
- 置換: 古いジョブを削除し、置き換える新しいジョブを作成
7. JobSet — 分散ジョブ用の CNCF プロジェクト
JobSet は、複数の依存ジョブを調整するために設計された CNCF プロジェクト (現在サンドボックス段階にあります) です。これは、__HTMLTAG_266___分散 ML トレーニング パイプライン__HTMLTAG_267___.
に最適なツールです。ジョブセット設定:
___コードブロック_9___7.1 分散 ML トレーニング用のジョブセット
_シナリオ: パラメーター サーバー アーキテクチャを使用してモデルをトレーニングします。ポッドの 1 つのグループをパラメーター サーバー (勾配を保存) として、別のグループをワーカー (計算) として使用します。
コードブロック_10
7.2 JobSet の優れた機能__HTMLTAG_276___
- _障害ポリシーの伝播: セット内のジョブが失敗した場合、ジョブセット全体が再起動または一緒に失敗する可能性があります。「孤立した」ジョブはありません__HTMLTAG_281___
- DNS ベースの通信: JobSet 内のジョブには、相互に通信するための DNS レコードが自動的に設定されます (
{jobset-name}-{job-name}-{job-index}-{pod-index}.{jobset-name})
- _排他的トポロジ: 同じジョブのポッドが同じラック/ノード上でスケジュールされていることを確認します (ネットワーク遅延を削減します)
- 起動シーケンス__HTMLTAG_294___: PS の準備ができた後にのみワーカーを起動
7.3 ジョブセットの追跡
コードブロック_11
8。概要: いつ何を使用するか?
- SimpleJob: 1 つのタスクを 1 回実行 — 基本的なジョブを使用
- 順序なしの並列処理: 完了 + 並列処理のあるインデックスなしジョブ
- データのパーティショニング: インデックス付きジョブ — 各ポッドは指定されたパーティションを処理します
- キューベースの処理: ワークキュー ジョブ + Redis/RabbitMQ
- スケジュールされたタスク: タイムゾーンをサポートする CronJob
- 分散トレーニング/HPC: 複数ジョブ調整用のジョブセット
Jobs と CronJob は、Kubernetes 上のすべてのバッチ処理システムの基盤です。完了モードと失敗ポリシーを理解すると、特に AI/ML ワークロードの人気が高まっている中で、信頼性の高いパイプラインを構築するのに役立ちます。
{jobset-name}-{job-name}-{job-index}-{pod-index}.{jobset-name})