コンセプト

Kubernetes v1.15 のドキュメントは積極的にメンテナンスされていません。現在表示されているバージョンはスナップショットです。最新のドキュメントはこちらです: 最新バージョン

Edit This Page

Podのライフサイクル

このページではPodのライフサイクルについて説明します。

PodのPhase

Podのstatus項目はPodStatusオブジェクトで、それはphaseのフィールドがあります。

Podのフェーズは、そのPodがライフサイクルのどの状態にあるかを、簡単かつ高レベルにまとめたものです。 このフェーズはコンテナやPodの状態を包括的にまとめることを目的としたものではなく、また包括的なステートマシンでもありません。

Podの各フェーズの値と意味は厳重に守られています。 ここに記載されているもの以外にphaseの値は存在しないと思ってください。

これらがphaseの取りうる値です。

概要
Pending PodがKubernetesシステムによって承認されましたが、1つ以上のコンテナイメージが作成されていません。これには、スケジュールされるまでの時間と、ネットワーク経由でイメージをダウンロードするための時間などが含まれます。これには時間がかかることがあります。
Running PodがNodeにバインドされ、すべてのコンテナが作成されました。少なくとも1つのコンテナがまだ実行されているか、開始または再起動中です。
Succeeded Pod内のすべてのコンテナが正常に終了し、再起動されません。
Failed Pod内のすべてのコンテナが終了し、少なくとも1つのコンテナが異常終了しました。つまり、コンテナはゼロ以外のステータスで終了したか、システムによって終了されました。
Unknown 何らかの理由により、通常はPodのホストとの通信にエラーが発生したために、Podの状態を取得できませんでした。

Podのconditions

PodにはPodStatusがあります。それはPodが成功したかどうかの情報を持つPodConditionsの配列です。 PodCondition配列の各要素には、次の6つのフィールドがあります。

コンテナのProbe

Probekubelet により定期的に実行されるコンテナの診断です。 診断を行うために、kubeletはコンテナに実装された ハンドラーを呼びます。 Handlerには次の3つの種類があります:

各Probe 次の3つのうちの一つの結果を持ちます:

Kubeletは2種類のProbeを実行中のコンテナで行い、また反応することができます:

livenessProbeとreadinessProbeをいつ使うべきか?

コンテナ自体に問題が発生した場合や状態が悪くなった際にクラッシュすることができれば livenessProbeは不要です。この場合kubeletが自動でPodのrestartPolicyに基づいたアクションを実行します。

Probeに失敗したときにコンテナを殺したり再起動させたりするには、 livenessProbeを設定しrestartPolicyをAlwaysまたはOnFailureにします。

Probeが成功したときにのみPodにトラフィックを送信したい場合は、readinessProbeを指定します。 この場合readinessProbeはlivenessProbeと同じになる可能性がありますが、 readinessProbeが存在するということは、Podがトラフィックを受けずに開始され、Probe成功が開始した後でトラフィックを受け始めることになります。 コンテナが起動時に大きなデータ、構成ファイル、またはマイグレーションを読み込む必要がある場合は、readinessProbeを指定します。

コンテナがメンテナンスのために停止できるようにするには、 livenessProbeとは異なる、特定のエンドポイントを確認するreadinessProbeを指定することができます。

Podが削除されたときにリクエストを来ないようにするためには必ずしもreadinessProbeが必要というわけではありません。 Podの削除時にはreadinessProbeが存在するかどうかに関係なくPodは自動的に自身をunhealthyにします。 Pod内のコンテナが停止するのを待つ間Podはunhealthyのままです。

livenessProbeまたはreadinessProbeを設定する方法の詳細については、 Configure Liveness and Readiness Probesを参照してください

Podとコンテナのステータス

PodとContainerのステータスについての詳細の情報は、それぞれPodStatusContainerStatusを参照してください。 Podのステータスとして報告される情報は、現在のContainerStateに依存しています。

コンテナのステータス

PodがスケジューラによってNodeに割り当てられると、 kubeletはコンテナのランタイムを使用してコンテナの作成を開始します。 コンテナの状態はWaiting、RunningまたはTerminatedの3ついずれかです。 コンテナの状態を確認するにはkubectl describe pod [POD_NAME]のコマンドを使用します。 Pod内のコンテナごとにStateの項目として表示されます。

PodReadinessGate

FEATURE STATE: Kubernetes v1.14 stable
この機能は、現在 安定版 です。

  • バージョン名は、 vX (Xはバージョン番号を示す整数) という規則でつけられています。
  • 安定版となっている機能は、これ以降のバージョンにおいても長期にわたって利用可能です。

追加のフィードバックやシグナルをPodStatusに注入できるようにしてPodのReadinessに拡張性を持たせるため、 Kubernetes 1.11 ではPod ready++という機能が導入されました。 PodSpecの新しいフィールドReadinessGateを使用して、PodのRedinessを評価する追加の状態を指定できます。 KubernetesがPodのstatus.conditionsフィールドでそのような状態を発見できない場合、 ステータスはデフォルトで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のlabel key formatに準拠している必要があります。 kubectl patchコマンドはオブジェクトステータスのパッチ適用をまだサポートしていないので、 新しいPod ConditionはKubeClient librariesのどれかを使用する必要があります。

新しいPod Conditionが導入されるとPodは次の両方の条件に当てはまる場合のみ準備できていると評価されます:

PodのReadinessの評価へのこの変更を容易にするために、新しいPod ConditionであるContainersReadyが導入され、古いPodのReady条件を取得します。

K8s 1.1ではAlpha機能のため”Pod Ready++” 機能はPodReadinessGates feature gateにて明示的に指定する必要があります。

K8s 1.12ではこの機能はデフォルトで有効になっています。

RestartPolicy

PodSpecには、Always、OnFailure、またはNeverのいずれかの値を持つrestartPolicyフィールドがあります。 デフォルト値はAlwaysです。restartPolicyは、Pod内のすべてのコンテナに適用されます。 restartPolicyは、同じNode上のkubeletによるコンテナの再起動のみを参照します。 kubeletによって再起動される終了したコンテナは、5分後にキャップされた指数バックオフ遅延(10秒、20秒、40秒…)で再起動され、10分間の実行後にリセットされます。Pods documentに書かれているように、一度NodeにバインドされるとPodは別のポートにバインドされ直すことはありません。

Podのライフタイム

一般にPodは誰かが破棄するまで消えません。これは人間またはコントローラかもしれません。 このルールの唯一の例外は、一定の期間以上の(マスターでterminated-pod-gc-thresholdによって判断される)SucceededまたはFailedのphaseを持つPodは期限切れになり自動的に破棄されます。

次の3種類のコントローラがあります。

3種類のコントローラにはすべてPodTemplateが含まれます。 Podを自分で直接作成するのではなく適切なコントローラを作成してPodを作成させることをおすすめします。 これはPod単独ではマシンの障害に対して回復力がないためです。コントローラにはこの機能があります。

Nodeが停止したりクラスタの他のNodeから切断された場合、 Kubernetesは失われたノード上のすべてのPodのphaseをFailedに設定するためのポリシーを適用します。

高度なliveness probeの例

Liveness Probeはkubeletによって実行されるため、 すべてのリクエストはkubeletネットワークのnamespaceで行われます。

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - args:
    - /server
    image: k8s.gcr.io/liveness
    livenessProbe:
      httpGet:
        # "host" が定義されていない場合、"PodIP"が使用されます
        # host: my-host
        # "scheme"が定義されていない場合、HTTPスキームが使用されます。"HTTP"と"HTTPS"のみ
        # scheme: HTTPS
        path: /healthz
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 15
      timeoutSeconds: 1
    name: liveness

statesの例

次の項目

フィードバック