ライフサイクルとヘルスチェック ― restartPolicy と probe

導入

Pod は生まれてから消えるまで、いくつかの状態（フェーズ）を移り変わります。そして「中のアプリが本当に生きているか・受付準備ができたか」を Kubernetes が自動で見張る仕組みが プローブ（probe） です。自己修復の要になる部分です。

説明

Pod の大まかな状態（フェーズ）は次のとおりです。

Pending（保留中） … まだノードに配置されていない、または準備中。
Running（実行中） … ノードに配置され、コンテナが動いている。
Succeeded（成功） … 中の処理が正常に完了して終わった（使い捨て処理向け）。
Failed（失敗） … 異常終了した。

コンテナが終了・失敗したときにどうするかは restartPolicy（再起動ポリシー） で決めます（Always＝常に再起動、OnFailure＝失敗時のみ、Never＝しない）。常駐サービスは既定の Always を使います。

さらに Kubernetes は、コンテナの中身を定期的に突いて健康状態を確かめます。これが プローブ（probe、探り針） で、3種類あります。

liveness probe（生存確認） … 「生きているか?」を確かめる。失敗が続くとコンテナを再起動する（フリーズからの自動復旧）。
readiness probe（準備確認） … 「受付できるか?」を確かめる。失敗している間はその Pod へ通信を送らない（起動直後や過負荷時に、まだ準備できていない Pod を避ける）。
startup probe（起動確認） … 起動が遅いアプリ向けに、立ち上がりきるまでの猶予を与える。これが成功するまで他のプローブを待たせる。

httpGet（HTTPで特定のパスを叩いて応答を見る）で liveness と readiness を設定した例です。

apiVersion: v1
kind: Pod
metadata:
  name: web-with-probes
spec:
  containers:
    - name: web
      image: my-web:1.0
      ports:
        - containerPort: 8080
      livenessProbe:            # 生きているか（ダメなら再起動）
        httpGet:
          path: /healthz        # このパスを叩いて
          port: 8080
        initialDelaySeconds: 5  # 起動5秒後から
        periodSeconds: 10       # 10秒ごとに確認
      readinessProbe:           # 受付できるか（ダメなら通信を回さない）
        httpGet:
          path: /ready
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 5

プローブの判定はこう流れます。

flowchart TD
    L{liveness<br/>応答あり?} -- はい --> OK[そのまま稼働]
    L -- いいえが続く --> RS[コンテナを再起動]
    R{readiness<br/>応答あり?} -- はい --> IN[通信の対象に含める]
    R -- いいえ --> OUT[通信の対象から外す<br/>Pod自体は消さない]

liveness と readiness の違いが肝心です。liveness は「ダメなら作り直す」、readiness は「ダメなら今は使わない（そっとしておく）」。この2つを適切に設定しておくことで、Kubernetes は落ちた Pod を自動で立て直しつつ、準備できていない Pod にうっかり通信を回す事故を防げます。第1章で挙げた「自己修復」は、こうしたプローブに支えられています。