第6章 CronJob [batch/v1]


説明
CronJob は、単一の cron ジョブの設定を表します。
タイプ
object

6.1. 仕様

プロパティータイプ説明

apiVersion

string

APIVersion はオブジェクトのこの表現のバージョンスキーマを定義します。サーバーは認識されたスキーマを最新の内部値に変換し、認識されない値は拒否することがあります。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources を参照してください。

kind

string

kind はこのオブジェクトが表す REST リソースを表す文字列の値です。サーバーはクライアントが要求を送信するエンドポイントからこれを推測できることがあります。これを更新することはできません。CamelCase を使用します。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds を参照してください。

metadata

ObjectMeta

標準オブジェクトのメタデータ。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata を参照してください。

spec

object

CronJobSpec は、ジョブの実行がどのようになり、実際にいつ実行されるかを記述します。

status

object

CronJobStatus は、cron ジョブの現在の状態を表します。

6.1.1. .spec

説明
CronJobSpec は、ジョブの実行がどのようになり、実際にいつ実行されるかを記述します。
タイプ
object
必須
  • スケジュール
  • jobTemplate
プロパティータイプ説明

concurrencyPolicy

string

ジョブの同時実行を処理する方法を指定します。有効な値は以下のとおりです。

- "Allow" (デフォルト):CronJobs の同時実行を許可します。- "Forbid": 同時実行を禁止し、前の実行がまだ終了していない場合は次の実行をスキップします。- "Replace": 現在実行中のジョブをキャンセルし、新しいジョブに置き換えます。

有効な列挙値: "Allow" は CronJob の同時実行を許可します。 - "Forbid" は同時実行を禁止し、前の実行が終了していない場合は次の実行をスキップします。- "Replace" は同時実行をキャンセルし、新しいジョブに置き換えます。

failedJobsHistoryLimit

integer

保持する失敗した終了ジョブの数。値は負の値ではない整数にする必要があります。デフォルトは 1 です。

jobTemplate

object

JobTemplateSpec は、テンプレートから作成されたときにジョブが持つべきデータを記述します

スケジュール

string

Cron 形式のスケジュールについては、https://en.wikipedia.org/wiki/Cron を参照してください。

startingDeadlineSeconds

integer

ジョブを開始するためのオプションの期限 (秒単位)(何らかの理由によりスケジュールされた時間が経過する場合)。ジョブの実行が行われない場合、ジョブの失敗としてカウントされます。

successfulJobsHistoryLimit

integer

保持する成功した終了済みジョブの数。値は負の値ではない整数にする必要があります。デフォルトは 3 です。

suspend

boolean

このフラグは、後続の実行を一時停止するようにコントローラーに指示します。すでに開始されている実行には適用されません。デフォルトは false です。

timeZone

string

指定されたスケジュールのタイムゾーン名については、https://en.wikipedia.org/wiki/List_of_tz_database_time_zones を参照してください。指定しない場合、デフォルトで kube-controller-manager プロセスのタイムゾーンが使用されます。有効なタイムゾーン名とタイムゾーンオフセットのセットは、CronJob の検証中および実行時にコントローラーマネージャーによって、システム全体のタイムゾーンデータベースから読み込まれます。システム全体のタイムゾーンデータベースが見つからない場合は、代わりにバンドル化されたバージョンのデータベースが使用されます。CronJob の有効期間中またはホスト設定の変更によってタイムゾーン名が無効になると、コントローラーは新しいジョブの作成を停止し、理由が UnknownTimeZone のシステムイベントを作成します。詳細は、https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#time-zones を参照してください。

6.1.2. .spec.jobTemplate

説明
JobTemplateSpec は、テンプレートから作成されたときにジョブが持つべきデータを記述します
タイプ
object
プロパティータイプ説明

metadata

ObjectMeta

このテンプレートから作成されたジョブの標準オブジェクトのメタデータ。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata を参照してください。

spec

object

JobSpec は、ジョブの実行がどのようになるかを記述します。

6.1.3. .spec.jobTemplate.spec

説明
JobSpec は、ジョブの実行がどのようになるかを記述します。
タイプ
object
必須
  • template
プロパティータイプ説明

activeDeadlineSeconds

integer

システムがジョブを終了しようとする前に、ジョブが継続的にアクティブになる可能性がある startTime を基準とした秒単位の期間を指定します。値は正の整数でなければなりません。ジョブが (作成時または更新中に) 一時停止になった場合、このタイマーは事実上停止となり、ジョブが再開したときにリセットされます。

backoffLimit

integer

このジョブを失敗とマークするまでの再試行回数を指定します。デフォルトは 6 です。

backoffLimitPerIndex

integer

このインデックスを失敗としてマークするまでの、インデックス内における再試行回数の制限を指定します。有効にすると、インデックスごとの失敗回数が Pod の batch.kubernetes.io/job-index-failure-count アノテーションに保持されます。これは、ジョブの completionMode=Indexed で、Pod の再起動ポリシーが Never の場合にのみ設定できます。このフィールドはイミュータブルです。このフィールドは、ベータレベルですJobBackoffLimitPerIndex フィーチャーゲートが有効になっている場合に使用できます (デフォルトで有効)。

completionMode

string

completionMode は、Pod の完了を追跡する方法を指定します。NonIndexed (デフォルト) または Indexed にすることができます。

NonIndexed は、.spec.completions が正常に完了した Pod がある場合に、ジョブが完了したと見なされることを意味します。各 Pod の完了は、互いに対応します。

Indexed とは、Job の Pod が 0 から (.spec.completions - 1) までの関連する完了インデックスを取得することを意味します。これはアノテーション batch.kubernetes.io/job-completion-index で利用できます。インデックスごとに正常に完了した Pod が 1 つあると、ジョブは完了したと見なされます。値が Indexed の場合は、.spec.completions を指定する必要があり、.spec.parallelism は 10^5 以下である必要があります。さらに、Pod 名は $(job-name)-$(index)-$(random-string) の形式を取り、Pod ホスト名は $(job-name)-$(index) の形式を取ります。

今後、さらに多くの完了モードを追加できます。ジョブコントローラーが認識できないモードを確認した場合、コントローラーはジョブの更新をスキップします。

可能な列挙値: "Indexed" はジョブ完了モードです。このモードでは、ジョブの Pod は関連する完了インデックスを 0 から (.spec.completions - 1) 取得します。ジョブは、完了インデックスごとに Pod が完了すると完了したと見なされます。"NonIndexed" はジョブ完了モードです。このモードでは、.spec.completions が正常に完了した Pod がある場合に、ジョブは完了したと見なされます。Pod の完了は相互に関係しています。

completions

integer

ジョブを実行するために正常に終了した Pod の希望数を指定します。null に設定すると、任意の Pod の成功がすべての Pod の成功を示し、並列処理に正の値を設定できるようになります。1 に設定すると、並列処理が 1 に制限され、その Pod の成功がジョブの成功を示します。詳細: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

managedBy

string

ManagedBy フィールドは、ジョブを管理するコントローラーを示します。k8s ジョブコントローラーは、このフィールドを持たないジョブ、またはフィールド値が予約文字列 kubernetes.io/job-controller のジョブを調整しますが、このフィールドにカスタム値を持つジョブの調整はスキップします。値は、接頭辞としてドメインが付加された有効なパス (例: acme.io/foo) である必要があります。最初の "/" より前にあるすべての文字は、RFC 1123 で定義されている有効なサブドメインである必要があります。最初の "/" より後のすべての文字は、RFC 3986 で定義されている有効な HTTP パスの文字である必要があります。この値の文字数は 64 文字を超えてはなりません。

このフィールドはアルファレベルです。フィーチャーゲート JobManagedBy が有効な場合 (デフォルトでは無効)、ジョブコントローラーはこのフィールドの設定を受け入れます。

manualSelector

boolean

manualSelector は、Pod ラベルと Pod セレクターの生成を制御します。何をしているのかわからない場合は、manualSelector を未設定のままにします。false または設定解除されると、システムはこのジョブに固有のラベルを選択し、そのラベルを Pod テンプレートに追加します。true の場合、ユーザーは一意のラベルを選択してセレクターを指定する必要があります。一意のラベルを選択しないと、このジョブや他のジョブが正しく機能しなくなる可能性があります。ただし、古い extensions/v1beta1 API で作成されたジョブに manualSelector=true が表示される場合があります。詳細: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#specifying-your-own-pod-selector

maxFailedIndexes

integer

backoffLimitPerIndex が設定されている場合、ジョブを失敗としてマークするまでの失敗したインデックスの最大数を指定します。失敗したインデックスの数がこの数を超えると、ジョブ全体が Failed としてマークされ、実行が終了します。null のままにすると、ジョブはすべてのインデックスの実行を続行し、ジョブ状態は Complete でマークされます。backoffLimitPerIndex が設定されている場合にのみ指定できます。null または完了まで可能です。これは必須であり、完了が 10^5 より大きい場合は 10^4 以下でなければなりません。このフィールドは、ベータレベルですJobBackoffLimitPerIndex フィーチャーゲートが有効になっている場合に使用できます (デフォルトで有効)。

parallelism

integer

ジョブが任意の時点で実行する必要のある Pod の最大数を指定します。定常状態で実行している Pod の実際の数は、((.spec.completions - .status.successful) < .spec.parallelism) の場合、つまり、実行する必要のある作業が最大並列処理より少ない場合は、この数より少なくなります。詳細: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

podFailurePolicy

object

PodFailurePolicy は、失敗した Pod が backoffLimit にどのように影響するかを説明します。

podReplacementPolicy

string

podReplacementPolicy は、代替 Pod をいつ作成するか指定します。可能な値は次のとおりです。- TerminatingOrFailed : Pod が終了中 (metadata.deletionTimestamp がある) または失敗したときに Pod が再作成されます。- Failed: 以前に作成された Pod が完全に終了する (フェーズが Failed または Succeeded になる) まで待機してから代替 Pod を作成します。

podFailurePolicy を使用する場合、許可される値は Failed のみです。podFailurePolicy が使用されていない場合、許可される値は TerminatingOrFailed と Failed です。これはベータフィールドです。これを使用するには、JobPodReplacementPolicy 機能のトグルを有効にします。これはデフォルトでオンに設定されます。

可能な列挙値: - "Failed" の場合、以前に作成された Pod が完全に終了する (フェーズが Failed または Succeeded になる) まで待機してから、代替 Pod を作成します。- "TerminatingOrFailed" の場合、Pod が終了中 (metadata.deletionTimestamp がある) または失敗したときに Pod を再作成します。

selector

LabelSelector

Pod 数と一致する必要がある Pod に対するラベルクエリー。通常、システムはこのフィールドを設定します。詳細: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors

successPolicy

object

SuccessPolicy は、いくつかのインデックスの成功に基づきジョブの成功を宣言できるタイミングを説明します。

suspend

boolean

suspend は、Job コントローラーが Pod を作成するかどうかを指定します。suspend を true に設定して Job を作成すると、ジョブコントローラーは Pod を作成しません。作成後に Job が一時停止した場合 (つまり、フラグが false から true になる場合)、Job コントローラーはこの Job に関連付けられているすべてのアクティブな Pod を削除します。ユーザーは、これを適切に処理するようにワークロードを設計する必要があります。ジョブを一時停止すると、ジョブの StartTime フィールドがリセットされ、ActiveDeadlineSeconds タイマーも効果的にリセットされます。デフォルトは false です。

template

PodTemplateSpec

ジョブの実行時に作成される Pod を説明します。使用できる template.spec.restartPolicy の値は "Never" または "OnFailure" のみです。詳細: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

ttlSecondsAfterFinished

integer

ttlSecondsAfterFinished は、実行が終了した (Complete または Failed のいずれか) Job の存続期間を制限します。このフィールドが設定されている場合、Job の終了後に ttlSecondsAfterFinished を設定すると、自動的に削除される可能性があります。ジョブが削除されると、そのライフサイクル保証 (ファイナライザーなど) が尊重されます。このフィールドが設定されていないと、ジョブが自動的に削除されません。このフィールドがゼロに設定されていると、ジョブは終了後すぐに削除できるようになります。

6.1.4. .spec.jobTemplate.spec.podFailurePolicy

説明
PodFailurePolicy は、失敗した Pod が backoffLimit にどのように影響するかを説明します。
タイプ
object
必須
  • rules
プロパティータイプ説明

rules

array

Pod 障害ポリシールールの一覧。ルールは順番に評価されます。ルールが Pod の障害に一致すると、残りのルールは無視されます。Pod の障害に一致するルールがない場合は、デフォルトの処理が適用されます。つまり、Pod の失敗のカウンターが増分され、backoffLimit に対してチェックされます。最大 20 個の要素が許可されます。

rules[]

object

PodFailurePolicyRule は、要件が満たされた場合に Pod の障害がどのように処理されるかを記述します。各ルールでは、onExitCodes と onPodConditions のいずれか 1 つを使用できますが、両方は使用できません。

6.1.5. .spec.jobTemplate.spec.podFailurePolicy.rules

説明
Pod 障害ポリシールールの一覧。ルールは順番に評価されます。ルールが Pod の障害に一致すると、残りのルールは無視されます。Pod の障害に一致するルールがない場合は、デフォルトの処理が適用されます。つまり、Pod の失敗のカウンターが増分され、backoffLimit に対してチェックされます。最大 20 個の要素が許可されます。
タイプ
array

6.1.6. .spec.jobTemplate.spec.podFailurePolicy.rules[]

説明
PodFailurePolicyRule は、要件が満たされた場合に Pod の障害がどのように処理されるかを記述します。各ルールでは、onExitCodes と onPodConditions のいずれか 1 つを使用できますが、両方は使用できません。
タイプ
object
必須
  • action
プロパティータイプ説明

action

string

要件が満たされた場合に Pod の障害に対して実行されるアクションを指定します。可能な値は次のとおりです。

- FailJob: Pod のジョブが Failed としてマークされ、実行中のすべての Pod が終了したことを示します。- FailIndex: Pod のインデックスが Failed としてマークされ、再起動されないことを示します。この値はベータレベルです。これは、JobBackoffLimitPerIndex フィーチャーゲートが有効になっている場合 (デフォルトで有効) に使用できます。- Ignore: .backoffLimit に対するカウンターがインクリメントされず、代替 Pod が作成されることを示します。- Count: Pod がデフォルトの方法で処理されることを示します。- .backoffLimit までカウンターがインクリメントされます。その他の値は、今後追加される予定です。クライアントはルールを省略して、不明なアクションに対応する必要があります。

可能な列挙値: - "Count" は、Pod 障害時に実行される可能性のあるアクションです。- Pod 障害はデフォルトの方法で処理されます。- ジョブの .status.failed フィールドで表される .backoffLimit へのカウンターが増加します。- "FailIndex" は、Pod 障害時に実行される可能性のあるアクションです。- このインデックス内での再起動を回避するために、ジョブのインデックスを失敗としてマークします。このアクションは、backoffLimitPerIndex が設定されている場合にのみ使用できます。この値はベータレベルです。- "FailJob" は、Pod の障害時に実行される可能性のあるアクションです。- Pod のジョブを Failed としてマークし、実行中のすべての Pod を終了します。- "Ignore" は、Pod 障害時に実行される可能性のあるアクションです。- ジョブの .status.failed フィールドで表される .backoffLimit へのカウンターは増加せず、代替 Pod が作成されます。

onExitCodes

object

PodFailurePolicyOnExitCodesRequirement は、コンテナー終了コードに基づいて失敗した Pod を処理するための要件を説明します。特に、各アプリケーションコンテナーの .state.termination.exitCode と init コンテナーのステータスを検索します。これは、Pod ステータスの .status.containerStatuses フィールドと .status.initContainerStatuses フィールドをそれぞれ検索します。正常に完了したコンテナー (終了コード 0) は、要件チェックから除外されます。

onPodConditions

array

Pod の条件に関する要件を表します。要件は Pod 条件パターンのリストとして表されます。少なくとも 1 つのパターンが実際の Pod の状態と一致する場合、要件は満たされます。最大 20 個の要素が許可されます。

onPodConditions[]

object

PodFailurePolicyOnPodConditionsPattern は、実際の Pod 条件タイプと一致するパターンを記述します。

6.1.7. .spec.jobTemplate.spec.podFailurePolicy.rules[].onExitCodes

説明
PodFailurePolicyOnExitCodesRequirement は、コンテナー終了コードに基づいて失敗した Pod を処理するための要件を説明します。特に、各アプリケーションコンテナーの .state.termination.exitCode と init コンテナーのステータスを検索します。これは、Pod ステータスの .status.containerStatuses フィールドと .status.initContainerStatuses フィールドをそれぞれ検索します。正常に完了したコンテナー (終了コード 0) は、要件チェックから除外されます。
タイプ
object
必須
  • operator
  • values
プロパティータイプ説明

containerName

string

終了コードのチェックを指定された名前のコンテナーに制限します。null の場合、ルールはすべてのコンテナーに適用されます。指定する場合、Pod テンプレート内のコンテナー名または initContainer 名のいずれかと一致する必要があります。

operator

string

コンテナー終了コードと指定された値の関係を表します。正常に完了したコンテナー (終了コード 0) は、要件チェックから除外されます。可能な値は次のとおりです。

- In: 少なくとも 1 つのコンテナーの終了コードが指定の値のセット内にある場合、要件は満たされます ('containerName' フィールドからの制限がないコンテナーが複数ある場合は、複数の終了コードが存在する可能性があります)。 - NotIn: 少なくとも 1 つのコンテナーの終了コードが指定の値のセット内にない場合、要件は満たされます ('containerName' フィールドからの制限がないコンテナーが複数ある場合は、複数の終了コードが存在する可能性があります)。その他の値は、今後追加される予定です。クライアントは、要件が満たされていないことを前提として、不明な演算子に対応する必要があります。

使用可能な列挙値: - "In" - "NotIn"

values

配列 (整数)

値のセットを指定します。返された各コンテナー終了コードは、この値のセットに対して、演算子に関するチェックを行います (複数のコンテナーがある場合は複数存在する可能性があります)。値のリストは順序付けする必要があり、重複を含めることはできません。値 '0' は、In 演算子に使用できません。少なくとも 1 つの要素が必要です。最大 255 個の要素が許可されます。

6.1.8. .spec.jobTemplate.spec.podFailurePolicy.rules[].onPodConditions

説明
Pod の条件に関する要件を表します。要件は Pod 条件パターンのリストとして表されます。少なくとも 1 つのパターンが実際の Pod の状態と一致する場合、要件は満たされます。最大 20 個の要素が許可されます。
タイプ
array

6.1.9. .spec.jobTemplate.spec.podFailurePolicy.rules[].onPodConditions[]

説明
PodFailurePolicyOnPodConditionsPattern は、実際の Pod 条件タイプと一致するパターンを記述します。
タイプ
object
必須
  • type
  • status
プロパティータイプ説明

status

string

必要な Pod の条件ステータスを指定します。Pod 条件と一致するには、指定されたステータスが Pod 条件ステータスと等しい必要があります。デフォルトは True です。

type

string

必要な Pod 条件タイプを指定します。Pod 条件と一致するには、指定されたタイプが Pod 条件タイプと等しい必要があります。

6.1.10. .spec.jobTemplate.spec.successPolicy

説明
SuccessPolicy は、いくつかのインデックスの成功に基づきジョブの成功を宣言できるタイミングを説明します。
タイプ
object
必須
  • rules
プロパティータイプ説明

rules

array

rules は、.status.succeeded >= .spec.completions になる前にジョブを成功として宣言するための代替ルールのリストを表します。いずれかのルールが満たされると、"SucceededCriteriaMet" 条件が追加され、残っている Pod が削除されます。このようなジョブの最終的な状態には "Complete" 条件があります。さらに、これらのルールは順番に評価され、ジョブがいずれかのルールを満たすと、他のルールは無視されます。最大 20 個の要素が許可されます。

rules[]

object

SuccessPolicyRule は、ジョブを成功として宣言するためのルールを記述します。各ルールには、"succeededIndexes" または "succeededCount" のいずれか 1 つを必ず指定する必要があります。

6.1.11. .spec.jobTemplate.spec.successPolicy.rules

説明
rules は、.status.succeeded >= .spec.completions になる前にジョブを成功として宣言するための代替ルールのリストを表します。いずれかのルールが満たされると、"SucceededCriteriaMet" 条件が追加され、残っている Pod が削除されます。このようなジョブの最終的な状態には "Complete" 条件があります。さらに、これらのルールは順番に評価され、ジョブがいずれかのルールを満たすと、他のルールは無視されます。最大 20 個の要素が許可されます。
タイプ
array

6.1.12. .spec.jobTemplate.spec.successPolicy.rules[]

説明
SuccessPolicyRule は、ジョブを成功として宣言するためのルールを記述します。各ルールには、"succeededIndexes" または "succeededCount" のいずれか 1 つを必ず指定する必要があります。
タイプ
object
プロパティータイプ説明

succeededCount

integer

succeededCount は、ジョブの成功したインデックスの実際のセットの最小必要サイズを指定します。succeededCount を succeededIndexes と併せて使用すると、チェックは succeededIndexes で指定されたインデックスのセットにのみ制限されます。たとえば、succeededIndexes が "1-4"、succeededCount が "3"、完了したインデックスが "1"、"3"、"5" の場合、ルールでは "1" と "3" のインデックスのみが考慮されるため、ジョブは成功として宣言されません。このフィールドが null の場合、デフォルトの値は設定されず、評価されることはありません。指定する場合は、正の整数で指定する必要があります。

succeededIndexes

string

succeededIndexes は、ジョブの成功したインデックスの実際のセットに含める必要があるインデックスのセットを指定します。インデックスのリストは 0 から ".spec.completions-1" の範囲内とし、重複を含んではなりません。少なくとも 1 つの要素が必要です。インデックスは、コンマで区切られた間隔として表されます。間隔には、10 進整数、またはハイフンで区切られた 10 進整数のペアを使用できます。この場合の番号は、連続する番号の最初と最後をハイフンで区切って表します。たとえば、完了したインデックスが 1、3、4、5、7 の場合は、"1,3-5,7" で表現されます。このフィールドが null の場合、このフィールドのデフォルト値は設定されず、評価されることはありません。

6.1.13. .status

説明
CronJobStatus は、cron ジョブの現在の状態を表します。
タイプ
object
プロパティータイプ説明

active

array (ObjectReference)

現在実行中のジョブへのポインターのリスト。

lastScheduleTime

Time

この Job が最後に正常にスケジュールされた時刻情報。

lastSuccessfulTime

Time

この Job が最後に正常に完了した時刻情報。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.