Kubernetes DevOps面接17問：アーキテクチャ・トラブルシューティング

問題¶

The moment you mention Kubernetes in a Devops interview, expect a deep dive Here are 17 Kubernetes questions I was asked that dive into architecture, troubleshooting, and real-world decision-making: 1. Your pod keeps getting stuck in CrashLoopBackOff, but logs show...（以下続く）

解答と解説¶

Q1: Pod が CrashLoopBackOff になっている。ログは正常に見える。何を確認するか？¶

確認順序:

# 1. 直近のイベントを確認
kubectl describe pod <pod-name>

# 2. 前回クラッシュ時のログを確認
kubectl logs <pod-name> --previous

# 3. リソース制限の確認 (OOMKilled の可能性)
kubectl top pod <pod-name>

よくある原因: OOMKilled（メモリ超過）、Liveness probe の失敗、設定ファイルの参照エラー、依存サービスへの接続失敗

Q2: ノードが NotReady になった。どうデバッグするか？¶

# kubelet の状態確認
systemctl status kubelet

# ノードのイベント確認
kubectl describe node <node-name>

# ディスク容量・メモリ確認
kubectl top nodes
df -h  # ノードにSSHして確認

Q3: Deployment のローリングアップデート中に新バージョンに問題があった。どうロールバックするか？¶

# ロールバック
kubectl rollout undo deployment/<name>

# 特定バージョンにロールバック
kubectl rollout history deployment/<name>
kubectl rollout undo deployment/<name> --to-revision=2

# ロールアウト状態の確認
kubectl rollout status deployment/<name>

Q4: Pod 間通信ができない。原因の切り分け方は？¶

NetworkPolicy の確認 → DNS → CNI プラグインの順で確認

# DNS 動作確認
kubectl run debug --image=busybox --rm -it -- nslookup <service-name>

# サービスのエンドポイント確認
kubectl get endpoints <service-name>

# NetworkPolicy の確認
kubectl get networkpolicy -n <namespace>

Q5: HPA（Horizontal Pod Autoscaler）が動いていない。なぜ？¶

よくある原因: - metrics-server がインストールされていない - Pod の resources.requests が設定されていない（HPA はこれを基準にスケール） - カスタムメトリクスの場合は kube-adapter の設定が必要

# HPA が正しく動くための Pod 設定
resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

Q6: Kubernetes の etcd とは何か。なぜ重要か？¶

etcd はクラスタの全状態（Pod、Service、ConfigMap など）を保存する分散 KV ストア。etcd が落ちるとクラスタが機能しなくなるため、定期バックアップが必須。

# etcd のバックアップ
ETCDCTL_API=3 etcdctl snapshot save backup.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

Q7: PodDisruptionBudget（PDB）とは何か。いつ設定するか？¶

ノードのドレインやローリングアップデート時に、最低限稼働し続けるべき Pod 数を保証する設定。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2  # 常に最低2Pod は稼働
  selector:
    matchLabels:
      app: my-app

その他の頻出テーマ（Q8〜Q17）¶

Ingress vs LoadBalancer Service: コスト・機能の違い
StatefulSet vs Deployment: ステートフルなアプリ（DB）への対応
ConfigMap vs Secret: 機密情報の扱い方（Secret は base64 エンコードのみで暗号化ではない点に注意）
Namespace の分離戦略: 環境分離 vs サービス分離
Resource Quota と LimitRange: クラスタリソースの公平な割り当て
ServiceAccount と RBAC: 最小権限原則
Helm チャートの管理: アップグレードと rollback
マルチクラスタ戦略: Federation、Argo CD での GitOps
コンテナイメージのセキュリティ: trivy によるスキャン、Pod Security Standards
ログ収集設計: DaemonSet で fluentd/fluent-bit をデプロイする構成

面接でのポイント¶

「なぜ」を常に問われる: ツールの名前だけでなく、「なぜその設計か」「トレードオフは何か」を答える
実務エピソードを持つ: CrashLoopBackOff をどう解決したか、具体的な経験談を混ぜる
CKAD/CKA の取得は有効: 面接前の実力証明として認知度が高い