kubectl デバッグパターン

kubectl describe pod <name> -n <ns>
kubectl get events -n <ns> --sort-by='.lastTimestamp'
kubectl logs <pod> -n <ns> [-c <container>] [--previous]

Source              | 見る結
default-scheduler   | スケジューリング段階 — Pending の原因 (taint, affinity, resources, PVC)
kubelet             | ノードの上での段階 — image pull, mount, probe, OOM
controller-manager  | 上位コントローラのアクション — ReplicaSet の Pod 生成 / 削除
attachdetach        | EBS / EFS ボリュームのマウント段階

# リアルタイムストリーム
kubectl logs -f <pod>

# 最後の N 行
kubectl logs --tail=200 <pod>

# マルチコンテナ Pod
kubectl logs <pod> -c <container>

# 直前に死んだコンテナ (CrashLoopBackOff の核心)
kubectl logs <pod> --previous

# Deployment / Label 単位
kubectl logs -l app.kubernetes.io/name=myshop-api --tail=100

kubectl exec -it <pod> -n <ns> -- /bin/sh

# Pod の中に busybox コンテナを挟み込む
kubectl debug -it <pod> -n <ns> \
  --image=busybox:1.36 \
  --target=<container-name>

# distroless Pod のファイルシステムを見る (--target で同じ PID namespace 共有)
kubectl debug -it <pod> -n <ns> \
  --image=nicolaka/netshoot \
  --target=<container-name>

kubectl debug node/<node-name> -it --image=busybox

1. kubectl logs <pod> --previous
   -> 直前のコンテナの stderr が本当の原因。95% の場合ここで答えが出る。

2. kubectl describe pod <pod>
   -> Events の Last State / Reason / Exit Code 確認。
   -> Exit Code 137 = SIGKILL (OOM または強制終了)
   -> Exit Code 139 = SIGSEGV (segfault)
   -> Exit Code 1 = 一般エラー

3. probe 失敗を疑う
   -> [12章 ヘルスチェック](./health-checks/) の liveness が早く fail しすぎると
      アプリケーションが生きていても kubelet がコンテナを殺す。
   -> initialDelaySeconds が十分かを点検。

4. initContainer 段階を疑う
   -> STATUS が Init:Error なら init 段階の失敗。
   -> kubectl logs <pod> -c <init-container-name>

5. ConfigMap / Secret 欠落
   -> describe Events の "MountVolume.SetUp failed"。
   -> [6章 ConfigMap · Secret](./configmap-and-secret/) の名前一致を確認。

1. kubectl get events -n <ns> --field-selector reason=OOMKilling
   -> どの Pod がいつ OOMKilled されたかの時系列リスト。

2. kubectl describe pod <pod>
   -> Last State -> Terminated -> Reason: OOMKilled, Exit Code: 137。

3. [11章 リソース要求と上限](./resources-and-limits/) の limits.memory 確認
   -> コンテナの実際の使用量が limits を超えた時点で終了。
   -> [25章 モニタリング·アラート](./monitoring-and-alerts/) の
      container_memory_working_set_bytes メトリクスでパターン確認。

4. memory leak を疑う
   -> 時間グラフで右肩上がりの直線ならコードレベルのリーク。
   -> heap profile (Java jmap, Go pprof, Python memray) で追加診断。

5. 誤った limits を疑う
   -> JVM の -Xmx が container limits より大きく設定されている場合がある。
   -> Native ライブラリのメモリ使用は heap 以外に別途。

1. kubectl describe pod <pod>
   -> Events の reason で6つの原因を絞る:

   - "manifest unknown" / "not found"
     -> イメージタグの誤字または ECR へのプッシュ失敗。
        [24章 CI/CD](./cicd-pipeline/) の ECR push 段階を確認。

   - "unauthorized" / "denied"
     -> ECR 権限不足。Node IAM Role の ECR read 権限を確認、
        または imagePullSecret の認証情報を確認。

   - "no basic auth credentials"
     -> imagePullSecret 自体がないか名前の誤字。

   - "x509: certificate signed by unknown authority"
     -> private registry の証明書の信頼問題。

   - "context deadline exceeded"
     -> ネットワーク遅延。NAT Gateway / VPC Endpoint の経路を確認。

   - "ECR repository ... does not exist"
     -> 別の region / 別の account の ECR を指している場合。

1. kubectl describe pod <pod>
   -> Events の default-scheduler メッセージが即座に答えを教えてくれる。

2. "0/N nodes are available: ... Insufficient cpu/memory"
   -> [11章](./resources-and-limits/) の requests がノードの可用量を超過。
   -> [13章 オートスケーリング](./autoscaling/) の Karpenter / Cluster Autoscaler が
      新しいノードを立ち上げている途中か確認。

3. "Insufficient nodes match node selector / affinity"
   -> nodeSelector のラベルキーの誤字、またはそのラベルを持つノードがない。
   -> kubectl get nodes --show-labels でラベル確認。

4. "had taints that the pod didn't tolerate"
   -> ノードの taint と Pod の toleration の不一致。
   -> Karpenter の NodePool が spot のみ立ち上げるのに Pod に toleration なし、など。

5. "pod has unbound immediate PersistentVolumeClaims"
   -> [9章 PV/PVC/StorageClass](./pv-pvc-storageclass/) の動的プロビジョニング失敗。
   -> StorageClass の EBS CSI Driver が正常動作するか確認。

6. Karpenter の応答時間を疑う
   -> 新しいノードのプロビジョニングまで30秒 ~ 2分。
   -> その時間の間 Pending は正常。

1. Pod 自体が ready か?
   -> kubectl get pods -l <selector> -o wide
   -> READY が 1/1 で STATUS が Running か。
   -> readinessProbe が失敗中なら Endpoints から自動除外される。

2. Service の selector が Pod ラベルと一致するか?
   -> kubectl describe service <svc>
   -> kubectl get endpoints <svc> -- Endpoints が空なら selector の不一致。

3. Service の port が Pod の containerPort と合っているか?
   -> targetPort は Pod の中のポート (またはポート名)。
   -> port は Service 自体の仮想ポート。

4. NetworkPolicy が遮っているか?
   -> [14章 RBAC/NetworkPolicy/ResourceQuota](./rbac-networkpolicy-quota/) の ingress ルールを確認。

5. Ingress の ALB が実際に立ち上がったか?
   -> kubectl describe ingress -- Address フィールド。
   -> kubectl logs -n kube-system deployment/aws-load-balancer-controller。
   -> ALB target group の healthy / unhealthy 状態 (AWS コンソール)。

6. DNS 解決自体の点検
   -> kubectl run -it --rm dns-test --image=busybox:1.36 \
        -- nslookup <svc>.<ns>.svc.cluster.local

# 最も軽い一時コンテナ
kubectl run -it --rm net-test --image=busybox:1.36 \
  -n <ns> -- /bin/sh

# フルパッケージ (curl, dig, traceroute, tcpdump, nslookup)
kubectl run -it --rm net-test --image=nicolaka/netshoot \
  -n <ns> -- /bin/bash

# DNS
dig myshop-api.myshop.svc.cluster.local

# HTTP 接続
curl -v http://myshop-api.myshop:80/health/ready

# 経路追跡
traceroute api.myshop.example.com

# ノード IP と Pod IP のルーティング
ip route

kubectl debug node/<node-name> -it --image=nicolaka/netshoot
# その中で:
tcpdump -i any -n 'host <pod-ip>'

[単一 Pod の問題] — describe / logs / events のほうが速い
  - CrashLoopBackOff, ImagePullBackOff, OOMKilled
  - 「特定の Pod 1個だけがダメ」

[分散 / 統計的な問題] — 可観測性スタックのほうが速い
  - 「エラー率が 5% を超える」
  - 「P95 latency が1秒を超える」
  - 「直近1時間比でトラフィック 30%」
  - 事故時点の他のワークロードとの相関

1. PagerDuty / Slack でアラート本文を確認 (alertname, severity, runbook_url)
2. runbook の「一次点検」セクションをたどる
3. Grafana ダッシュボードで事故範囲を確認 (1 Pod / 1 Service / 全体)
4. 範囲が 1 Pod なら kubectl describe + logs --previous
   範囲が 1 Service なら endpoints + NetworkPolicy
   範囲が全体ならノード / CNI / クラスタコンポーネント
5. 一次対応 (スケールアップ、再起動、トラフィック遮断)
6. Slack 事故チャンネルに状態共有 + 事後 RCA 準備