+v ljx97609760
一緒にコミュニケーションをとって勉強しましょう

ポッドのライフサイクル

この記事では、ライフサイクルのさまざまな段階、生存プローブと準備プローブ、再起動戦略などを含む、Kubernetes のポッドのライフサイクルについて説明します。

ポッドフェーズ

PodのステータスフィールドはPodStatusオブジェクトであり、PodStatusにはフェーズフィールドがあります。

ポッドのフェーズは、ライフサイクルにおけるポッドの単純なマクロの概要です。このフィールドは、コンテナーやポッドの包括的な概要を意図したものではなく、また、包括的なステートマシンを意図したものでもありません。

Pod フェーズの数と意味は厳密に指定されています。ポッドは、このドキュメントに記載されているもの以外のフェーズ値を持つと想定すべきではありません。

位相に可能な値は次のとおりです。

保留中: ポッドは Kubernetes システムによって受け入れられましたが、1 つ以上のコンテナーイメージがまだ作成されていません。待機時間には、ポッドをスケジュールする時間と、ネットワーク経由でイメージをダウンロードする時間が含まれます。これには時間がかかる場合があります。
実行中: ポッドはノードにバインドされており、ポッド内のすべてのコンテナが作成されています。少なくとも 1 つのコンテナが実行中か、起動または再起動の処理中です。
成功: ポッド内のすべてのコンテナは正常に終了したため、再起動されません。
失敗: ポッド内のすべてのコンテナが終了し、少なくとも 1 つのコンテナが失敗により終了しました。つまり、コンテナはゼロ以外のステータスで終了したか、システムによって終了されました。
不明 (Unknown): 何らかの理由で Pod のステータスを取得できません。通常は、Pod が存在するホストとの通信が失敗したためです。

次の図は、Pod のライフサイクルの模式図であり、Pod の状態の変化を確認できます。

ポッドのライフサイクルの概略図 (ネットワークからの画像)

ポッドのステータス

ポッドには、PodCondition の配列を含む PodStatus オブジェクトがあります。PodCondition 配列の各要素には、タイプフィールドとステータスフィールドがあります。type フィールドは文字列で、可能な値は PodScheduled、Ready、Initialized、Unschedulable、および ContainersReady です。ステータスフィールドは、True、False、Unknown の値を含む文字列です。

コンテナプローブ

プローブは、kubelet によってコンテナー上で実行される定期的な診断です。診断を実行するために、kubelet はコンテナーによって実装されたハンドラーを呼び出します。ハンドラーには次の 3 種類があります。

ExecAction: コンテナ内で指定されたコマンドを実行します。コマンドが戻りコード 0 で終了した場合、診断は成功したとみなされます。
TCPSocketAction: 指定されたポート上のコンテナの IP アドレスに対して TCP チェックを実行します。ポートが開いていれば、診断は成功したとみなされます。
HTTPGetAction: 指定されたポートとパス上のコンテナーの IP アドレスに対して HTTP Get リクエストを実行します。応答のステータスコードが 200 以上 400 未満の場合、診断は成功したとみなされます。

各プローブは 3 つの結果のうち 1 つを取得します。

成功: コンテナーは診断に合格しました。
失敗: コンテナーの診断は失敗しました。
不明: 診断が失敗したため、アクションは実行されません。

Kubelet はオプションで、コンテナ上で実行されている 2 種類のプローブを実行し、それに反応できます。

livenessProbe: コンテナが実行されているかどうかを示します。liveness プローブが失敗した場合、kubelet はコンテナーを強制終了し、コンテナーは再起動ポリシーの対象になります。コンテナーが liveness プローブを提供しない場合、デフォルトのステータスは成功です。
readinessProbe: コンテナーがリクエストを処理する準備ができているかどうかを示します。readiness プローブが失敗した場合、エンドポイントコントローラーは、ポッドに一致するすべてのサービスのエンドポイントからポッドの IP アドレスを削除します。初期遅延前の準備完了状態はデフォルトで失敗になります。コンテナーが Readiness プローブを提供しない場合、デフォルトのステータスは成功です。

liveness プローブと readiness プローブをいつ使用する必要がありますか?

コンテナー内のプロセスが問題に遭遇したり異常な場合にそれ自体をクラッシュできる場合、liveness プローブは必ずしも必要ではなく、kubelet はポッドの restartPolicy に従って正しいアクションを自動的に実行します。

プローブが失敗した場合にコンテナーを強制終了して再起動する場合は、liveness プローブの restartPolicy を Always または OnFailure に指定します。

プローブが成功した場合にのみポッドへのトラフィックの送信を開始する場合は、readiness プローブを指定します。この場合、readiness プローブは liveness プローブと同じである可能性がありますが、仕様に readiness プローブが存在するということは、ポッドはトラフィックを受信せずに起動し、プローブがトラフィックの受信に成功した後にのみ開始されることを意味します。

コンテナー自体を維持する場合は、liveness プローブとは異なるエンドポイントをチェックする readiness プローブを指定できます。

ポッドの削除時にリクエストを除外できるようにしたいだけの場合は、必ずしも readiness プローブを使用する必要はないことに注意してください。ポッドが削除されると、ポッドの存在に関係なく、ポッドは自動的にそれ自体を未処理状態にします。レディネスプローブ。ポッド内のコンテナーが停止するのを待っている間、ポッドは未処理の状態のままになります。

準備ゲート

Kubernetes 1.14 (バージョン readinessGates GA、バージョン 1.11 はアルファ版) 以降、ポッドの準備状況検出メカニズムの拡張機能がデフォルトでサポートされています。

アプリケーションは、追加のフィードバックまたは信号を PodStatus: Pod readiness に挿入できます。この機能を使用するには、PodSpec で readinessGates を設定し、kubelet がポッドの準備状況を評価するための追加条件のリストを指定します。

Readiness ゲートは、ポッドの status.condition フィールドの現在の状態によって決まります。Kubernetes がポッドの status.conditions フィールドでそのような条件を見つけられない場合、条件のステータスはデフォルトで「False」になります。
以下に例を示します。

kind: Pod
...
spec:
  readinessGates:
    - conditionType: "www.example.com/feature-1"
status:
  conditions:
    - type: Ready                              # 内置的 Pod 状态
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
    - type: "www.example.com/feature-1"        # 附加的额外的 Pod 状态
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
  containerStatuses:
    - containerID: docker://abcd...
      ready: true

追加するポッド条件の名前は、Kubernetes ラベルキー形式に準拠している必要があります。

Pod のステータスは、Pod 内のすべてのコンテナのステータスが Ready であり、Pod にアタッチされている追加のステータス検出の readinessGates 条件も Ready である場合にのみ Ready になります。

ポッドとコンテナのステータス

ポッドコンテナのステータスの詳細については、「PodStatus」と「ContainerStatus」を参照してください。報告されるポッドの状態情報は、現在の ContainerState に依存することに注意してください。

戦略を再起動する

PodSpec には、Always、OnFailure、Never の値を指定できる restartPolicy フィールドがあります。デフォルトは「常に」です。restartPolicy はポッド内のすべてのコンテナに適用されます。restartPolicy は、同じノード上の kubelet を介したコンテナーの再起動のみを指します。失敗したコンテナーは、5 分 (10 秒、20 秒、40 秒...) を上限とする指数バックオフ遅延で kubelet によって再起動され、実行が成功してから 10 分後にリセットされます。Pod のドキュメントに記載されているように、Pod は一度ノードにバインドされると、別のノードに再バインドされることはありません。

ポッドの寿命

一般に、ポッドは誰かが破壊するまで消えません。これは人またはコントローラーである可能性があります。このルールの唯一の例外は、一定期間 (マスターによって決定される) を超えてフェーズが成功または失敗したポッドは期限切れになり、自動的に破棄されることです。

使用可能なコントローラーは 3 つあります。

ジョブを使用して、バッチ計算など、終了することが予想される Pod を実行します。ジョブは、再起動ポリシーが OnFailure または Never であるポッドでのみ使用できます。
Web サーバーなど、終了することが予想されないポッドには、ReplicationController、ReplicaSet、および Deployment を使用します。ReplicationController は、restartPolicy が Always の Pod にのみ適用されます。
マシン固有のシステムサービスを提供するには、DaemonSet を使用して各マシンのポッドを実行します。

3 種類のコントローラーすべてに PodTemplate が含まれています。ポッドを自分で直接作成するのではなく、適切なコントローラーを作成し、コントローラーにポッドを作成させることをお勧めします。これは、マシンに障害が発生した場合に個々のポッドには自動的に回復する方法がないのに対し、コントローラーには自動的に回復できるためです。

ノードが停止するか、クラスターの残りの部分から切断されると、Kubernetes は、失われたノード上のすべてのポッドのフェーズを失敗に設定するポリシーを適用します。

高度な liveness プローブの例

Liveness プローブは kubelet によって実行されるため、すべてのリクエストは kubelet のネットワーク名前空間で行われます。

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - args:
    - /server
    image: k8s.gcr.io/liveness
    livenessProbe:
      httpGet:
        # when "host" is not defined, "PodIP" will be used
        # host: my-host
        # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed
        # scheme: HTTPS
        path: /healthz
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 15
      timeoutSeconds: 1
    name: liveness

状態例

ポッド内にはコンテナが 1 つだけあり、実行されています。コンテナは正常に終了しました。
- ログ完了イベント。
- restartPolicy が次の場合:
  - 常に: コンテナを再起動します。Pod フェーズはまだ実行中です。
  - OnFailure: ポッドフェーズが成功になります。
  - Never: ポッドフェーズは成功します。
ポッド内にはコンテナが 1 つだけあり、実行されています。コンテナの出口に失敗しました。
- 障害イベントをログに記録します。
- restartPolicy が次の場合:
  - 常に: コンテナを再起動します。Pod フェーズはまだ実行中です。
  - OnFailure: コンテナを再起動します。ポッドフェーズはまだ実行中です。
  - Never: ポッドフェーズは失敗になります。
ポッドには 2 つのコンテナがあり、実行されています。コンテナ 1 は終了できませんでした。
- 障害イベントをログに記録します。
- restartPolicy が次の場合:
  - 常に: コンテナを再起動します。Pod フェーズはまだ実行中です。
  - OnFailure: コンテナを再起動します。ポッドフェーズはまだ実行中です。
  - Never: コンテナーを再起動しません。Pod フェーズは実行されたままになります。
- コンテナ 1 が実行されておらず、コンテナ 2 が終了した場合:
  - 障害イベントをログに記録します。
  - restartPolicy が次の場合:
    - 常に: コンテナを再起動します。Pod フェーズはまだ実行中です。
    - OnFailure: コンテナを再起動します。ポッドフェーズはまだ実行中です。
    - Never: ポッドフェーズは失敗になります。
ポッド内にはコンテナが 1 つだけあり、実行されています。コンテナーランタイムのメモリ制限を超えました
- コンテナは失敗ステータスで終了しました。
- OOM イベントをログに記録します。
- restartPolicy が次の場合:
  - 常に: コンテナを再起動します。Pod フェーズはまだ実行中です。
  - OnFailure: コンテナを再起動します。ポッドフェーズはまだ実行中です。
  - なし: 失敗したイベントはログに記録され、ポッドフェーズは失敗のままになります。
ポッドは実行中ですが、ディスク障害があります:
- すべてのコンテナを強制終了します。
- 適切なイベントをログに記録します。
- ポッドフェーズが失敗になります。
- コントローラーで実行している場合、ポッドは別の場所で再構築されます。
ポッドは実行中であり、そのノードはセグメント化されています。
- ノードコントローラーはタイムアウトになるまで待機します。
- ノードコントローラーはポッドフェーズを失敗に設定します。
- コントローラーで実行している場合、ポッドは別の場所で再構築されます。

[クラウドネイティブ] ポッドのライフサイクル