KubernetesのLiveness Probeは、コンテナのプロセスがデッドロックなどで応答不能に陥ったことを検知し、そのコンテナを自動で再起動する仕組みです。プロセスは動いているのに処理が進まない「生きているが機能していない」状態を回復させる役割を担い、トラフィックの受け入れ可否を判断するReadiness Probe、起動の遅いアプリを保護するStartup Probeとは目的が異なります。この記事では、3種のProbeの違いと選択基準、exec・httpGet・tcpSocket・gRPCの4つのチェック方式、initialDelaySecondsなどの設定値、YAMLでの実装と動作確認、そして誤設定が再起動ループを招くアンチパターンまでを整理します。
まとめ：Liveness Probe設定の要点
- Liveness＝再起動の判断、Readiness＝トラフィックの可否、Startup＝起動猶予。役割が違うため使い分ける。
- チェック方式は
exec・httpGet・tcpSocket・grpcの4種。gRPCはKubernetes v1.27でGA（正式版）となり、外部ツールなしで利用できる。 - 主要パラメータの既定値は
initialDelaySeconds=0、periodSeconds=10、timeoutSeconds=1、successThreshold=1、failureThreshold=3。 - Liveness Probeでデータベースなど外部依存をチェックしてはいけない。依存先の障害で全Podが同時再起動し、カスケード障害を起こす。
以降で、それぞれの根拠と具体的な設定を見ていきます。
Liveness Probeとは：Kubernetesがコンテナを再起動する判断基準
Liveness Probeは、kubeletがコンテナへ定期的にヘルスチェックを送り、failureThresholdで指定した回数だけ連続で失敗すると、そのコンテナを再起動する機能です。判断対象はあくまで「コンテナ内のプロセスが正常に処理を続けられるか」で、典型的にはデッドロックや無限ループのように、プロセスは終了していないのに応答を返せなくなった状態を検知します。プロセスがクラッシュして終了した場合はKubernetesの再起動ポリシーが直接コンテナを立ち上げ直すため、Liveness Probeの主眼は「終了しないが機能しない」ケースの回復にあります。
Probe未設定時の無検知リスク
Liveness Probeを設定しないコンテナは、プロセスが起動している限り「正常」とみなされ続けます。アプリがデッドロックやメモリ枯渇で応答を返せなくなっても、Kubernetesはそれを異常と判断できず、再起動が行われません。結果として、ロードバランサからは生存しているPodに見えるためリクエストが振り分けられ、実際には全て失敗する、という状態が続きます。自動回復の恩恵を受けたい応答型のアプリケーションでは、Liveness Probeが復旧の起点になります。
Liveness・Readiness・Startupの違いと使い分け
Kubernetesの3つのProbeは名前が似ていますが、失敗したときの挙動がまったく異なります。Livenessはコンテナを再起動し、Readinessはトラフィックを止めるだけで再起動はしません。Startupは起動が完了するまで他の2つを抑止します。この違いを取り違えると、再起動すべきでないコンテナを落としたり、起動中のアプリを繰り返し殺したりする事故につながります。
Readiness Probe：Serviceのエンドポイントからの切り離し
Readiness Probeが失敗すると、KubernetesはそのPodをServiceのエンドポイント一覧から外し、新しいリクエストが届かないようにします。コンテナは再起動されず、準備が整えば再びエンドポイントへ戻ります。起動直後のキャッシュ構築中や、一時的に依存サービスへ接続できない間だけトラフィックを外したいときに使います。「まだ受けられない」を表現するのがReadiness、「もう回復不能だから作り直す」を表現するのがLivenessです。
Startup Probe：起動が遅いアプリの初期化を保護する
Startup Probeは、アプリの起動完了を確認するまでLiveness・Readinessの実行を止めておくためのProbeです。成功するまでは他の2つが動かないため、初期化に時間のかかるレガシーアプリが、起動途中でLiveness Probeに殺されて再起動ループに陥るのを防げます。かつてはinitialDelaySecondsを長めに取って対処していましたが、起動時間が読めないアプリではStartup ProbeでfailureThreshold×periodSecondsの猶予枠を確保するほうが安全です。
3種のProbeの選択基準
| Probe | 失敗時の挙動 | 主な用途 |
|---|---|---|
| Liveness | コンテナを再起動 | デッドロック等からの自動回復 |
| Readiness | Serviceから切り離す（再起動なし） | 一時的にトラフィックを止める |
| Startup | 成功まで他2つを抑止 | 起動が遅いアプリの保護 |
基本は「応答性の回復が要るならLiveness、トラフィック制御が要るならReadiness、起動が遅いならStartupを追加」で判断します。KubernetesそのものやPod・Serviceの前提を整理したい場合は、Kubernetes（クバネティス）とは？仕組み・Dockerとの違いもあわせて確認してください。
Probeの4つのチェック方式：exec・httpGet・tcpSocket・gRPC
各Probeは、実際のチェック方法を次の4方式から1つだけ指定します。アプリの通信手段に合わせて選びます。
httpGet：HTTPエンドポイントのステータスで判定
指定したパスへHTTP GETを送り、レスポンスのステータスコードが200〜399なら成功と判定します。Webアプリやマイクロサービスで最も一般的な方式です。/healthzのような専用のヘルスチェック用エンドポイントを用意し、DBへの問い合わせなど重い処理を含めないのが基本形です。
exec：コンテナ内コマンドの終了コードで判定
コンテナ内で指定コマンドを実行し、終了コードが0なら成功とします。HTTPを持たないバッチ処理やデーモンで使い、たとえばcat /tmp/healthyのように、アプリが正常時に作るファイルの有無を確認する使い方が一般的です。プロセス起動のコストがかかるため、頻度の高いProbeでは負荷に注意します。
tcpSocket：TCP接続の確立可否で判定
指定ポートへのTCP接続が確立できれば成功とします。HTTPを話さないデータベースやメッセージキューなど、ポートが開いているかだけを確認したい場合に向きます。ただし「接続できる＝正しく処理できる」とは限らないため、アプリ層の異常までは検知できない点に留意します。
gRPC：v1.27でGAとなったネイティブ対応
gRPCサーバに対しては、標準のgRPCヘルスチェックプロトコルで直接Probeを実行できます。この機能はKubernetes 1.24でベータ、1.27で正式版（GA）となり、フィーチャーゲートなしで使えます。以前はgrpc-health-probeという外部バイナリをコンテナに同梱する必要がありましたが、GA以降はマニフェストでgrpcポートを指定するだけで済みます。Probe側はTLSや認証パラメータを持たないため、ヘルスチェック用エンドポイントはPodのIPで平文待受にする点だけ注意します。
Probeの設定パラメータと既定値：initialDelaySeconds・periodSeconds ほか
Probeの挙動は5つのパラメータで調整します。既定値のまま使うと厳しすぎる場合があるため、値の意味を理解して設定します。
各パラメータの意味と既定値
| パラメータ | 既定値 | 意味 |
|---|---|---|
| initialDelaySeconds | 0 | コンテナ起動からProbe開始までの待機秒数 |
| periodSeconds | 10 | Probeを実行する間隔（秒） |
| timeoutSeconds | 1 | 応答を待つタイムアウト（秒） |
| successThreshold | 1 | 成功とみなす連続成功回数 |
| failureThreshold | 3 | 失敗とみなす連続失敗回数 |
successThresholdはLivenessとStartupでは1に固定され、1以外を指定できません。1回でも成功すれば「生きている」と判断すべきだからです。複数回の成功を要求できるのはReadiness Probeだけです。
timeoutSeconds・failureThresholdの調整指針
再起動が発動するまでの猶予は、おおよそinitialDelaySeconds＋periodSeconds×failureThresholdで決まります。既定値のLivenessなら、起動後およそ30秒でチェックが積み重なり再起動に至ります。起動に時間がかかるアプリでこの枠が足りない場合、initialDelaySecondsを安易に伸ばすと今度は障害検知が遅れるため、前述のStartup Probeへ切り出すのが定番の対処です。逆にtimeoutSeconds=1は高負荷時に応答が1秒を超えただけで失敗扱いになりやすく、過敏な再起動の原因になります。負荷試験時の応答時間を基準に、余裕を持った値へ調整します。
Liveness・Readiness Probeの設定例と動作確認
実際のPodマニフェストにProbeを書き、kubectlで挙動を確認する流れを示します。ここではhttpGet方式でLivenessとReadiness、起動保護のStartupを併記します。
マニフェスト例（httpGet）
apiVersion: v1
kind: Pod
metadata:
name: probe-demo
spec:
containers:
- name: app
image: registry.k8s.io/e2e-test-images/agnhost:2.40
args: ["netexec", "--http-port=8080"]
ports:
- containerPort: 8080
startupProbe:
httpGet:
path: /healthz
port: 8080
failureThreshold: 30
periodSeconds: 10
livenessProbe:
httpGet:
path: /healthz
port: 8080
periodSeconds: 10
failureThreshold: 3
readinessProbe:
httpGet:
path: /readyz
port: 8080
periodSeconds: 5Startup ProbeにfailureThreshold: 30・periodSeconds: 10を与えると、起動完了まで最大300秒の猶予が生まれ、その間Livenessは動きません。起動が終わればLivenessが引き継ぎます。
kubectlでの動作確認
適用後はkubectl describe pod probe-demoでEventsとRestart Countを確認します。Liveness Probeが失敗して再起動が起きると、EventsにLiveness probe failedとともにコンテナがKillされた記録が残り、RESTARTSのカウントが増えます。kubectl get podのREADY列は、Readiness Probeが成功しているコンテナ数を示すため、トラフィックが流れているかの確認に使えます。マニフェストの適用やデバッグに使うkubectl周辺のツールは、kubectlとkubebuilderの違いと使い分けも参考になります。
Liveness Probeのアンチパターン：設定してはいけない場面と再起動ループ
Liveness Probeは便利な一方で、誤った対象をチェックすると障害を「回復」ではなく「拡大」させます。ここは公式ドキュメントでも繰り返し警告される、事故の起きやすい領域です。結論から言えば、Liveness Probeはそのコンテナ自身が処理を続けられるかだけを見るべきで、それ以外を見せてはいけません。
外部依存チェックの禁止とカスケード障害
Liveness Probeの中で、データベースや別のマイクロサービスへの疎通を確認するのは典型的な失敗です。依存先が一時的にダウンすると、そこに繋ぐ全Podのプローブが同時に失敗し、Kubernetesがそれらを一斉に再起動します。しかし再起動しても依存先は復旧していないため、Podは起動と再起動を延々と繰り返し、依存先が戻っても再起動の嵐で自力回復できなくなります。これがカスケード障害です。外部依存の状態は、トラフィックを外すだけで再起動しないReadiness Probeに寄せるか、あるいはProbeでは見ずアプリ側のリトライに任せます。
高負荷時の再起動ループとtimeoutSecondsの調整
もう一つの罠が、負荷が高まってレスポンスが遅くなったときの再起動ループです。timeoutSeconds=1のまま運用すると、ピーク時に応答が1秒を超えただけでLivenessが失敗し、まだ処理できるコンテナを再起動してしまいます。落ちたPod分の負荷が残りのPodに集中し、それらも遅くなって失敗し…と連鎖して、負荷が高いときほど自らキャパシティを削る事態を招きます。対策は、timeoutSecondsとfailureThresholdに負荷試験ベースの余裕を持たせ、依存や重い処理をヘルスチェックのパスから外すことです。Liveness Probeは「疑わしきは再起動」ではなく「明確に壊れているときだけ再起動」に倒して設計します。
よくある質問
Liveness ProbeとReadiness Probeの違いは何ですか？
失敗時の挙動が違います。Liveness Probeが失敗するとコンテナが再起動され、Readiness Probeが失敗するとPodがServiceのエンドポイントから外れてトラフィックが止まります（再起動はされません）。回復のための再起動がLiveness、トラフィック制御がReadinessです。停止時にReadinessだけを先に落としてから受付を止める順序は、グレースフルシャットダウンの実装手順で解説しています。
Startup Probeとは何ですか？いつ使いますか？
アプリの起動完了を確認するまで、LivenessとReadinessの実行を止めておくProbeです。起動に時間のかかるアプリが、初期化の途中でLiveness Probeに再起動されてループに陥るのを防ぐために使います。起動時間が読めないレガシーアプリで特に有効です。
initialDelaySecondsは何秒に設定すべきですか？
アプリが最初のヘルスチェックに応答できるようになるまでの起動時間を基準にします。既定値は0秒です。起動時間が長い、あるいはばらつく場合は、initialDelaySecondsを伸ばすより、Startup Probeを追加して起動を保護するほうが安全です。
failureThresholdの既定値はいくつですか？
3です。既定のperiodSeconds=10と組み合わせると、連続で約30秒失敗し続けたときに再起動（Liveness）や切り離し（Readiness）が発動します。
Probeを設定しないとどうなりますか？
プロセスが起動している限り正常とみなされ続けます。デッドロックなどで応答を返せなくなっても再起動されず、準備前のPodにもトラフィックが流れます。自動回復とトラフィック制御の恩恵を受けられない状態になります。
