5.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 の再起動ポリシー。

関連情報

5.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 つのジョブが作成される場合があります。そのためジョブはべき等である必要があり、履歴制限を設定する必要があります。

5.2.1.1. ジョブの作成方法

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

  • OpenShift Container Platform が作成する Pod を記述している Pod テンプレート。
  • parallelism パラメーター。ジョブの実行に使用する、同時に実行される Pod の数を指定します。

    • 非並列ジョブの場合は、未設定のままにします。未設定の場合は、デフォルトの 1 に設定されます。
  • completions パラメーター。ジョブを完了するために必要な、正常に完了した Pod の数を指定します。

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

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

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

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

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

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

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

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

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

  • .spec.successfulJobsHistoryLimit。保持する成功した終了済みジョブの数 (デフォルトは 3 に設定)。
  • .spec.failedJobsHistoryLimit。保持する失敗した終了済みジョブの数 (デフォルトは 1 に設定)。
ヒント
  • 必要なくなった cron ジョブを削除します。

    $ oc delete cronjob/<cron_job_name>

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

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

5.2.1.5. 既知の制限

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

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

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

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

5.2.2. ジョブの作成

ジョブオブジェクトを作成して OpenShift Container Platform にジョブを作成します。

手順

ジョブを作成するには、以下を実行します。

  1. 以下のような YAML ファイルを作成します。

    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 レプリカの数を指定します。デフォルトは 1 です。
    • 非並列ジョブの場合は、未設定のままにします。未設定の場合は、デフォルトの 1 に設定されます。
    2
    オプション: ジョブの完了をマークするために必要な Pod の正常な完了の数を指定します。
    • 非並列ジョブの場合は、未設定のままにします。未設定の場合は、デフォルトの 1 に設定されます。
    • 固定の完了数を持つ並列ジョブの場合、完了の数を指定します。
    • ワークキューのある並列ジョブでは、未設定のままにします。未設定の場合、デフォルトは parallelism 値に設定されます。
    3
    オプション: ジョブを実行できる最大期間を指定します。
    4
    オプション: ジョブの再試行回数を指定します。このフィールドは、デフォルトでは 6 に設定されています。
    5
    コントローラーが作成する Pod のテンプレートを指定します。
    6
    Pod の再起動ポリシーを指定します。
    • Never.ジョブを再起動しません。
    • OnFailure.ジョブが失敗した場合にのみ再起動します。
    • Alwaysジョブを常に再起動します。

      OpenShift Container Platform が失敗したコンテナーに再起動ポリシーを使用する方法の詳細は、Kubernetes ドキュメントの State の例 を参照してください。

  2. ジョブを作成します。

    $ oc create -f <file-name>.yaml
注記

oc create job を使用して単一コマンドからジョブを作成し、起動することもできます。以下のコマンドは直前の例に指定されている同じジョブを作成し、これを起動します。

$ oc create job pi --image=perl -- perl -Mbignum=bpi -wle 'print bpi(2000)'

5.2.3. cron ジョブの作成

ジョブオブジェクトを作成して OpenShift Container Platform に cron ジョブを作成します。

手順

cron ジョブを作成するには、以下を実行します。

  1. 以下のような YAML ファイルを作成します。

    apiVersion: batch/v1
    kind: CronJob
    metadata:
      name: pi
    spec:
      schedule: "*/1 * * * *"          1
      timeZone: Etc/UTC                2
      concurrencyPolicy: "Replace"     3
      startingDeadlineSeconds: 200     4
      suspend: true                    5
      successfulJobsHistoryLimit: 3    6
      failedJobsHistoryLimit: 1        7
      jobTemplate:                     8
        spec:
          template:
            metadata:
              labels:                  9
                parent: "cronjobpi"
            spec:
              containers:
              - name: pi
                image: perl
                command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
              restartPolicy: OnFailure 10
    #...
    1
    cron 形式 で指定されたジョブのスケジュール。この例では、ジョブは毎分実行されます。
    2
    スケジュールのオプションのタイムゾーン。有効なオプションは、tz データベースのタイムゾーンのリスト を参照してください。指定しない場合、Kubernetes コントローラーマネージャーは、ローカルタイムゾーンを基準にしてスケジュールを解釈します。
    3
    オプションの同時実行ポリシー。cron ジョブ内での同時実行ジョブを処理する方法を指定します。以下の同時実行ポリシーの 1 つのみを指定できます。これが指定されない場合、同時実行を許可するようにデフォルト設定されます。
    • Allow: cron ジョブを同時に実行できます。
    • Forbid: 同時実行を禁止し、直前の実行が終了していない場合は次の実行を省略します。
    • Replace: 同時に実行されているジョブを取り消し、これを新規ジョブに置き換えます。
    4
    ジョブを開始するためのオプションの期限 (秒単位)(何らかの理由によりスケジュールされた時間が経過する場合)。ジョブの実行が行われない場合、ジョブの失敗としてカウントされます。これが指定されない場合は期間が設定されません。
    5
    cron ジョブの停止を許可するオプションのフラグ。これが true に設定されている場合、後続のすべての実行が停止されます。
    6
    保持する成功した終了済みジョブの数 (デフォルトは 3 に設定)。
    7
    保持する失敗した終了済みジョブの数 (デフォルトは 1 に設定)。
    8
    ジョブテンプレート。これはジョブの例と同様です。
    9
    この cron ジョブで生成されるジョブのラベルを設定します。
    10
    Pod の再起動ポリシー。ジョブコントローラーには適用されません。
  2. cron ジョブを作成します。

    $ oc create -f <file-name>.yaml
注記

oc create cronjob を使用して単一コマンドから cron ジョブを作成し、起動することもできます。以下のコマンドは直前の例で指定されている同じ cron ジョブを作成し、これを起動します。

$ oc create cronjob pi --image=perl --schedule='*/1 * * * *' -- perl -Mbignum=bpi -wle 'print bpi(2000)'

oc create cronjob で、--schedule オプションは cron 形式 のスケジュールを受け入れます。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.