Liveness Probe Failed エラーの記事一覧

冒頭まとめ Liveness probe failed は、kubeletが対象コンテナの生存確認に失敗した記録です。 Warning Unhealthy kubelet Liveness probe failed: Get "http://10.244.1.17:8080/healthz": dial tcp 10.244.1.17:8080: connect: connection refused 失敗が failureThreshold の回数だけ連続すると、kubeletは失敗したコンテナを終了させます。その後の再起動は restartPolicy に従います。Pod lifecycleの公式資料では、Pod単位の値は Always、OnFailure、Never で、既定値は Always と定義されています。そのため、Deploymentなど一般的なPodでは同じPod内でコンテナが再起動します。 Liveness probeが失敗 ↓ failureThreshold回連続 kubeletが対象コンテナを終了 ↓ restartPolicyがAlwaysまたはOnFailure 同じPod、同じNodeでコンテナを再起動 ↓ 失敗が続けば再起動待ちが長くなり、CrashLoopBackOffになり得る ここで、Podが削除されて新しいPodへ置き換わるわけではありません。Pod名とUIDは同じまま、コンテナの restartCount が増えます。複数コンテナのPodなら、probeに失敗したコンテナが対象です。 Kubernetes公式のprobe資料は、liveness probeを、停止しているように見えないまま処理が進まなくなったコンテナを再起動する仕組みとして説明しています。一時的な高負荷、外部データベースの停止、起動の遅さを検出するためのものではありません。 同じ接続失敗でも、readiness probeとは結果が違います。 Liveness probe failed → 対象コンテナを終了し、再起動対象にする Readiness probe failed → コンテナは動かしたまま、PodをServiceの通常転送先から外す 一時的に要求を受けられないだけなら、readinessProbeでServiceから外します。起動に時間がかかるなら startupProbe で、livenessの開始を待たせます。再起動しなければ回復できない状態だけを livenessProbe で判定します。 最初に確認するのは再起動回数ではなく、イベント末尾の失敗理由です。 connect: connection refused → 指定したportで待ち受けていない context deadline exceeded / timeout → timeout内に応答できない HTTP probe failed with statuscode: 500 → endpointが失敗用statusを返した command timed out / exit code != 0 → exec probeのcommandが失敗した エラーの概要 probeは、kubeletがコンテナへ定期的に行う診断です。HTTP、TCP、exec、gRPCの4方式があります。 ...