website/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md

title, content_template, weight

title	content_template	weight
Podのライフサイクル	templates/concept	30

{{% capture overview %}}

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

{{% /capture %}}

{{% capture body %}}

PodのPhase

Podのstatus項目は[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)オブジェクトで、それは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](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core)の配列です。 PodCondition配列の各要素には、次の6つのフィールドがあります。

• lastProbeTime は、Pod Conditionが最後に確認されたときのタイムスタンプが表示されます。

• lastTransitionTime は、最後にPodのステータスの遷移があった際のタイムスタンプが表示されます。

• message は、ステータスの遷移に関する詳細を示す人間向けのメッセージです。

• reason は、最後の状態遷移の理由を示す、一意のキャメルケースでの単語です。

• status はTrueとFalse、Unknownのうちのどれかです。

• type 次の値を取る文字列です。

  • PodScheduled: PodがNodeにスケジュールされました。
  • Ready: Podはリクエストを処理でき、一致するすべてのサービスの負荷分散プールに追加されます。
  • Initialized: すべてのinit containersが正常に実行されました。
  • Unschedulable: リソースの枯渇やその他の理由で、Podがスケジュールできない状態です。
  • ContainersReady: Pod内のすべてのコンテナが準備できた状態です。

コンテナのProbe

[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は kubelet により定期的に実行されるコンテナの診断です。 診断を行うために、kubeletはコンテナに実装された ハンドラーを呼びます。 Handlerには次の3つの種類があります:

• [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): コンテナ内で特定のコマンドを実行します。コマンドがステータス0で終了した場合に診断を成功と見まします。

• [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core): コンテナのIPの特定のポートにTCPチェックを行います。 そのポートが空いていれば診断を成功とみなします。

• [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core): コンテナのIPの特定のポートとパスに対して、HTTP GETのリクエストを送信します。 レスポンスのステータスコードが200以上400未満の際に診断を成功とみなします。

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

• Success: コンテナの診断が成功しました。
• Failure: コンテナの診断が失敗しました。
• Unknown: コンテナの診断が失敗し、取れるアクションがありません。

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

• livenessProbe: コンテナが動いているかを示します。 livenessProbe に失敗すると、kubeletはコンテナを殺します、そしてコンテナはrestart policyに従います。 コンテナにlivenessProbeが設定されていない場合、デフォルトの状態はSuccessです。

• readinessProbe: コンテナがServiceのリクエストを受けることができるかを示します。 readinessProbeに失敗すると、エンドポイントコントローラーにより、ServiceからそのPodのIPアドレスが削除されます。 initial delay前のデフォルトのreadinessProbeの初期値はFailureです。 コンテナにreadinessProbeが設定されていない場合、デフォルトの状態はSuccessです。

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のステータスについての詳細の情報は、それぞれ[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)と [ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)を参照してください。 Podのステータスとして報告される情報は、現在の[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)に依存しています。

コンテナのステータス

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

• Waiting: コンテナのデフォルトの状態。コンテナがRunningまたはTerminatedのいずれの状態でもない場合コンテナはWaitingの状態になります。Waiting状態のコンテナは引き続きイメージを取得したりSecretsを適用したりするなど必要な操作を実行します。この状態に加えてメッセージに関する情報と状態に関する理由が表示されます。

  ...
    State:          Waiting
     Reason:       ErrImagePull
  ...
  

• Running: コンテナが問題なく実行されていることを示します。コンテナがRunningに入るとpostStartフック（もしあれば）が実行されます。この状態にはコンテナが実行中状態に入った時刻も表示されます。

  ...
     State:          Running
      Started:      Wed, 30 Jan 2019 16:46:38 +0530
  ...
  

• Terminated: コンテナの実行が完了しコンテナの実行が停止したことを示します。コンテナは実行が正常に完了したときまたは何らかの理由で失敗したときにこの状態になります。いずれにせよ理由と終了コード、コンテナの開始時刻と終了時刻が表示されます。コンテナがTerminatedに入る前にpreStopフックがあればあれば実行されます。

  ...
     State:          Terminated
       Reason:       Completed
       Exit Code:    0
       Started:      Wed, 30 Jan 2019 11:45:26 +0530
       Finished:     Wed, 30 Jan 2019 11:45:26 +0530
   ...
  

PodReadinessGate

{{< feature-state for_k8s_version="v1.14" state="stable" >}}

追加のフィードバックやシグナルを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内のすべてのコンテナが準備完了している。
• ReadinessGatesで指定された条件が全てTrueである。

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は人間またはコントローラーが明示的に削除するまで存在します。 コントロールプレーンは終了状態のPod(SucceededまたはFailedのphaseを持つ)の数が設定された閾値（kube-controller-manager内のterminated-pod-gc-thresholdによって定義される）を超えたとき、それらのPodを削除します。 これはPodが作成されて時間とともに終了するため、リソースリークを避けます。

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

• バッチ計算などのように終了が予想されるPodに対しては、Jobを使用します。 JobはrestartPolicyがOnFailureまたはNeverになるPodに対してのみ適切です。

• 停止することを期待しないPod（たとえばWebサーバーなど）には、ReplicationController、ReplicaSet、またはDeploymentを使用します。ReplicationControllerはrestartPolicyがAlwaysのPodに対してのみ適切です。

• マシン固有のシステムサービスを提供するため、マシンごとに1つずつ実行する必要があるPodにはDaemonSetを使用します。

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の例

• Podが実行中でそのPodには1つのコンテナがあります。コンテナは正常終了しました。

  • 完了のイベントを記録します。
  • restartPolicyが、
    • Always: コンテナを再起動します。PodのphaseはRunningのままです。
    • OnFailure: PodのphaseはSucceededになります。
    • Never: PodのphaseはSucceededになります。

• Podが実行中でそのPodには1つのコンテナがあります。コンテナは失敗終了しました。

  • 失敗イベントを記録します。
  • restartPolicyが、
    • Always: コンテナを再起動します。PodのphaseはRunningのままです。
    • OnFailure: コンテナを再起動します。PodのphaseはRunningのままです。
    • Never: PodのphaseはFailedになります。

• Podが実行中で、その中には2つのコンテナがあります。コンテナ1は失敗終了しました。

  • 失敗イベントを記録します。
  • restartPolicyが、
    • Always: コンテナを再起動します。PodのphaseはRunningのままです。
    • OnFailure: コンテナを再起動します。PodのphaseはRunningのままです。
    • Never: コンテナを再起動しません。PodのphaseはRunningのままです。
  • コンテナ1が死んでいてコンテナ2は動いている場合
    • 失敗イベントを記録します。
    • restartPolicyが、
      • Always: コンテナを再起動します。PodのphaseはRunningのままです。
      • OnFailure: コンテナを再起動します。PodのphaseはRunningのままです。
      • Never: PodのphaseはFailedになります。

• Podが実行中でそのPodには1つのコンテナがあります。コンテナはメモリーを使い果たしました。

  • コンテナは失敗で終了します。
  • OOMイベントを記録します。
  • restartPolicyが、
    • Always: コンテナを再起動します。PodのphaseはRunningのままです。
    • OnFailure: コンテナを再起動します。PodのphaseはRunningのままです。
    • Never: 失敗イベントを記録します。PodのphaseはFailedになります。

• Podが実行中ですがディスクは死んでいます。

  • すべてのコンテナを殺します。
  • 適切なイベントを記録します。
  • PodのphaseはFailedになります。
  • Podがコントローラで作成されていた場合は、別の場所で再作成されます。

• Podが実行中ですがNodeが切り離されました。

  • Nodeコントローラがタイムアウトを待ちます。
  • NodeコントローラがPodのphaseをFailedにします。
  • Podがコントローラで作成されていた場合は、別の場所で再作成されます。

{{% /capture %}}

{{% capture whatsnext %}}

• attaching handlers to Container lifecycle eventsのハンズオンをやってみる

• configuring liveness and readiness probesのハンズオンをやってみる

• Container lifecycle hooksについてもっと学ぶ

{{% /capture %}}