― Readiness Probe の罠 ― #

K8S で kubectl get pods の結果が Running だからといって安心してはいけない。
これは単に「コンテナが起動している」という意味であって、「トラフィックを受け取る準備ができている」という意味ではない。

---

現象：Running (0/1) を探せ #

まず最初に確認すべきなのは READY カラムだ。

kubectl get pods -n <namespace>

NAME        READY   STATUS    RESTARTS
app-pod     0/1     Running   0

STATUS は Running なのに READY が 0/1？
これは コンテナ自体は動いているが、Kubernetes が「まだ準備できていない」と判断し、Service のエンドポイントから除外している状態を意味する。
当然、この状態では接続できない。

---

原因調査：describe と debug #

なぜ Ready にならないのかは describe でイベントを確認する。

kubectl describe pod <pod-name> -n <namespace>

Events セクションに 「Readiness probe failed」 が出ていれば原因は確定だ。

アプリ内部の状態をさらに詳しく確認したいが、
イメージに sh や ps すら存在しない場合（Distroless など）は、
以下のコマンドで一時的なデバッグコンテナをアタッチして確認する。

kubectl debug を実行するには コンテナ名 が必要になる。
コンテナ名は上記の describe の結果から確認できる。

kubectl debug -it <pod-name> -n <namespace> \
  --image=nicolaka/netshoot --target=<container-name>

接続後に実行：

ss -lntp   # アプリが 0.0.0.0 で正しくポートを Listen しているか確認

そのほか、以下のコマンドでプロセスやネットワークの状態を確認できる。

ps, curl, ip a, ip route, ip neigh,
nslookup, dig, printenv, df -h,
free -m, getent hosts

Distroless とは、実行ファイルと依存関係のみを含み、
シェルや基本ユーティリティをすべて削除したイメージである。
セキュリティは強化されるが、トラブルシューティングには
kubectl debug が必須となる。

---

対処：Probe 設定の修正 #

多くの場合、アプリの起動時間が設定より長いことが原因だ。
initialDelaySeconds を延ばすか、ヘルスチェックのパスを修正する。

まず、その Pod を作成したコントローラを確認する。

kubectl get pod <pod-name> -n <namespace> \
  -o jsonpath='{.metadata.ownerReferences[0].kind}{" "}{.metadata.ownerReferences[0].name}{"\n"}'

多くの場合は ReplicaSet が表示され、
その元となるのは Deployment であることがほとんどだ
（StatefulSet の場合もあるが、ここでは Deployment と仮定する）。

ReplicaSet → Deployment を特定する。

kubectl get rs -n <namespace> | grep <replicaset-name>

取得した Deployment を編集する。

kubectl edit deploy <deploy-name> -n <namespace>

例：

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 30  # アプリ起動を十分に待つ

---

まとめ #

• kubectl get pods で 0/1 になっていないか確認する
• describe で Readiness probe failed を確認する
• アプリの起動時間を考慮して initialDelaySeconds を調整する
• Running はコンテナの状態であり、サービスの状態ではない

🛠 마지막 수정일: 2025.12.22