xDev Asia

Liveness/Readiness/Startup Probeの設定方法と使い分け。kubectl logs、exec、debug、 port-forwardによるデバッグ。Podのステータスと一般的な障害パターン。

Probes、Logging & Debugging — Liveness、Readiness、Startup Probeのタイムライン

1. 3つのProbeタイプ

Probe	目的	失敗時の動作
Liveness	コンテナが正常に動作しているか確認	コンテナを再起動
Readiness	コンテナがトラフィックを受け入れる準備ができているか確認	Serviceのendpointsから削除（再起動はしない）
Startup	アプリケーションの起動完了を確認	コンテナを再起動（成功するまでliveness/readinessを無効化）

Probeタイムライン:

  コンテナ起動 ──► Startup Probe (チェック中...) ──► 成功 ──► Liveness + Readiness開始
                                                     │
                                                     ▼
                                      failureThresholdに達すると ──► コンテナ再起動

2. Probeメソッドと設定

# httpGet — HTTP GETリクエストを送信
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15    # 最初のチェックまでの待機時間
  periodSeconds: 10          # チェック間隔
  timeoutSeconds: 3          # タイムアウト
  failureThreshold: 3        # 失敗判定に必要な連続失敗回数
  successThreshold: 1        # 成功判定に必要な連続成功回数

# tcpSocket — TCPポートへの接続を試行
readinessProbe:
  tcpSocket:
    port: 3306

# exec — コンテナ内でコマンドを実行（exit 0 = 成功）
livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy

設定フィールド	デフォルト	説明
`initialDelaySeconds`	0	コンテナ起動後、最初のProbeまでの待機秒数
`periodSeconds`	10	Probeの実行間隔（秒）
`timeoutSeconds`	1	Probeのタイムアウト秒数
`failureThreshold`	3	失敗と判定する連続失敗回数
`successThreshold`	1	成功と判定する連続成功回数（readinessのみ1以上設定可能）

試験のポイント: 起動が遅いアプリケーション（Java/Spring Bootなど）にはstartupProbeを使います。Startup Probeが成功するまでLiveness Probeは無効化されるため、アプリが初期化中に誤って再起動されることを防ぎます。CKADではこの3つのProbeの正しい使い分けがよく出題されます。

3. kubectl logs

# Podのログを表示
kubectl logs mypod

# 特定のコンテナのログ（マルチコンテナPod）
kubectl logs mypod -c sidecar

# ログをリアルタイムで追跡
kubectl logs mypod -f

# 直近1時間のログ
kubectl logs mypod --since=1h

# 直近100行のログ
kubectl logs mypod --tail=100

# 前のコンテナインスタンスのログ（再起動後）
kubectl logs mypod --previous

4. デバッグコマンド

# コンテナ内でコマンド実行
kubectl exec -it mypod -- sh
kubectl exec mypod -- cat /etc/config/app.conf

# ポートフォワード（ローカルPCからPodに直接アクセス）
kubectl port-forward mypod 8080:80
kubectl port-forward svc/myservice 8080:80

# エフェメラルデバッグコンテナ（running podに追加）
kubectl debug mypod -it --image=busybox --target=app

# Podからファイルをコピー
kubectl cp mypod:/var/log/app.log ./app.log
kubectl cp ./config.yaml mypod:/etc/config/

5. 一般的なPodステータス

ステータス	原因	対処法
CrashLoopBackOff	コンテナが繰り返しクラッシュ	`kubectl logs --previous`を確認
ImagePullBackOff	イメージのpullに失敗	イメージ名、タグ、レジストリ権限を確認
Pending	スケジュールできない	ノードリソース、taints/tolerations、PVCを確認
OOMKilled	メモリ制限を超過	`resources.limits.memory`を増加
Error	コンテナが非ゼロ終了コードで終了	ログとコマンドを確認

6. チートシート

タスク	コマンド
クラッシュしたPodの原因を調査	`kubectl logs pod --previous`
Pod内をインタラクティブに調査	`kubectl exec -it pod -- sh`
ローカルからPodにアクセス	`kubectl port-forward pod 8080:80`
ライブデバッグコンテナを追加	`kubectl debug pod -it --image=busybox`
Podの詳細とイベントを確認	`kubectl describe pod name`

7. 練習問題

Q1: アプリケーションの起動に60秒かかります。起動中にlivenessProbeがコンテナを再起動し、CrashLoopBackOffに陥ります。最適な解決策はどれですか？

A) livenessProbeのinitialDelaySecondsを120に増やす
B) livenessProbeを削除する
C) 十分なfailureThresholdを持つstartupProbeを追加する ✓
D) readinessProbeで代替する

解説: startupProbeは起動時間が長いアプリケーション向けの推奨ソリューションです。startupProbeが成功するまでlivenessProbeとreadinessProbeは無効化されます。initialDelaySecondsを増やすよりも堅牢です — 起動時間は負荷や環境によって変動するためです。

Q2: コンテナが再起動し続けています。前のコンテナインスタンスのログを確認するコマンドはどれですか？

A) kubectl logs mypod --all
B) kubectl logs mypod --previous ✓
C) kubectl describe pod mypod
D) kubectl get events

解説: --previousフラグは前のコンテナインスタンスのログを表示します。コンテナが再起動した場合、現在のログにはクラッシュ情報が含まれていないことがあります。describeとeventsも有用ですが、アプリケーションレベルのエラーは--previousログに記録されています。

Q3: readinessProbeが失敗した場合の動作はどれですか？

A) コンテナが再起動される
B) Pod全体が削除される
C) Podが対応するServiceのendpointsから削除される ✓
D) PodがPending状態に戻る

解説: readinessProbeの失敗はコンテナの再起動を引き起こしません（livenessProbeとは異なる）。代わりに、PodがServiceのendpointsリストから削除され、新しいトラフィックが送られなくなります。readinessProbeが再び成功すると、Podはendpointsに復帰します。