Workload API > Operate running Workloads > ライフサイクルの状態

ライフサイクルの状態¶

ワークロードのライフサイクルとは、作成から破棄までに遷移する状態のセットと、各遷移をトリガーする要素のことです。プラットフォームは、ワークロードのProtonをバックアップするKubernetes Podから状態を導き出します。

プラットフォームは2つのレベルで状態を追跡します。ProtonStatusは、各ProtonをバックアップするKubernetes Podから計算された完全なランタイムビューです。WorkloadStatusは、ワークロード自体に表示されるユーザー向けの部分セットであり、ワークロードレベルのAPIが報告することのない内部Protonのライフサイクルの状態（initializing、warming、draining、restarting）を省略します。

結合された状態テーブルでは、表示場所列を使用して、各値がどこに表示されるかを示しています。

状態	Surfaces on	説明
`unknown`	ワークロード + Proton	状態はまだ報告されていません。プラットフォームはまだスナップショットを生成していません。
`submitted`	ワークロード + Proton	APIによって受け入れられましたが、まだスケジュールされていません。Podは`Pending`（保留中）で、ノードは割り当てられていません。
`initializing`	Protonのみ	下位互換性を確保するため、レガシー状態が維持されます。新しいProtonでは、代わりに`provisioning`が使用されます。ワークロードは、これを隣接するワークロードレベルの状態（`launching`または`running`）にまとめます。
`provisioning`	ワークロード + Proton	クラスターリソース（リソースバンドルのスケジューリング、PVCの作成、シークレットの注入）が割り当てられています。Podはノードが割り当てられた`Pending`（保留中）状態です。
`launching`	ワークロード + Proton	イメージの取得とコンテナの起動が進行中、またはコンテナは起動していますが、Readiness Probeをまだ通過していません。Podは`Running`（実行中）ですが、コンテナは準備できていません。
`running`	ワークロード + Proton	正常で、リクエストを処理しています。Podは`Running`（実行中）で、すべてのコンテナが準備完了しています。
`suspended`	ワークロード + Proton	意図的に一時停止されています。Podは停止されますが、ワークロードのIDと設定は保持されます。`start`を実行すると、これらが復元されます。
`warming`	Protonのみ	置換時のウォームアップウィンドウで実行されています。候補のProtonから反映されます。
`draining`	Protonのみ	アクティブですが、トラフィックを受信しなくなりました。置換時の古いProtonです。
`interrupted`	Protonのみ	ランタイムがプリエンプトされました（ノードのエビクション、スポットの回収、またはスケジューラ主導の置換）。プラットフォームは、容量が空くと自動的に再スケジュールします。ワークロードレベルでは、`interrupted`は`stopped`に対応します。
`restarting`	Protonのみ	Podの再起動が必要な設定変更後、ProtonのIDを保持したままProtonがインプレースで再作成されています。ワークロードレベルのステータスは、隣接する可視状態のままです。
`stopping`	ワークロード + Proton	グレースフルシャットダウンが進行中です。Podは終了処理中です。
`stopped`	ワークロード + Proton	停止しています。再起動できます。Podが存在しないか、完了まで実行するアーティファクトのPodフェーズが`Succeeded`（成功）です。
`errored`	ワークロード + Proton	失敗しました。`CrashLoopBackOff`、`ImagePullBackOff`、またはPodフェーズが`Failed`（失敗）です。
`terminated`	ワークロード + Proton	永久に破棄されました。ワークロードが削除され、Protonは存在しなくなりました。

プラットフォームは、Pod状態の述語を優先順位に従って評価してProtonStatusを導き出します。その後、Protonのみの状態をまとめることでWorkloadStatusが導き出されます。

一般的な遷移¶

次の表に、作成、更新、置換、停止、失敗、および昇格操作の一般的な状態シーケンスを示します。このシーケンスは、完全な遷移パスを示すためにProtonレベルで記述されています。ワークロードレベルでは、Protonのみの状態（initializing、warming、draining、restarting）は隣接するワークロードで可視の状態にまとめられます。

操作	遷移
作成	`submitted -> provisioning -> launching -> running`
更新	`running -> initializing -> running`
置換	`running -> running(active) + initializing/warming/running(candidate) -> switch -> draining(active) + running(new active) -> running(single active)`
停止	`running -> stopping -> stopped`
一時停止 (Suspend)	`running -> suspended`
失敗	`launching \| running -> errored`
昇格	`running (draft) -> running (locked)` (再起動なし)

Podベースの真実¶

プラットフォームは、優先順位に従ってPodの述語からワークロードのステータスを計算します。

複数レプリカのワークロードの場合、ワースト状態優先（worst-state-wins）の集計が適用されます。
サイドカーは、コンテナの準備完了（readiness）と失敗の評価に影響します。
初期化（Init）コンテナのステータスは述語には影響しません。これらは起動に影響を与えますが、ワークロードレベルのerroredを直接トリガーすることはありません。

`errored`が継続する理由¶

いずれかのコンテナがCrashLoopBackOffになると、ワークロードはerroredを報告し、問題のあるPodが置き換えられるか、失敗したコンテナが再び成功し始めるまでrunningには戻りません。また、すべてのコンテナのReadiness Probeを通過するまで、ワークロードはlaunchingのままになります。readinessProbe.pathのタイプミスや、準備が完了しないサイドカーがあると、プライマリーコンテナが起動していてもワークロードはrunningに到達しません。

CrashLoopBackOffは、ワークロードまたはProtonのstatusフィールドに名前付き文字列として表示されません。ステータスは、これ以上の詳細情報なしにerroredと表示されます。クラッシュループを確認するには、Protonに対してstatusDetailsを呼び出します。restartCount > 0かつstatus: "waiting"であるコンテナは、クラッシュループが発生していることを示しています。

エラーになったワークロードのデバッグ¶

ProtonのstatusDetailsには、失敗したコンテナ名とその理由が含まれます。 /eventsエンドポイントは、DataRobotのライフサイクル遷移（状態変化、置換、昇格など）を記録しており、タイムラインの再構築に役立ちます。このエンドポイントは、クラッシュ再起動やイメージ取得の失敗など、KubernetesのPodレベルのイベントは転送しません。それらのイベントについては、Protonに対するstatusDetailsが主要な診断情報源となります。ログは、アプリケーションレベルのコンテキストを提供します。

ワークロードのどこで問題が発生したかを特定するために、ライフサイクルイベントとProtonごとのステータスを取得するには：

# Lifecycle events: what changed and when
curl -s "${DATAROBOT_ENDPOINT}/workloads/${WORKLOAD_ID}/events" \
  -H "Authorization: Bearer ${DATAROBOT_API_TOKEN}"

# Per-proton status
curl -s "${DATAROBOT_ENDPOINT}/workloads/${WORKLOAD_ID}/protons" \
  -H "Authorization: Bearer ${DATAROBOT_API_TOKEN}" | jq '.data[] | {id, role, status}'

Proton：ランタイムのバッキングと集約¶

Protonは、ワークロードの背後にあるランタイムプリミティブ、つまり実際に実行されているコンテナインスタンスです。ワークロードは管理されるIDであり、Protonは実行です。

オブジェクト階層¶

ワークロードには常に少なくとも1つのProtonがあります。置換中は一時的に2つ（古いものと新しいもの）のProtonを持つことがあり、ワークロードのトラフィックルーティングがどのProtonがリクエストを受け取るかを決定します。

Protonは1つ以上のKubernetesポッドで構成されます：

シングルレプリカのワークロードは1つのポッドにマッピングされます。
マルチレプリカのワークロードはレプリカごとに1つのポッドにマッピングされます。

ワークロードは安定したアドレスとガバナンスのラッパーです。Protonはそのアドレスの背後でアーティファクトを実行するランタイムバッキングです。

Protonのステータスの計算方法¶

プラットフォームは、述語を優先順位に従って使用し、ポッドのステートを集約することによってProtonのステータスを計算します。

マルチレプリカのProtonの場合、最悪のステートが優先される（worst-state-wins）集約が適用されます。

述語は優先順位に従って評価され、最も優先順位の高い一致が優先されます。

ポッドの条件	Protonのステート	ワークロードのステート	優先度
`CrashLoopBackOff`のコンテナがある	`errored`	`errored`	7 (最高)
`ImagePullBackOff`のコンテナがある	`errored`	`errored`	7
ポッドのフェーズ `Failed`	`errored`	`errored`	6
ポッドのフェーズ `Succeeded`	`stopped`	`stopped`	5
ポッドのフェーズ `Pending` (まだノードがない)	`submitted`	`submitted`	4
ポッドのフェーズ `Pending` (ノードにスケジュール済み)	`provisioning`	`provisioning`	4
ポッドのフェーズ `Running`、すべてのコンテナが準備完了ではない	`launching`	`launching`	3
ポッドのフェーズ `Running`、すべてのコンテナが準備完了	`running`	`running`	2
ノードのエビクションが進行中	`interrupted`	`stopped`	—
ユーザーが発行したサスペンド	`suspended`	`suspended`	—
設定変更後に再作成されたProton	`restarting`	(Protonのみ。ワークロードのステートは変更なし)	—
ポッドが存在しない	`stopped` (シャットダウン時) または `errored` (予期しないエラー)	同じ	—

述語は、サイドカーを含む各ポッドのすべてのコンテナを検査します。サイドカーのイメージURIが間違っている場合、プライマリーコンテナが正常であっても、Protonはerroredを報告します。Initコンテナのステータスは述語によって評価されません。これらは起動に影響しますが、直接erroredをトリガーすることはありません。

マルチコンテナの例¶

シナリオ	ポッドのフェーズ	コンテナのステート	ワークロードのステート
アプリとサイドカーが両方とも正常	実行中	アプリ準備完了、サイドカー準備完了	`running`
アプリ実行中、サイドカーが`ImagePullBackOff`	実行中	アプリ準備完了、サイドカー`ImagePullBackOff`	`errored`
アプリが`CrashLoopBackOff`	実行中	アプリ`CrashLoopBackOff`	`errored`
アプリ起動中、サイドカー実行中	実行中	アプリ`ContainerCreating`、サイドカー準備完了	`launching`
ポッドスケジュール済み、コンテナ待機中	保留中	両方とも`Waiting` (ノード割り当て済み)	`provisioning`
ポッド保留中、まだノードがない	保留中	両方とも`Waiting` (ノードなし)	`submitted`

Protonの検査¶

ほとんどのユーザーはワークロードを通じて操作します。Protonのエンドポイントは、ランタイムのステートを検査したり、置換操作中に候補をテストしたりするのに役立ちます。

ワークロードをバックアップしているProtonを一覧表示して、アクティブなインスタンスと候補のインスタンスを確認するには：

# List protons for a workload
curl -s "${DATAROBOT_ENDPOINT}/workloads/${WORKLOAD_ID}/protons" \
  -H "Authorization: Bearer ${DATAROBOT_API_TOKEN}" | jq '.'

APIで使用可能なProtonのエンドポイントの完全なセットを確認するには：

GET /workloads/{workload_id}/protons
GET /workloads/{workload_id}/protons/{proton_id}
GET /workloads/{workload_id}/protons/{proton_id}/statusDetails

OpenTelemetryのトレース、ログ、および指標は、プラットフォームの可観測性サーフェスの /api/v2/otel/workload/{workload_id}/{logs,metrics,traces} で公開されます（単数形の workload、Proton IDではなくワークロードIDがキーになります）。ワークロードAPI自体は /otel/* ルートを公開しません。