# ライフサイクルの状態

> ライフサイクルの状態 - ワークロードの状態、Podベースの計算、Proton、デバッグ。

This Markdown file sits beside the HTML page at the same path (with a `.md` suffix). It summarizes the topic and lists links for tools and LLM context.

Companion generated at `2026-09-02T14:28:12.977873+00:00` (UTC).

## Primary page

- [ライフサイクルの状態](https://docs.datarobot.com/ja/docs/workload-api/operate-workloads/lifecycle-states.html.md): Full documentation for this topic (Markdown sidecar).

## Sections on this page

- [一般的な遷移](https://docs.datarobot.com/ja/docs/workload-api/operate-workloads/lifecycle-states.html.md#transitions): In-page section heading.
- [Podベースの真実](https://docs.datarobot.com/ja/docs/workload-api/operate-workloads/lifecycle-states.html.md#pod-based-truth): In-page section heading.
- [erroredが継続する理由](https://docs.datarobot.com/ja/docs/workload-api/operate-workloads/lifecycle-states.html.md#why-errored-sticky): In-page section heading.
- [エラーになったワークロードのデバッグ](https://docs.datarobot.com/ja/docs/workload-api/operate-workloads/lifecycle-states.html.md#debug-an-errored-workload): In-page section heading.
- [Proton：ランタイムのバッキングと集約](https://docs.datarobot.com/ja/docs/workload-api/operate-workloads/lifecycle-states.html.md#protons-lifecycle): In-page section heading.
- [オブジェクト階層](https://docs.datarobot.com/ja/docs/workload-api/operate-workloads/lifecycle-states.html.md#proton-object-hierarchy): In-page section heading.
- [Protonのステータスの計算方法](https://docs.datarobot.com/ja/docs/workload-api/operate-workloads/lifecycle-states.html.md#proton-status-computation): In-page section heading.
- [マルチコンテナの例](https://docs.datarobot.com/ja/docs/workload-api/operate-workloads/lifecycle-states.html.md#multi-container-examples): In-page section heading.
- [Protonの検査](https://docs.datarobot.com/ja/docs/workload-api/operate-workloads/lifecycle-states.html.md#inspect-protons): In-page section heading.

## Documentation content

ワークロードのライフサイクルとは、作成から破棄までに遷移する状態のセットと、各遷移をトリガーする要素のことです。プラットフォームは、ワークロードの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/*` ルートを公開しません。