xDev Asia

Podのデバッグ: CrashLoopBackOff、ImagePullBackOff、Pending。Deploymentと Serviceのトラブルシュート。体系的なkubectlデバッグワークフロー。

Podトラブルシューティングワークフロー — CrashLoopBackOff、ImagePullBackOff、OOMKilled

1. Podデバッグワークフロー

体系的なPodトラブルシューティング:
  
  kubectl get pod POD_NAME
     │
     ├── Pending → ノード問題またはPVC未バインド
     ├── Running（動作しない）→ ログ確認、exec
     ├── CrashLoopBackOff → アプリがクラッシュ
     ├── ImagePullBackOff → イメージまたはレジストリ問題
     └── Error → 起動/初期化失敗
  
  すべての問題 → 次のステップ:
  kubectl describe pod POD_NAME
  （最下部のEventsセクションを確認！）
  
  ログの確認:
  kubectl logs POD_NAME
  kubectl logs POD_NAME --previous  （クラッシュ後）
  kubectl logs POD_NAME -c CONTAINER  （マルチコンテナ）

2. 一般的なPod問題

状態	原因	デバッグ
Pending	スケジュール不可	describe pod → Events: CPU/メモリ不足またはAffinityに一致するノードなし
ImagePullBackOff	イメージが存在しない / レジストリ認証	イメージ名のタイポ、imagePullSecretsを確認
CrashLoopBackOff	アプリが繰り返しクラッシュ	kubectl logs --previous、アプリの終了コードを確認
OOMKilled	メモリリミット超過	kubectl describe pod → Container Reason: OOMKilled
CreateContainerError	ボリュームマウント、ConfigMap、Secretが存在しない	describe podのEventsを確認

試験のポイント：kubectl describe podのEventsセクションがデバッグの最も重要な場所です。CKAのタスクでは壊れたPodの修正がよく求められます — 通常はイメージ名のタイポ、ConfigMap名の誤り、ポートの競合です。

3. Exec & デバッグ

# 実行中のコンテナにexec
kubectl exec -it POD_NAME -- /bin/sh
kubectl exec -it POD_NAME -c CONTAINER_NAME -- bash

# エフェメラルコンテナでデバッグ（v1.23+）
kubectl debug -it POD_NAME --image=busybox --target=app

# Pod内外へのファイルコピー
kubectl cp POD_NAME:/var/log/app.log ./app.log
kubectl cp ./config.yaml POD_NAME:/tmp/config.yaml

# 素早いテストのためのport-forward
kubectl port-forward pod/POD_NAME 8080:80
kubectl port-forward svc/SERVICE_NAME 8080:80

4. Deployment問題

# Deploymentステータスの確認
kubectl rollout status deployment/myapp
kubectl get replicaset -l app=myapp  # RS履歴の確認

# Podテンプレートの問題: DeploymentがRSを作成するがPodが失敗
kubectl describe replicaset RS_NAME  # Podテンプレートエラーの確認

# Deploymentが進行中のままスタック？
kubectl describe deployment myapp | grep -A5 Conditions

# Deploymentレベルのイベント確認
kubectl get events --field-selector involvedObject.name=myapp --sort-by='.lastTimestamp'

5. Service接続性デバッグ

Service接続性のデバッグ:

1. Endpointsの確認
   kubectl get endpoints SERVICE_NAME
   → 空: セレクタの不一致

2. クラスタ内からテスト
   kubectl run test --image=busybox --rm -it -- wget -O- http://SERVICE_NAME:PORT

3. kube-proxyの確認
   kubectl get pods -n kube-system -l k8s-app=kube-proxy

4. iptablesの確認（ノード上）
   iptables -t nat -L KUBE-SERVICES | grep SERVICE_NAME

6. チートシート

タスク	コマンド
前回コンテナのログ	`kubectl logs POD --previous`
Namespace内の全イベント	`kubectl get events --sort-by='.lastTimestamp'`
素早い接続テスト	`kubectl run test --image=busybox --rm -it -- wget -qO- URL`
Podの終了コード確認	`kubectl describe pod \| grep Exit Code`
マルチコンテナのログ	`kubectl logs POD -c CONTAINER`

7. 練習問題

Q1：PodがCrashLoopBackOff状態です。アプリケーションログに「Error: failed to connect to database at localhost:5432」と表示されています。問題は何ですか？

A) データベースServiceの設定ミス
B) アプリがlocalhostでデータベースに到達しようとしているが、サイドカーコンテナにデータベースが動作していない ✓
C) Podのメモリが不足している
D) Secretのデータベースパスワードが不正

解説：Pod内のコンテナはネットワーク名前空間を共有するため、「localhost」は同じPod内の他のコンテナにのみ到達します。データベースが別のPodにある場合、Service DNS名（例: pg-service.namespace.svc.cluster.local）を使用する必要があります。

Q2：DeploymentのPodがImagePullBackOffでスタックしています。イメージ名は「mycompany/private-app:1.2」です。最初に確認すべきことは？

A) Docker Hubにそのタグのイメージが存在するか
B) Deploymentにレジストリ認証情報を参照するimagePullSecretsがあるか ✓
C) ノードのディスク容量が十分か
D) Serviceが正しく設定されているか

解説：プライベートレジストリは認証が必要です。Podにはレジストリ認証情報を含むSecret（type: kubernetes.io/dockerconfigjson）を参照するimagePullSecretsフィールドが必要です。イメージ名とタグが正しいかも確認します。

Q3：「kubectl get endpoints myservice」の結果が「」を表示します。最も可能性の高い問題は？

A) Serviceポートの誤り
B) Serviceセレクタにマッチするラベルを持つReady状態のPodがない ✓
C) Ingressの設定ミス
D) kube-proxyが動作していない

解説：EndpointsはPodがServiceセレクタにマッチし、かつReady状態の場合に設定されます。一般的な原因：ラベルの不一致（セレクタのタイポ）、全PodがPending/CrashLoopingのためReady状態でない、間違ったNamespace。kubectl get pods -l APP=LABEL --show-labelsで確認。