1. ネットワークトラブルシューティングワークフロー
ネットワーク接続性の問題:
Pod AがPod B（またはService）に到達できない
レイヤーごとのデバッグ:
1. 同じノード、同じNamespace？
kubectl exec pod-a -- ping POD_B_IP
2. 異なるノード？
kubectl get pod pod-a pod-b -o wide # ノード配置を確認
3. Service名（DNS）経由？
kubectl exec pod-a -- nslookup my-service
kubectl exec pod-a -- wget -qO- http://my-service:8080
4. NetworkPolicyがブロック？
kubectl get networkpolicy -n NAMESPACE
5. kube-proxyが動作中？
kubectl get pods -n kube-system -l k8s-app=kube-proxy2. フルネットワークフロー図
クライアントPod ──(ルーティング)──► Service ClusterIP (iptables/ipvs)
│
kube-proxyが以下のいずれかにルーティング:
Pod IP 1 | Pod IP 2 | Pod IP 3
│
CNI (Calico/Flannel)がクロスノードの場合
正しいノードにルーティング
│
コンテナがcontainerPortで受信| 障害コンポーネント | 症状 | 対処法 |
|---|---|---|
| CoreDNS | DNS解決失敗 | CoreDNS Podを再起動 |
| kube-proxy | Service IPに到達不能 | kube-proxy DaemonSetを再起動 |
| CNIプラグイン | クロスノードPod通信失敗 | CNIの再インストールまたはCNI Podを確認 |
| NetworkPolicy | 特定のトラフィックがブロック | ブロックしているポリシーを確認/削除 |
試験のポイント：ネットワーキングをデバッグする際は、Pod内部から開始（IPで到達可能か？）→ Service（DNS + Endpoints？）→ ノード（CNIルーティング？）→ NetworkPolicy。DNSをテストせずにいきなりkube-proxyを確認しないでください。
3. CKA試験戦略
| ヒント | 詳細 |
|---|---|
| すぐにコンテキストを切り替え | 各問題はクラスタを指定 → kubectl config use-context CLUSTER |
| --dry-runを使用 | kubectl create deploy --dry-run=client -o yaml > file.yamlでYAMLを生成 |
| explainを使用 | kubectl explain pod.spec.containers.resourcesでフィールドヘルプ |
| 素早くブックマーク | YAMLテンプレートが必要な時はKubernetes docs検索を使用 |
| 難問はスキップ | マークして後で戻る；簡単な問題から先に（30%のトラブルシューティング = 最多配点） |
| 完了後に検証 | kubectl get/describeで変更が反映されたか確認 |
4. 必須kubectlショートカット
# 時間節約のためのエイリアス
alias k=kubectl
alias kgp='kubectl get pods'
alias kgs='kubectl get svc'
alias kns='kubectl config set-context --current --namespace'
# リソース短縮名
po = pods
svc = services
deploy = deployments
ns = namespaces
cm = configmaps
pvc = persistentvolumeclaims
pv = persistentvolumes
rs = replicasets
sa = serviceaccounts
no = nodes
# よく使うフラグ
-n NAMESPACE --namespace
-o wide 詳細出力（IP、Node）
-o yaml 完全YAML出力
-o jsonpath 特定フィールドの抽出
--all-namespaces / -A 全Namespaceで検索5. CKA必須コマンド
# dry-runでYAML生成
kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml
kubectl create deployment myapp --image=myapp --replicas=3 --dry-run=client -o yaml
# フィールドの抽出
kubectl get node NODENAME -o jsonpath='{.status.capacity.cpu}'
kubectl get pod PODNAME -o jsonpath='{.status.podIP}'
# フィールドでソート
kubectl get events --sort-by='.lastTimestamp'
kubectl get pods --sort-by='.status.startTime'
# リソースのウォッチ
kubectl get pods -w
# 全Namespace
kubectl get pods -A
kubectl get pods -A | grep CrashLoop6. CKAクイックリファレンス
| ドメイン（配点） | 主要トピック |
|---|---|
| Cluster Architecture (25%) | kubeadm、静的Pod、kubeconfig、RBAC |
| Workloads (15%) | Deployments、rollout、DaemonSet、StatefulSet、スケジューリング |
| Services & Networking (20%) | Services、Ingress、NetworkPolicy、DNS |
| Storage (10%) | PV、PVC、StorageClass、ボリュームマウント |
| Troubleshooting (30%) | ノード、ワークロード、ネットワークデバッグ — 最高配点 |
7. 練習問題
Q1：PodがService名で到達できませんがIP直接では成功します。DNS解決が失敗しています。CoreDNS Podは実行中です。何を確認すべきですか？
- A) kube-proxyの設定
- B) Podの/etc/resolv.confのnameserverエントリ ✓
- C) ノードのiptablesルール
- D) ServiceのtargetPort
解説：IPでは到達可能だがDNSが失敗する場合、PodがCoreDNSサーバーを使用していません。Pod内の/etc/resolv.confを確認 — kube-dns ClusterIPがnameserverとして表示されるべきです。表示されない場合、PodのdnsPolicyまたはdnsConfigがデフォルトをオーバーライドしている可能性があります。
Q2：CKA試験で新しい問題に取り組む際、最初に必ず行うことは？
- A) そのトピックのKubernetesドキュメントを読む
- B) kubectl config use-contextで正しいクラスタコンテキストに切り替える ✓
- C) 現在のクラスタ状態のバックアップを作成する
- D) クラスタの既存リソースを確認する
解説：CKAは複数のクラスタを使用します。各問題はクラスタを指定します。まずコンテキストを切り替えてください — 間違ったクラスタで作業すると、完璧に実行しても不合格になります。これが試験での#1のミスです。
Q3：Deployment「webapp」をポート80でNodePort Serviceとして外部に公開する最速の方法は？
- A) Service YAMLを記述してkubectl applyする
- B) kubectl expose deployment webapp --type=NodePort --port=80 ✓
- C) kubectl create service nodeport webapp --tcp=80:80
- D) Deployment YAMLを編集してhostPortを追加する
解説：kubectl exposeが最速です — Deploymentの既存セレクタを使用してPodをターゲットにするServiceを作成します。YAML編集が不要です。選択肢Cも動作しますが、Deploymentの既存セレクタを使用しません。