kubernetes「The life of a pod」

この文書は、kubernetesユーザーズガイドの「The life of a pod」の和訳（参照した原文は release-1.0版）で、一部意訳や不正確な部分が含まれているかもしれません。kubernetesは Apache License v2.0で提供されています。

2015/4/14更新

このドキュメントはpodのライフサイクルについて解説している。これは網羅的なドキュメントではなく、このトピックへの紹介文である。

podのフェーズ

API規約全体と一貫するため、フェーズはpodのライフサイクルの推移のハイレベルのシンプルなサマリーになっている。これはコンテナレベルやpodレベルの状態の観察結果を体系的にとりまとめたり、その他の状態を表すことを意図したものではないし、包括的なステートマシンを意図してもいない。

PodPhase の値の数と意味は厳格に保護されている。ここで説明されていること以外は、podについて何らかの PodPhase も仮定すべきではない。

Pending: podはシステムに受け入れられているが、1つ以上のコンテナイメージが作成されていない。これには、スケジュールされるまでの時間を含むほか、イメージをネットワーク越しにダウンロードしてくる時間も含まれ、これがある程度時間がかかることがある。
Running: podはnodeへの割り当てが完了していて、すべてのコンテナが作成されている。少なくとも1つのコンテナが動作を継続しているか、起動もしくは再起動の途上にある。
Succeeded: pod内のすべてのコンテナが正常に終了し、再起動はしない。
Failed: pod内の全てのコンテナが終了済みで、少なくとも1つのコンテナが異常終了している（ゼロ以外のexitステータスで終了したか、システムによって終了された）。

Podの状態

readiness調査を指定しているコンテナを含んでいるpodはReady状態もレポートする。状態ステータスは、 True , False , Unknown のいずれかをとる。

コンテナのProbe

Probeはコンテナ上のkubeletによって定期実行される診断である。具体的には診断には3つの Handlersのうちの1つを指定する：

ExecAction : 指定コマンドをコンテナ内で実行し、そのコマンドがステータスコード0で終了することで成功と期待する
TCPSocketAction : コンテナのIPアドレスの指定ポートにtcpチェックを実施し、ポートがオープンであることで成功と期待する
HTTPGetAction : コンテナのIPアドレスの指定ポートとパスに対してHTTP Getを実行し、レスポンスに200以上400未満のステータスコードがあることで成功と期待する

各probeは3つの結果のうち1つをとる

Success : コンテナは診断を通過したことを示す
Failure : コンテナは診断に失敗したことを示す
Unknown : 診断できなかったため何もアクションすべきでないことを示す

現状、kubeletは実行中のコンテナにオプションで以下の2つの独立した診断を実施し、アクションのトリガーとなる。

LivenessProbe : コンテナがlive、つまり動作を継続しているかどうかを示す。LivenessProbeは、コンテナが不健康な状態になった場合のヒントをkubeletに出している。LivenessProbeが失敗したとき、kubeletはコンテナをkillしそのコンテナはそれ自身の RestartPolicyに従う。最初の遅延が起きるまでのLivenessのデフォルト状態は Success である。probeが提供されていないときのコンテナのLiveness状態は Success と仮定されている。
ReadinessProbe : コンテナがserviceリクエストを受けられる状態かどうかを示す。ReadinessProbeが失敗したとき、エンドポイントのコントローラーはそのpodにマッチするすべてのserviceのエンドポイントからpodのIPアドレスを取り除く。このためReadinessProbeは、podが動作しているかもしれないもののプロキシからトラフィックを受け取るべきではないシグナルをエンドポイントのコントローラーに送るために便利なことがある（例：コンテナがリスニング開始まで長いスタートアップ時間がかかる場合やコンテナをメンテナンスのためにダウンする場合）。最初の遅延が起きるまでのReadinessのデフォルト状態は Failure である。probeが提供されていないときのコンテナのReadiness状態は Success と仮定されている。

コンテナの状態

現状（と過去）のコンテナステータスのより詳細な情報は ContainerStatusesで見つかるかもしれない。レポートされる情報は現状の ContainerStateに依存していて、Waiting, Running, Terminatedのいずれかである。

RestartPolicy

RestartPolicyにとりうる値には、 Always , OnFailure , Never がある。RestartPolicyがセットされていない場合、デフォルト値は Always になる。RestartPolicyはpod内のすべてのコンテナに適用される。RestartPolicyは、同一node上のKubeletがコンテナを再起動するためにのみ参照される。 podのドキュメントで議論したとおり、ひとたびnodeに割り当てられるとpodは他のnodeに再割り当てされることは決してない。このため、podがnodeの障害を切り抜けるためにはある種のコントローラーが必須ということになり、それは一時にひとつのpodしか必要ない場合でさえ同様である。

現状、利用できる唯一のコントローラーは ReplicationControllerである。 ReplicationController は RestartPolicy = Always のpodにのみ適している。 ReplicationController は異なるrestart policyのいかなるpod作成も拒否すべきである。

その他のポリシーでpod群を維持するようなコントローラーへのもっともなニーズはある。他のいずれかのポリシー（ OnFailure または Never ）を持つpodが終了した際、コントローラーは再生成を止めるべきである。この基礎的な違いのため、このポリシーを実装できる新たなコントローラーを仮定し、このドキュメントでは JobControllerと呼ぶことにしよう。

podのライフタイム

一般的に、作成されたpod群は誰かが削除するまで消滅することはない。削除は人の手による場合もあるし、 ReplicationController による場合もある。このルールの唯一の例外は、 PodPhase が Succeeded または Failed のまま一定期間を過ぎた（マスターが判定する）podが有効期限切れになり自動的に回収されるケースである。

nodeが死んだり残りのクラスターから切断された場合、システム内の何らかの機能（ここではNodeControllerと呼ぶことにする）がポリシー（例：タイムアウト）を適用し、失われたnodeのpodを Failed としてマークする役割を持つ。

実例

Podが Running、1コンテナでコンテナが正常終了
- 完了イベントをログ記録する
- RestartPolicyが
  - Alwaysなら: コンテナを再起動、podは Running を維持
  - OnFailureなら: podは Succeeded に
  - Neverなら: podは Succeeded に
Podが Running、1コンテナでコンテナが異常終了
- 障害イベントをログ記録する
- RestartPolicyが
  - Alwaysなら: コンテナを再起動、podは Running を維持
  - OnFailureなら: コンテナを再起動、podは Running を維持
  - Neverなら: podは Failed に
Podが Running、2コンテナでコンテナ1が異常終了
- 障害イベントをログ記録する
- RestartPolicyが
  - Alwaysなら: コンテナを再起動、podは Running を維持
  - OnFailureなら: コンテナを再起動、podは Running を維持
  - Neverなら: podは Running を維持
- コンテナ2が終了したら…
  - 障害イベントをログ記録する
  - RestartPolicyが
    - Alwaysなら: コンテナを再起動、podは Running を維持
    - OnFailureなら: コンテナを再起動、podは Running を維持
    - Neverなら: podは Failed に
Podが Running、コンテナがOOMになった（訳注 OOM：Out of Memory。物理メモリを使い果たした状態）
- コンテナを障害として終了させる
- OOMイベントをログ記録する
- RestartPolicyが
  - Alwaysなら: コンテナを再起動、podは Running を維持
  - OnFailureなら: コンテナを再起動、podは Running を維持
  - Neverなら: 障害イベントをログ記録し、podは Failes に
Podが Running、ディスクが死んだ
- すべてのコンテナをkill
- 対応するイベントをログ記録する
- podは Failed に
- コントローラー下で動作している場合、podは別環境で再作成される
Podが Running、動作nodeがセグメントアウト
- NodeControllerはタイムアウト待ちする
- NodeControllerがpodにFailedをマークする
- コントローラー下で動作している場合、podは別環境で再作成される