ヘルスチェックの設計（liveness/readiness/startup）

3種のプローブは「問い」が違う

ヘルスチェック（プローブ）を「アプリが生きているか確かめる仕組み」と一言でまとめると、設計を誤ります。Kubernetes が3種類を持つのは、それぞれが別の問いに答え、別のアクションを引き起こす からです。問いとアクションの対応を取り違えると、健全なPodを殺したり、壊れたPodにトラフィックを流し続けたりします。

決定的な違いは 「失敗したら何が起きるか」 です。liveness が失敗するとコンテナは殺されて再起動します。readiness が失敗してもコンテナは生き続け、ただ振り分け先から外れるだけです。この非対称性が、後述する設計判断のすべての根拠になります。「再起動で直る問題か、待てば直る問題か」を取り違えると、対処が逆効果になるのです。

liveness：プロセスが「自力では直らない」状態の検出

liveness プローブが答えるべき問いは、「再起動以外に回復手段がない状態に陥っていないか」 です。典型例はデッドロック、無限ループ、メモリ枯渇でイベントループが進まない、といった プロセス内部の不可逆な詰まり です。これらは外から SIGKILL→再起動するしか直しようがありません。

逆に言えば、再起動で直らないものを liveness に入れてはいけません。最も多い失敗が、liveness のエンドポイントでDB接続や下流APIを叩いてしまうことです。下流が一時的に落ちている間、liveness は失敗し続け、kubelet は健全なアプリプロセスを 延々と再起動します。再起動してもDBは復旧していないので、また失敗する——これが再起動ループ（CrashLoopBackOff）の温床です。

実装上、liveness のチェックは軽量・自己完結であるべきです。HTTPなら「リクエストを受けてイベントループが回り、200を返せること」を確認する程度——つまり「ハンドラが応答できる」こと自体がイベントループ生存の証明になります。下流呼び出しもロック取得も含めません。

readiness：受付可否は刻一刻と変わる

readiness が答えるのは、「今、この瞬間、新規リクエストを処理できる状態か」 です。失敗してもPodは殺されず、Service の Endpoints から一時的に外れるだけで、状態が戻れば自動的に復帰します。これは liveness のような不可逆な判定ではなく、可逆なゲート です。

readiness を落とすべき正当なケースは、起動直後でキャッシュ温め中、設定リロード中、ローカルのワーカープールが飽和して新規を捌けない、そしてグレースフルシャットダウンの開始時です。終了時に readiness を落としてルーティングから外す流れは グレースフルシャットダウン の起点になります。

ここで最大の設計判断が 「readiness に依存先を含めるか」 です。これは liveness と違って一概に禁止ではありませんが、含めると連鎖障害のリスクがある ため慎重さが要ります。

判断の指針はこうです。そのPod固有のローカルな受付可否（プール飽和、ウォームアップ）は readiness に入れてよい。一方、全レプリカで共有する外部依存（共通DB、共通キャッシュ）は readiness に入れない。前者は外せば負荷が他Podに逃げて意味があるが、後者は全員同時に外れて逃げ場がなくなるからです。

startup：起動の遅さで liveness に殺されない

startup プローブは比較的新しい仕組みで、答える問いは 「起動シーケンスが完了したか」 です。失敗してもアクションは「待つ」だけ。重要なのは、startup が成功するまで liveness と readiness を一切作動させない 点です。

これが解決するのは典型的な事故です。起動に40秒かかるアプリ（巨大なヒープ確保、マイグレーション、JITウォームアップ等）に対し、liveness を initialDelaySeconds だけで調整しようとすると、安全側に倒して初期遅延を長くすればするほど、本当に詰まったときの検出も遅れるというジレンマに陥ります。短くすれば、まだ起動中のPodを liveness が「死んでいる」と誤判定して殺し、永遠に起動が終わらない再起動ループになります。

4つのパラメータが挙動を決める

各プローブの実際の挙動は、次の4パラメータの組み合わせで決まります。これらを理解せずにデフォルト値で運用すると、誤検知（フラッピング）と検出遅延のどちらかに偏ります。

periodSeconds        … チェック周期（何秒ごとに叩くか）
timeoutSeconds       … 1回のチェックの応答待ち上限
failureThreshold     … 連続何回失敗したらアクション発動か
successThreshold     … 連続何回成功したら復帰とみなすか（readinessで重要）

最悪検出時間 ≈ periodSeconds × failureThreshold + timeoutSeconds

failureThreshold を 1 にすると、たった1回のタイムアウト（GCの瞬間的ストップ・ザ・ワールド等）でPodが殺されます。逆に大きすぎると、本当の詰まりの検出が遅れる。一過性のノイズは閾値で吸収し、持続的な異常だけをアクションに繋げるのが設計の勘所です。timeoutSeconds の既定はしばしば短すぎ（1秒など）、負荷時のGCで簡単に超過するため、定常レイテンシのテール（パーセンタイル）を踏まえて余裕を持たせます。

設計判断のまとめ

3種のプローブを正しく使い分ける核心は、「失敗時のアクションから逆算する」 ことです。

そのチェックが失敗したとき、再起動すべきか？
  → YES（再起動で直る・自プロセス内部の詰まり）  : liveness
  → NO、でもトラフィックは止めたい（待てば直る）  : readiness
  → 起動が終わるまで上2つを待たせたいだけ       : startup

まとめ

• liveness＝再起動すべきか、readiness＝受付可否、startup＝起動完了か。問いとアクションが異なるので、決して一つのエンドポイントに混ぜない。
• liveness は自プロセス内部の不可逆な詰まりだけを軽量に見る。依存先を入れると再起動ループでメタステーブル障害を自作する。
• readiness はローカルな受付可否（プール飽和・ウォームアップ・終了開始）に使う。全レプリカ共有の依存先を入れると全員同時に外れて全停止する。依存先障害はサーキットブレーカ等で個別に扱う。
• startup を分ければ「起動は気長に、定常時の詰まりは即座に殺す」を両立できる。
• periodSeconds/timeoutSeconds/failureThreshold は一過性ノイズを吸収しつつ持続的異常を検出する観点で、テールレイテンシを踏まえて調整する。