Tech Learning Daily

「Running」はトラフィックを受け取れることを意味しない

kubectl get pods の STATUS 列に並ぶ Running は、コンテナプロセスが起動して動き続けていることを示すだけの表示だ。Pod が Running になった瞬間からリクエストを正しく処理できるとは限らない。DB接続の初期化中かもしれないし、キャッシュのウォームアップがまだ終わっていないかもしれない。

素朴には「デプロイのたびに Pod が再起動を繰り返すなら livenessProbe の設定を疑えばいい」と思うかもしれない。しかし実際の現場でつまずきやすいのは再起動そのものではなく、Pod は何ともないのに一部のリクエストだけ通ったり通らなかったりする、という現象の方だ。原因は Service が実際にトラフィックを転送する先の Pod IP 一覧である EndpointSlice にそのPodのIPが載っているかどうかにあり、載せるかどうかを決めているのが readinessProbe である。

liveness probe — 生きているかどうかだけを判定する

livenessProbe は、コンテナ内のプロセスがまだ応答できる状態かどうかを一定間隔で確認する。既定値は実行間隔を表す periodSeconds が10秒、応答待ちの上限を表す timeoutSeconds が1秒、連続失敗の許容回数を表す failureThreshold が3回で、この3回連続で失敗すると kubelet はコンテナを強制終了し、作り直す。デッドロックに陥って二度と応答しないプロセスを、外部から強制的に入れ替えるための仕組みだ。

livenessProbe に DB や外部APIへの疎通確認を書きたくなるが、これは避けたほうがよい。DB 側が一時的に落ちている間、そのDBに依存する全Podのlivenessが一斉に失敗して再起動され、再起動後もDBが直っていなければ同じ理由でまた失敗する。本来はDBの復旧を待てばよいだけの障害が、無関係な全Podの再起動の連鎖に変わってしまう。livenessは自分のプロセスが応答するかだけを見て、外部依存の生死には関与させないのが基本方針だ。

     ヘルスチェック失敗
    ┌───────┴───────┐
    ▼               ▼
liveness失敗    readiness失敗
    ▼               ▼
kubeletが再起動  EndpointSliceから除外
    ▼               ▼
RESTARTS+1      Podは動いたまま
                トラフィック停止のみ

readiness probe — トラフィックの蛇口を開け閉めする

readinessProbe が失敗すると、EndpointSlice を管理するコントローラがそのPodのIPを、一致する全Serviceの EndpointSlice から取り除く。Pod自体はkillされず動き続けるし、kubectl get pods の RESTARTS も増えない。ただ Service 経由のトラフィックだけが来なくなる。原因(例えばDBへの接続が一時的に切れている)が解消されて再びreadinessProbeが成功すれば、IPは自動的にEndpointSliceへ戻る。

Deployment のローリングアップデートも readinessProbe の結果で進行が制御される。同時に停止してよいPod数を表す maxUnavailable と、同時に追加してよいPod数を表す maxSurge は既定でそれぞれ 25% だが、新しいPodがreadyになるまで古いPodの入れ替えは進まない。ただし、readyになってから「利用可能」と数えるまでの待ち時間を表す minReadySeconds の既定値は 0 のため、readinessProbe が一度成功した瞬間にそのPodは「利用可能」とカウントされる。起動直後だけ一瞬成功してすぐ失敗に転じるような不安定なPodでは、この既定のままだと安定を確認せずに次のPodの入れ替えへ進んでしまう。minReadySeconds に数十秒を設定すると、その秒数だけReady状態を維持できたPodだけを「利用可能」と数えるため、フラッピングするPodを入れ替えの母数から締め出せる。

readinessProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 5
minReadySeconds: 30  # 既定0 → 安定確認なしに進む

startupProbe — 遅い起動を liveness の誤爆から守る

startupProbe を設定すると、それが成功するまで liveness と readiness のプローブ自体が実行されない。起動に時間がかかるアプリケーションが、まだ立ち上がっている途中の状態を liveness に「死んでいる」と誤判定されて再起動され、再起動のたびにまた起動待ちからやり直す——というループを防ぐための仕組みだ。

startupProbe が必要かどうかの目安は initialDelaySeconds + failureThreshold × periodSeconds という式で計算できる。既定値のまま(0 + 3 × 10 = 30秒)このアプリの起動が30秒を超えるなら、livenessProbe だけでは起動完了前に失敗としてカウントされ切ってしまう。JVM を使うアプリなど起動に数十秒から数分かかる場合は、livenessと同じエンドポイントを見る startupProbe を failureThreshold 大きめに設定して用意し、起動を待つ猶予をそちらに持たせるのが定石だ。