Pod Condition

Kubernetesでは、多くのオブジェクトに Condition があります。 Conditionは、オブジェクトが表す対象の実際の状態の一部を示すマーカーです。 PodにもConditionがあり、KubernetesのPodのConditionは、コントローラー(やトラブルシューティングを行う人)がPodの健全性を理解するための重要な要素です。

Podのフェーズは、Podがライフサイクル上のどこに位置するかを大まかにまとめたものですが、単一の値ですべてを表現することはできません。 例えば、PodがRunningフェーズにあっても、まだトラフィックを処理する準備が整っていない場合があります。 PodのConditionは、Podがスケジュールされたかどうか、コンテナが準備完了かどうか、リサイズが進行中かどうか、taintによってPodが中断されようとしているかなど、Podの状態の複数の側面を独立して追跡することでフェーズを補完します。

Pod Conditionの構造

Podのステータスには、Podが特定のチェックポイントを通過したかどうかを示すPodConditionの配列が含まれています。

PodCondition配列の各要素には、以下のフィールドがあります:

ビルトインのPod Condition

Kubernetesは以下のPod Conditionを管理します:

ライフサイクル上のCondition: Podがライフサイクルを進む過程で、おおよそPodScheduled、PodReadyToStartContainers、Initialized、ContainersReady、Readyの順に設定されます。

その他のCondition: 特定の操作やイベントに応じて、DisruptionTarget、PodResizePending、PodResizeInProgressが設定されます。

上記のビルトインのConditionに加えて、PodのReadinessゲートを使用してカスタムのConditionを定義することもできます。

ライフサイクル上のPod Condition

Podがライフサイクルを進むにつれて、kubeletは以下のConditionをおおよそ次の順序で設定します:

1. PodScheduled: Podがノードにスケジュールされたことを示します。
2. PodReadyToStartContainers: Podのサンドボックスが正常に作成され、ネットワークが構成されたことを示します。 サンドボックスとネットワークは、コンテナランタイムとCNIプラグインによってセットアップされます。
3. Initialized: すべてのInitコンテナが正常に完了したことを示します。 Initコンテナを持たないPodでは、サンドボックスの作成前にTrueに設定されます。
4. ContainersReady: Pod内のすべてのコンテナが準備完了であることを示します。 コンテナのReadinessは、設定されている場合はReadiness Probeによって判定されます。
5. Ready: Podがリクエストを処理でき、一致するすべてのServiceの負荷分散プールに追加されるべきであることを示します。 ReadyでないPodはServiceのエンドポイントから削除されます。

kubectlを使用してPodのConditionを確認できます:

kubectl get pod <pod-name> -o yaml

実行中のPodのstatus.conditionsは次のようになります:

status:
  conditions:
    - type: PodScheduled
      status: "True"
      lastProbeTime: null
      lastTransitionTime: "2026-03-29T08:52:21Z"
      observedGeneration: 1
    - type: PodReadyToStartContainers
      status: "True"
      lastProbeTime: null
      lastTransitionTime: "2026-04-11T06:02:16Z"
      observedGeneration: 1
    - type: Initialized
      status: "True"
      lastProbeTime: null
      lastTransitionTime: "2026-03-29T08:52:21Z"
      observedGeneration: 1
    - type: ContainersReady
      status: "True"
      lastProbeTime: null
      lastTransitionTime: "2026-04-11T06:02:45Z"
      observedGeneration: 1
    - type: Ready
      status: "True"
      lastProbeTime: null
      lastTransitionTime: "2026-04-11T06:02:45Z"
      observedGeneration: 1

PodReadyToStartContainers

Podがノードにスケジュールされた後、kubeletに受け入れられ、必要なストレージボリュームがマウントされる必要があります。 これらのフェーズが完了すると、kubeletは(Container Runtime Interface (CRI)を使用して)コンテナランタイムと連携し、ランタイムサンドボックスをセットアップしてPodのネットワークを構成します。 PodReadyToStartContainersConditionフィーチャーゲートが有効な場合(Kubernetes 1.36ではデフォルトで有効)、PodReadyToStartContainers ConditionがPodのstatus.conditionsフィールドに追加されます。

PodReadyToStartContainers Conditionは、Podにネットワーク構成済みのランタイムサンドボックスがないことをkubeletが検出すると、Falseに設定されます。 これは以下のシナリオで発生します:

• Podのライフサイクルの初期で、kubeletがコンテナランタイムを使用してPodのサンドボックスのセットアップをまだ開始していないとき。
• Podのライフサイクルの後期で、Podのサンドボックスが以下のいずれかの原因で破棄されたとき:
  • Podが退避させられずに、ノードが再起動した。
  • 隔離に仮想マシンを使用するコンテナランタイムにおいて、Podサンドボックスの仮想マシンが再起動し、新しいサンドボックスと新しいコンテナネットワーク設定の作成が必要になった。

ランタイムプラグインによるPodのサンドボックスの作成とネットワーク構成が正常に完了すると、kubeletはPodReadyToStartContainers ConditionをTrueに設定します。 PodReadyToStartContainers ConditionがTrueに設定された後、kubeletはコンテナイメージの取得とコンテナの作成を開始できます。

Initコンテナを持つPodでは、kubeletはInitコンテナが正常に完了した後(これはランタイムプラグインによるサンドボックスの作成とネットワーク構成が成功した後に発生します)、Initialized ConditionをTrueに設定します。 Initコンテナを持たないPodでは、kubeletはサンドボックスの作成とネットワーク構成が開始する前に、Initialized ConditionをTrueに設定します。

その他のPod Condition

以下のConditionは、通常のPodのライフサイクルの進行には含まれません。 これらは特定の操作やイベントに応じて設定されます。

DisruptionTarget

DisruptionによりPodが削除されようとしていることを示すために、専用のPod DisruptionTarget Conditionが追加されます。 このConditionのreasonフィールドは、Podの終了理由として以下のいずれかを示します:

PreemptionByScheduler

より高い優先度を持つ新しいPodを受け入れるために、スケジューラーによってPodがプリエンプトされようとしています。 詳細はPodの優先度とプリエンプションを参照してください。

DeletionByTaintManager

Podが許容しないNoExecuteのtaintにより、Taint Manager(kube-controller-manager内のノードライフサイクルコントローラーの一部)によってPodが削除されようとしています。 taintベースの退避を参照してください。

EvictionByEvictionAPI

PodがKubernetes APIを使用した退避の対象としてマークされました。

DeletionByPodGC

既に存在しないノードにバインドされているPodが、Podのガベージコレクションによって削除されようとしています。

TerminationByKubelet

ノードの圧迫による退避、ノードのグレースフルシャットダウン、またはシステムにとってクリティカルなPodのためのプリエンプションのいずれかにより、Podがkubeletによって終了されました。

Podのコンテナの制限を超過したことによる退避のようなその他すべてのDisruptionシナリオでは、Disruptionの原因がPod自体にある可能性が高く、リトライしても再発するため、PodはDisruptionTarget Conditionを受け取りません。

Podのガベージコレクター(PodGC)は、Podをクリーンアップするとともに、Podが非終了フェーズにある場合はそれらをfailedとしてマークします(Podのガベージコレクションも参照してください)。

Job(またはCronJob)を使用する場合、これらのPodのDisruptionのConditionを、JobのPod失敗ポリシーの一部として活用したい場合があります。

詳細については、Disruptionを参照してください。

PodResizePendingとPodResizeInProgress

kubeletは、リサイズリクエストの状態を示すために、PodのステータスのConditionを更新します:

• type: PodResizePending: kubeletはリクエストをすぐには許可できません。 messageフィールドにその理由が記載されます。
  • reason: Infeasible: 要求されたリサイズは現在のノード上では実行不可能です(例えば、ノードが持つリソースより多くを要求した場合)。
  • reason: Deferred: 要求されたリサイズは現時点では不可能ですが、後で実現可能になる可能性があります(例えば、他のPodが削除された場合)。 kubeletはリサイズを再試行します。
• type: PodResizeInProgress: kubeletはリサイズを受け入れてリソースを割り当てましたが、変更はまだ適用中です。 通常は短時間で完了しますが、リソースの種類やランタイムの挙動によってはさらに時間がかかる場合があります。 実行中に発生したエラーは、messageフィールドに(reason: Errorとともに)報告されます。

要求されたリサイズが Deferred となった場合、kubeletは、例えば他のPodが削除されたりスケールダウンされたりしたときなどに、定期的にリサイズを再試行します。

Podのリサイズの詳細については、コンテナに割り当てられたCPUおよびメモリリソースのリサイズを参照してください。

Enhanced Pod readiness

アプリケーションは、Podの.statusに追加のフィードバックやシグナルを注入できます。 これは Enhanced Pod readiness と呼ばれます。 これを使用するには、PodのspecでreadinessGatesを設定し、kubeletがPodのReadinessを評価する際に確認する追加のConditionのリストを指定します。 そして、これらのカスタムConditionを管理するコントローラーを実装またはインストールすると、kubeletはそれをPodがreadyかどうかを判断するための追加情報として使用します。

ReadinessゲートはPodのstatus.conditionフィールドの現在の状態によって決まります。 Kubernetesがstatus.conditionsフィールド内に該当するConditionを見つけられない場合、そのConditionのステータスはデフォルトで"False"になります。

kind: Pod
...
spec:
  readinessGates:
    - conditionType: "www.example.com/feature-1"
status:
  conditions:
    - type: Ready                              # ビルトインのPodCondition
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
    - type: "www.example.com/feature-1"        # 追加のPodCondition
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
  containerStatuses:
    - containerID: docker://abcd...
      ready: true
...

追加するPodのConditionの名前は、Kubernetesのラベルキーのフォーマットに準拠している必要があります。

Pod Readinessのためのステータス

Podにこれらのstatus.conditionsを設定するには、アプリケーションやオペレーターは、Podのステータスサブリソースに対してPATCHアクションを使用する必要があります。 kubectl patchを--subresource=statusとともに使用するか、Kubernetesのクライアントライブラリを使用して、PodのReadinessのためにカスタムのPodのConditionを設定するコードを記述できます。

カスタムConditionを使用するPodは、以下の両方が当てはまる場合のみreadyと評価されます。

• Pod内のすべてのコンテナがreadyである。
• readinessGatesに指定されたすべてのConditionがTrueである。

PodのコンテナがReadyでも、カスタムConditionの少なくとも1つが欠落しているかFalseの場合、kubeletはPodのReady Conditionをreason: ReadinessGatesNotReadyとともにstatus: "False"に設定します。

次の項目

• Podのライフサイクルについて学ぶ。
• Disruptionについて学ぶ。
• コンテナのプローブと、それらがPodのReadinessにどう影響するかについて学ぶ。
• Podのリソースをインプレースでリサイズする方法を学ぶ。