Kubernetes Podのライフサイクル(Lifecycle)

9944 ワード

同前 k 8 s クベルnetes podのライフサイクル pod lifecycle

文書ディレクトリ

Pod Lifecle

Podのフェーズ:Pod phase

容器の状態:Container states

容器のプローブ:Container probes

再起動ポリシー:restartPolicy

Pod削除

Podの回収

参考資料

Pod Lifecle
Podの段階:Pod phase
関連フィールド:.status.phase phaseは、Podがライフサイクルのどの段階にあるかを示し、次の5つの可能な値があります.

Pending:Podはk 8 sシステムで受け入れられていますが、Podには作成されていないコンテナもあります.Podがスケジューリングされる前もダウンロードコンテナミラーリングされる時もこの段階にある

Running:PodはNodeにスケジューリングされており、すべてのコンテナが作成されており、少なくとも1つのコンテナが稼働中(起動中または再起動中のコンテナも計算)

である.

Succeeded:Podのすべてのコンテナは正常に停止し、

を再起動することはありません.

Failed:Podのすべてのコンテナが停止し、少なくとも1つのコンテナが失敗停止(非0状態で終了またはシステムによって強制停止)

である.

Unknown:何らかの理由でPodが入手できない状態で、一般的にPodが存在するHostとの通信問題により

が発生する.
Pod phaseの表示方法:

kubectl get pods pi2-ll9dn -o yaml |grep 'phase'
phase: Succeeded

注意:次のコマンドを使用して表示されるSTATUSは、Podのphaseではありません.

kubectl get pod pi2-ll9dn
NAME        READY   STATUS      RESTARTS   AGE
pi2-ll9dn   0/1     Completed   0          4h50m

PodにはCompletedというphaseはありません.
容器の状態:Container states
関連フィールド:.status.containerStatuses[index].state(containerStatusesは配列であり、各配列要素はPodの1つのコンテナに対応する)1つのPodには複数のコンテナが含まれていることを知っているので、Podの状態またはフェーズはPodのコンテナの状態を直接反映することはできません.Podがノードにスケジューリングされると、kubeletはコンテナ実行時(Dockerなど)にコンテナの作成を開始します.コンテナの状態はコマンドkubectl describe pod [POD_NAME]で確認できます.次の3つの状態があります.

Waiting:コンテナのデフォルトの状態は、RunningとTerminatedの状態でなければこの状態であり、ミラーを引くときもこの状態

である

Running:コンテナが正常に動作中であることを示し、postStart hook(フック)が定義されている場合、そのhookはコンテナがRunning状態に入る前に

を実行する.

Terminated:コンテナが完了し、停止していることを示します.preStopフックが定義されている場合、1つの容器がTerminated状態に入る前にフックが実行されます.実行が完了するには、通常の終了と、何らかの理由で終了に失敗したため、ReasonとExit Codeを介して容器停止の原因とステータスコードを表示する2つの状況がある:

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

容器のプローブ:Container probes
Node上のkebuletはプローブを用いて運転中の容器の状態を周期的に検出することができる.プローブの実現方法は3種類あります.

は、cat /tmp/healthyのような特定のコマンドを容器内で実行する、コマンドが返すステータスコードが0であれば、検出に成功したと判断する

は、コンテナのIPおよび指定ポートに対してTCP検出を開始するが、成功すれば検出に成功すると考えられ、telnetを使用してLinuxサーバ上のポート

を検出するのと同様である.

は、コンテナのIPおよび指定ポートに対してHTTP要求を開始する、返されたステータスコードが[200400]区間内であれば、検出に成功すると判断する

.
次の3種類のプローブがあります.

livenessProbe:コンテナがまだ稼働しているかどうかを検出します.クbeletはこのプローブを使用して、いつコンテナを再起動するかを知っています.プローブに失敗すると、クbeletはそのコンテナをkillします.コンテナが再起動する必要があるかどうかは、コンテナがあるPodの再起動ポリシー(restartPolicy、詳細は後述)を参照してください.コンテナがこのプローブを提供していない場合は、デフォルトで成功した

readinesProbe:コンテナがサービス要求を受信する準備ができているかどうかを検出するために使用され、プローブに失敗すると、コントローラはこのPodのIPアドレスを対応するServiceから削除します.コンテナ起動時の初期化遅延(initial delay、詳細は以下のinitialDelaySecondsを参照)時間内に、プローブはデフォルトで失敗した.1つの容器がこのプローブを提供していない場合、デフォルトは成功(initial delayの後)

です.

startupProbe:コンテナの起動時にコンテナが起動完了したかどうかを判断するために使用されます.このプローブの検出に成功する前、すなわち、コンテナの起動に成功する前に、livenessProbeとreadinesProbeプローブは機能しません.起動中に、livenessProbeプローブがコンテナの再起動に失敗してデッドロックを引き起こすことを防止します.このプローブプローブが失敗すると(コンテナの起動時間がしきい値を超えた)、kubeletはこのコンテナkillを落とし、restartPolicyに基づいてコンテナ

を作成するかどうかを決定する.
プローブがサポートするプロパティ:

initialDelaySeconds:デフォルト値は0、最小値は0です.コンテナが起動してからどのくらい待つか、liveness or readinesは1回目の

の実行を開始します.

periodSeconds:プローブを実行するにはどのくらいかかりますか.デフォルト値は10で、最小値は1

です.

timeoutSeconds:プローブ実行タイムアウト時間、デフォルト値は1、最小値は1

successThreshold:失敗した後に何回プローブを実行して成功したか、デフォルト値は1、最小値は1であり、livenessにとっては1

でなければならない.

failureThreshold:プローブが何回連続して失敗したか、デフォルトは3で、最小値は1

です.
プローブの定義方法は以下のとおりです.

apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  containers:
  - name:demo-ctr
    image: polinux/stress
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]
    livenessProbe: # liveness  -command
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5 #  1      ,  5s  
      failureThreshold: 2 #       2          
      periodSeconds: 5 #  5s      
    readinessProbe: # readinessProbe    livenessProbe       
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    startupProbe:  # startupProbe
      httpGet:
        path: /healthz
        port: liveness-port
      failureThreshold: 30
      periodSeconds: 10  #     30*10=300s liveness readiness      ，300s startup      ，    kill

再起動ポリシー:restartPolicy
1つのコンテナが終了すると、成功しても失敗しても、再起動ポリシーがトリガーされ、restartPolicyの設定に基づいてコンテナを再起動するかどうかを決定します.restartPolicyには、次の3つの値があります.

Always:デフォルト値は、正常に終了しても失敗してもコンテナを再起動しようとします.PodのフェーズはRunning

に維持されます.

OnFailure:失敗したときに再起動し、PodのフェーズはRunningに維持し、成功したときに再起動しない、PodのフェーズはSucceeded

に移行する

Never:失敗しても成功しても再起動しない.Podの段階はFailedまたはSucceededに変わり、1つのPodが終了した後に再起動しようとすると、指数関数的に増加する遅延(10 s,20 s,40 s...最大5分)があり、1つの容器が再起動して10分間実行して問題が発生しないと、この遅延はリセットされます.

Pod削除
Podはnode上で実行されるプロセスのセットを表すため、これらのプロセスが不要になったときに優雅に終了することを許可することは重要です(KILL信号によって強制的に停止されるのではなく、リソースクリーンアップを行う機会がありません).k 8 sの設計目標は、ユーザが削除要求を開始し、プロセスがいつ終了するかを知ることができ、削除が最終的に完了することを確保することである.1つのPodに対して削除要求を開始すると、クラスタはこのPodを強制的に削除する前に、grace period(terminationGracePeriodSeconds、デフォルトは30 s)を記録し追跡し、この間、kubeletは優雅にPodを閉じることを試みる.一般的には、Dockerなどのコンテナ実行時には、Pod内の各コンテナのプライマリ・プロセスにTERM信号が送信され、grace periodが終了すると、コンテナ実行時には、まだ正常に終了していないプロセスにKILLが送信され、PodはAPIサーバ上で削除されます.クbeletまたはコンテナ実行時の管理サービスが、これらのプロセスが優雅に終了するのを待って再起動されると、grace periodを含む削除プロセス全体が再試行されます.PodのコンテナがpreStopフックを定義している場合、終了コンテナ(TERMまたはKILL信号をコンテナに送信する)の前にフックが先に実行され、grace period時間が過ぎてフックがまだ実行されていない場合、kubeletは2 sの時間を追加してコンテナが優雅に終了する機会を与える.preStopフックを長時間実行する必要がある場合は、terminationGracePeriodSecondsを大きくすることをお勧めします.grace periodが開始されると、Podは利用可能なサービスリストから削除され、サービス要求はこのPodに転送されません.すべてのコンテナ(pauseを含む)が停止すると、kubeletはAPI ServerをトリガーしてこのPodを削除します.
Podの回収
完了したPod(FailedおよびSucceededを含むPod)の場合、APIオブジェクトはシステムに保持されます.システムで作成されたPodの数が指定したしきい値(kube-controller-managerのterminated-pod-gc-threshold)を超えた場合、コントロールパネルはこれらの完了したPod(FailedおよびSucceededのPodを含む)をクリーンアップします.
参考資料
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

Kubernetesのスケジューリングメカニズム

ubuntu/linux mintインストールPyV 8