liveness・readiness・startup probe とは何で、それぞれいつ使いますか？

Question

IT Interview Practice · Accepted Answer

probe は、kubelet がコンテナの健全性をチェックし、その結果に応じて動作できるようにします。3 種類あります。**liveness**（生きているか、それとも再起動すべきか？）、**readiness**（トラフィックを受ける準備ができているか？）、**startup**（起動が完了したか？）です。それぞれ異なる問いに答えます。

## 3 つの probe を一目で

```text
LIVENESS   → "Is the app stuck/deadlocked?"   FAIL → kubelet RESTARTS the container
READINESS  → "Can it serve traffic right now?" FAIL → Pod removed from Service endpoints
                                                       (NOT restarted)
STARTUP    → "Has the slow boot finished?"     runs FIRST; while it runs, liveness &
                                                readiness are held off
```

## readiness と liveness — 重要な区別

```text
Readiness controls TRAFFIC:
  → a Pod that fails readiness is pulled OUT of the Service load-balancer,
    but keeps running (e.g. it's warming a cache or a dependency is down)
Liveness controls LIFE:
  → a Pod that fails liveness is KILLED and restarted (it's broken beyond recovery)
Using liveness where you meant readiness causes needless restart loops.
```

## probe の定義

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      ports: [{ containerPort: 8080 }]

startupProbe:            # 起動が遅いアプリに、他が始まる前の猶予を与える
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = 起動まで最大 5 分
        periodSeconds: 10

readinessProbe:          # トラフィックを制御する
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # 不健全なら再起動する
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## probe の仕組み

```text
httpGet    → GET a path; 2xx/3xx = pass         (most common for web apps)
tcpSocket  → can we open a TCP connection?       (for non-HTTP services)
exec       → run a command; exit 0 = pass        (custom checks)
grpc       → native gRPC health check
Key knobs: initialDelaySeconds, periodSeconds, timeoutSeconds,
           failureThreshold, successThreshold.
```

## なぜ startup probe が存在するのか

```text
Slow-starting apps (JVM warmup, big migrations) used to force you to set a huge
initialDelaySeconds on liveness — which then made real crashes slow to detect.
The startupProbe fixes this: it protects the slow boot, and ONLY after it passes
do liveness/readiness begin with their normal (tight) timings.
```

```bash
kubectl describe pod app     # イベント内で probe の失敗と再起動の理由を見る
kubectl get pod app          # READY 列は readiness を、RESTARTS は liveness を反映
```

## なぜ重要なのか

health probe は Kubernetes が self-healing と安全なトラフィックルーティングを実現する手段であり、3 種類とそれぞれをいつ使うかを理解することは必須の信頼性の知識です。多くのエンジニアがつまずく決定的な区別は、**readiness** と **liveness** の間にあります。readiness は**トラフィック**を制御し（失敗した Pod は Service の load-balancer から外されるが動き続ける。ウォームアップ中や依存先が一時的に落ちているときに理想的）、liveness は**生死**を制御します（失敗した Pod は kill されて再起動される。回復不能なほどデッドロックしたとき用）。この 2 つを混同する — readiness を意図した所で liveness probe を使う — と、無用な再起動ループと障害を招くため、各 probe がどの問いに答えるかを知ることは直接的に実践的です。**startup** probe は実在した歴史的な痛みを解決します。起動の遅いアプリはかつて liveness に巨大な `initialDelaySeconds` を強い（本物のクラッシュの検出を遅らせた）のに対し、startup probe は起動ウィンドウを保護し、startup が成功したときに初めて liveness/readiness を通常の締まったタイミングで走らせます。probe の仕組み（`httpGet`・`tcpSocket`・`exec`・`grpc`）と調整つまみ（`initialDelaySeconds`・`periodSeconds`・`failureThreshold` など）を理解すれば、当て推量ではなく正しく health check を設定できます。probe は、ユーザーが健全な Pod に当たるか、壊れた Pod が自動的に回復するかを直接左右するため、それを正しく設定することは、Kubernetes 上で信頼性の高い production グレードの workload を動かすための基礎です。

3 つの probe を一目で

readiness と liveness — 重要な区別

probe の定義

probe の仕組み

なぜ startup probe が存在するのか

なぜ重要なのか

関連する質問