【ツール活用｜実務向け】Kubernetesの信頼性を最大化する：Liveness, Readiness, Startup Probeの正しい使い分け

1. 導入：なぜヘルスチェックの設定が重要なのか

Kubernetesで運用されるアプリケーションにおいて、Podが「起動していること」と「リクエストを処理できる状態であること」は別物です。もし、アプリケーションがメモリリークで応答不能になったり、起動に時間がかかるレガシーシステムだったりする場合、K8sが適切に制御できなければサービス停止やユーザーへのエラー応答を招きます。本記事では、システムの自己修復性を高めるための「3つのProbe」の正しい設計指針を解説します。

2. 基礎知識：3つのProbeの役割

Kubernetesには、Podの状態を監視するための3つのプローブが存在します。
LivenessProbe：アプリが生きているかを確認します。失敗した場合、K8sはコンテナを「再起動」させます。
ReadinessProbe：アプリがトラフィックを受け取れる状態かを確認します。失敗した場合、該当PodはServiceの負荷分散対象から除外されます。
StartupProbe：アプリの起動完了を待ちます。これが設定されている間、他のProbeは無効化されます。起動の遅いアプリに適しています。

3. 実装と使い分けの論理

現場で陥りやすい失敗は、すべてのProbeに同じエンドポイントを設定することです。
・LivenessProbeは「再起動が必要な致命的状態（デッドロック等）」のみを判定すべきです。外部依存（DB接続など）を含めると、DB一時停止時に全Podが再起動ループに陥るリスクがあります。
・ReadinessProbeは「外部リソースへの接続準備完了」を含めて判定します。これにより、準備が終わるまでトラフィックを流さないようにします。
・StartupProbeは、起動に数分かかるようなアプリケーションの死活監視を回避するために活用します。

4. サンプルプログラム：YAML設定例

以下は、Webアプリケーションにおける標準的なProbe構成です。

apiVersion: v1
kind: Pod
metadata:
  name: app-health-check
spec:
  containers:

name: my-app

    image: my-app:latest
    # 起動が遅いアプリのための設定
    startupProbe:
      httpGet:
        path: /health/ready
        port: 8080
      failureThreshold: 30 # 30回失敗するまで待機（起動待ち）
      periodSeconds: 10
    # トラフィック受け入れ判定
    readinessProbe:
      httpGet:
        path: /health/ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
    # 致命的な状態の判定（再起動トリガー）
    livenessProbe:
      httpGet:
        path: /health/live
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

5. 応用・注意点：現場での運用Tips

注意点1：LivenessProbeとDB依存の回避
LivenessProbeでDB接続確認を行うと、一時的なネットワーク障害でクラスター全体が再起動し、復旧が大幅に遅れます。Livenessはアプリ内部の「メモリ状態」や「スレッドの死活」に限定し、DB接続はReadinessProbeで制御するのが鉄則です。

注意点2：タイムアウトと閾値のチューニング
デフォルト設定のまま運用すると、負荷が高い瞬間にProbeが失敗し、意図しない再起動が発生することがあります。必ず負荷試験を行い、failureThreshold（失敗の許容回数）やtimeoutSeconds（タイムアウト時間）を実際のアプリの応答特性に合わせて調整してください。