4.2. ジョブの使用による Pod でのタスクの実行

job は、OpenShift Container Platform クラスターのタスクを実行します。

ジョブは、タスクの全体的な進捗状況を追跡し、進行中、完了、および失敗した各 Pod の情報を使ってその状態を更新します。ジョブを削除するとそのジョブによって作成された Pod のレプリカがクリーンアップされます。ジョブは Kubernetes API の一部で、他のオブジェクトタイプ同様に oc コマンドで管理できます。

ジョブ仕様のサンプル

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  parallelism: 1    1
  completions: 1    2
  activeDeadlineSeconds: 1800 3
  backoffLimit: 6   4
  template:         5
    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: OnFailure    6

1
ジョブの Pod レプリカは並行して実行される必要があります。
2
ジョブの完了をマークするには、Pod の正常な完了が必要です。
3
ジョブを実行できる最長期間。
4
ジョブの再試行回数。
5
コントローラーが作成する Pod のテンプレート。
6
Pod の再起動ポリシー。

ジョブについての詳細は、Kubernetes のドキュメント を参照してください。

4.2.1. ジョブと Cron ジョブについて

ジョブは、タスクの全体的な進捗状況を追跡し、進行中、完了、および失敗した各 Pod の情報を使ってその状態を更新します。ジョブを削除するとそのジョブによって作成された Pod がクリーンアップされます。ジョブは Kubernetes API の一部で、他のオブジェクトタイプ同様に oc コマンドで管理できます。

OpenShift Container Platform で一度だけ実行するオブジェクトを作成できるリソースタイプは 2 種類あります。

ジョブ
定期的なジョブは、タスクを作成しジョブが完了したことを確認する、一度だけ実行するオブジェクトです。

ジョブとして実行するには、主に以下のタスクタイプを使用できます。

  • 非並列ジョブ:

    • Pod が失敗しない限り、単一の Pod のみを起動するジョブ。
    • このジョブは、Pod が正常に終了するとすぐに完了します。

  • 固定の完了数が指定された並列ジョブ

    • 複数の Pod を起動するジョブ。
    • ジョブはタスク全体を表し、1 から completions 値までの範囲内のそれぞれの値に対して 1 つの正常な Pod がある場合に完了します。

  • ワークキューを含む並列ジョブ:

    • 指定された Pod に複数の並列ワーカープロセスを持つジョブ。
    • OpenShift Container Platform は Pod を調整し、それぞれの機能を判別するか、または外部キューサービスを使用します。
    • 各 Pod はそれぞれ、すべてのピア Pod が完了しているかどうかや、ジョブ全体が実行済みであることを判別することができます。
    • ジョブからの Pod が正常な状態で終了すると、新規 Pod は作成されません。
    • 1 つ以上の Pod が正常な状態で終了し、すべての Pod が終了している場合、ジョブが正常に完了します。
    • Pod が正常な状態で終了した場合、それ以外の Pod がこのタスクについて機能したり、または出力を書き込むことはありません。Pod はすべて終了プロセスにあるはずです。

各種のジョブを使用する方法についての詳細は、Kubernetes ドキュメントの Job Patterns を参照してください。

Cron ジョブ
ジョブは、Cron ジョブを使って複数回実行するようにスケジュールすることが可能です。

cron ジョブ は、ユーザーがジョブの実行方法を指定することを可能にすることで、定期的なジョブを積み重ねます。Cron ジョブは Kubernetes API の一部であり、他のオブジェクトタイプと同様に oc コマンドで管理できます。

Cron ジョブは、バックアップの実行やメールの送信など周期的な繰り返しのタスクを作成する際に役立ちます。また、低アクティビティー期間にジョブをスケジュールする場合など、特定の時間に個別のタスクをスケジュールすることも可能です。cron ジョブは、cronjob コントローラーを実行するコントロールプレーンノードに設定されたタイムゾーンに基づいて Job オブジェクトを作成します。

警告

Cron ジョブはスケジュールの実行時間ごとに約 1 回ずつ Job オブジェクトを作成しますが、ジョブの作成に失敗したり、2 つのジョブが作成される場合があります。そのためジョブはべき等である必要があり、履歴制限を設定する必要があります。

4.2.1.1. ジョブの作成方法

どちらのリソースタイプにも、以下の主要な要素から設定されるジョブ設定が必要です。

  • OpenShift Container Platform が作成する Pod を記述している Pod テンプレート。

  • parallelism パラメーター。ジョブの実行に使用する、同時に実行される Pod の数を指定します。

    • 非並列ジョブの場合は、未設定のままにします。未設定の場合は、デフォルトの 1 に設定されます。

  • completions パラメーター。ジョブを完了するために必要な、正常に完了した Pod の数を指定します。

    • 非並列ジョブの場合は、未設定のままにします。未設定の場合は、デフォルトの 1 に設定されます。
    • 固定の完了数を持つ並列ジョブの場合は、値を指定します。
    • ワークキューのある並列ジョブでは、未設定のままにします。未設定の場合、デフォルトは parallelism 値に設定されます。

4.2.1.2. ジョブの最長期間を設定する方法

ジョブの定義時に、activeDeadlineSeconds フィールドを設定して最長期間を定義できます。これは秒単位で指定され、デフォルトでは設定されません。設定されていない場合は、実施される最長期間はありません。

最長期間は、最初の Pod がスケジュールされた時点から計算され、ジョブが有効である期間を定義します。これは実行の全体の時間を追跡します。指定されたタイムアウトに達すると、OpenShift Container Platform がジョブを終了します。

4.2.1.3. 失敗した Pod のためのジョブのバックオフポリシーを設定する方法

ジョブは、設定の論理的なエラーなどの理由により再試行の設定回数を超えた後に失敗とみなされる場合があります。ジョブに関連付けられた失敗した Pod は 6 分を上限として指数関数的バックオフ遅延値 (10s、20s、40s …) に基づいて再作成されます。この制限は、コントローラーのチェック間で失敗した Pod が新たに生じない場合に再設定されます。

ジョブの再試行回数を設定するには spec.backoffLimit パラメーターを使用します。

4.2.1.4. アーティファクトを削除するように Cron ジョブを設定する方法

Cron ジョブはジョブや Pod などのアーティファクトリーソースをそのままにすることがあります。ユーザーは履歴制限を設定して古いジョブとそれらの Pod が適切に消去されるようにすることが重要です。これに対応する 2 つのフィールドが Cron ジョブ仕様にあります。

  • .spec.successfulJobsHistoryLimit.保持する成功した終了済みジョブの数 (デフォルトは 3 に設定)。
  • .spec.successfulJobsHistoryLimit。保持する失敗した終了済みジョブの数 (デフォルトは 1 に設定)。
ヒント

  • 必要なくなった Cron ジョブを削除します。 

    $ oc delete cronjob/<cron_job_name>

    これを実行することで、不要なアーティファクトの生成を防げます。

  • spec.suspend を true に設定することで、その後の実行を中断することができます。その後のすべての実行は、false に再設定するまで中断されます。

4.2.1.5. 既知の制限

ジョブ仕様の再起動ポリシーは Pod にのみ適用され、ジョブコントローラー には適用されません。ただし、ジョブコントローラーはジョブを完了まで再試行するようハードコーディングされます。

そのため restartPolicy: Never または --restart=Never により、restartPolicy: OnFailure または --restart=OnFailure と同じ動作が実行されます。つまり、ジョブが失敗すると、成功するまで (または手動で破棄されるまで) 自動で再起動します。このポリシーは再起動するサブシステムのみを設定します。

Never ポリシーでは、ジョブコントローラー が再起動を実行します。それぞれの再試行時に、ジョブコントローラーはジョブステータスの失敗数を増分し、新規 Pod を作成します。これは、それぞれの試行が失敗するたびに Pod の数が増えることを意味します。

OnFailure ポリシーでは、kubelet が再起動を実行します。それぞれの試行によりジョブステータスでの失敗数が増分する訳ではありません。さらに、kubelet は同じノードで Pod の起動に失敗したジョブを再試行します。