レッスン10: NetworkPolicies & CKAD試験戦略

1. NetworkPolicy

デフォルトでは、クラスター内のすべてのPodが相互に通信できます。NetworkPolicyはラベルに基づいてトラフィックを制限します。

デフォルト: 全PodがすべてのPodと通信可能（制限なし）

default-deny-all適用後:
  Pod A ──✗──► Pod B（ブロック）
  Pod A ──✗──► Pod C（ブロック）

allowポリシー適用後:
  Pod A (app=frontend) ──✓──► Pod B (app=backend, port 3000)
  Pod A ──✗──► Pod C (app=database)（依然ブロック）

2. NetworkPolicy構文

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
  namespace: production
spec:
  podSelector:         # これらのPodに適用（空 = NS内の全Pod）
    matchLabels:
      app: backend
  policyTypes:
  - Ingress            # インバウンドトラフィックを制御
  - Egress             # アウトバウンドトラフィックを制御
  ingress:
  - from:
    - podSelector:     # このラベルのPodからの通信を許可
        matchLabels:
          app: frontend
    - namespaceSelector: # このNamespaceのPodからの通信を許可
        matchLabels:
          name: production
    ports:
    - protocol: TCP
      port: 3000
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

試験のポイント — NetworkPolicyのAND vs OR:
from: [{podSelector}, {namespaceSelector}] = OR（いずれかのselectorに一致するPod）
from: [{podSelector + namespaceSelector}] 同じアイテム内 = AND（両方に一致するPod）
CKADで最もトリッキーなひっかけ問題の一つです。

3. よく使われるパターン

パターン1: 全ingressをデフォルト拒否
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}     # 空 = 全Podに一致
  policyTypes:
  - Ingress
  # ingressルールなし = 全ingressを拒否

パターン2: 全トラフィックをデフォルト拒否（ingress + egress両方）
---
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  # ルールなし = 全拒否

パターン3: 全ingressを許可（denyをオーバーライド）
---
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - {}  # 空のルール = 全ingressを許可

パターン	policyTypes	ルール	効果
全ingress拒否	[Ingress]	ingressルールなし	全インバウンドをブロック
全egress拒否	[Egress]	egressルールなし	全アウトバウンドをブロック
特定を許可	[Ingress]	ingressルールを列挙	一致するもののみ許可
DNS egressを許可	[Egress]	ポート53（UDP+TCP）宛て	DNSクエリを許可

試験のポイント: NetworkPolicyはCNIプラグインがサポートしている場合のみ動作します（Calico、Cilium、Weave）。FlannelはNetworkPolicyをサポートしません！ Ingress/Egressルールは加算的 — 同じPodに複数のポリシーが適用される場合、KubernetesはすべてのルールをOR結合します。

4. CKAD試験戦略

試験情報:
- 2時間、約15-20のハンズオンタスク（パフォーマンスベース）
- 各タスクの配点が異なる（配点の高いタスクを優先）
- 合格点: 66%
- 参照可能: kubernetes.io/docs + helm.sh/docs

重要なキーボードショートカット:
  k = kubectl（試験でexport alias k=kubectlが事前設定済み）
  CTRL+R = コマンド履歴を検索
  CTRL+A = 行頭に移動

各タスクのワークフロー:

1. タスク説明を注意深く読む（Namespaceに注意！）
2. 必要に応じてcontextを切り替え:
   kubectl config use-context cluster-name
3. Namespaceショートカットを設定:
   export ns=target-namespace
   alias kn="kubectl -n $ns"
4. --dry-run=client -o yamlでYAMLを生成:
   kubectl run pod --image=nginx --dry-run=client -o yaml > pod.yaml
5. YAMLを編集、apply、確認:
   kubectl apply -f pod.yaml
   kubectl get pods -n $ns

5. --dry-runパターン

# 手書きより速くYAMLテンプレートを生成:

Pod:
  kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml

Deployment:
  kubectl create deployment myapp --image=nginx --replicas=3 \
    --dry-run=client -o yaml > deploy.yaml

Service（ClusterIP）:
  kubectl create service clusterip myapp --tcp=80:8080 \
    --dry-run=client -o yaml > svc.yaml

ConfigMap:
  kubectl create configmap myconfig --from-literal=k=v \
    --dry-run=client -o yaml > cm.yaml

Secret:
  kubectl create secret generic mysecret --from-literal=pass=secret \
    --dry-run=client -o yaml > secret.yaml

Job:
  kubectl create job myjob --image=busybox -- echo hello \
    --dry-run=client -o yaml > job.yaml

CronJob:
  kubectl create cronjob mycron --image=busybox --schedule="*/1 * * * *" \
    -- echo hello --dry-run=client -o yaml > cron.yaml

6. 必須kubectlショートカット

フルコマンド	短縮形
kubectl get pods	k get po
kubectl get deployments	k get deploy
kubectl get services	k get svc
kubectl get namespaces	k get ns
kubectl get persistentvolumeclaims	k get pvc
kubectl get configmaps	k get cm
kubectl get serviceaccounts	k get sa
kubectl get networkpolicies	k get netpol
kubectl describe pod mypod	k describe po mypod
kubectl delete pod mypod --force	k delete po mypod --force

7. 最終CKADチートシート

ドメイン	主要トピック	配点
App Design & Build	マルチコンテナ、Init Containers、Jobs、CronJobs、ボリューム	20%
App Deployment	Rolling updates、rollbacks、Helm、Kustomize	20%
App Observability	Probes（liveness/readiness/startup）、logs、debug	15%
App Env/Config/Security	ConfigMaps、Secrets、SecurityContext、SA、Resources、QoS	25%
Services & Networking	Services、Ingress、NetworkPolicies	20%

8. 練習問題

Q1: podSelector: {} と policyTypes: [Ingress] のNetworkPolicyを適用しましたが、ingressルールはありません。何が起こりますか？

• A) 全ingressトラフィックが許可される（ルールなし = 制限なし）
• B) Namespace内の全Podへの全ingressトラフィックが拒否される ✓
• C) 全Podが削除される
• D) 外部ingressのみ拒否、内部Pod間通信は許可

解説: podSelector: {} はNamespace内の全Podに一致します。policyTypes: [Ingress] はこのポリシーがingressを制御することを示します。ingressルールがないということは、ゼロのトラフィックが許可されることを意味します。これが「全ingressをデフォルト拒否」パターンです。ソースに関係なく、クラスター内のPod間通信も拒否されます。

Q2: NetworkPolicyの以下の2つのfrom句の違いは何ですか？
句A: from: [{podSelector: {app: web}}, {namespaceSelector: {env: prod}}]
句B: from: [{podSelector: {app: web}, namespaceSelector: {env: prod}}]

• A) 同じ意味
• B) 句A: app=webのPodから、またはenv=prod Namespaceの任意のPodからの通信を許可。句B: env=prod Namespaceに属するapp=webのPodからのみ許可 ✓
• C) 句AがANDロジック、句BがORロジック
• D) 句Bは無効なYAML構文

解説: NetworkPolicyでは、podSelectorとnamespaceSelectorが別々のリストアイテム（-で区切られている）にある場合はORロジックです。同じリストアイテム（同じインデントレベル、-なし）にある場合はANDロジックです。これは重要な違いであり、試験でのよくあるひっかけ問題です。

Q3: CKAD試験中に特定のPod specを持つDeploymentを作成する必要があります。最速のアプローチはどれですか？

• A) 暗記でYAML全体を手書き
• B) kubernetes.ioドキュメントからサンプルYAMLを検索してコピー&ペースト
• C) kubectl create deployment --dry-run=client -o yamlでテンプレートを生成して編集 ✓
• D) Helmでデフォルト値のチャートをデプロイ

解説: --dry-run=client -o yaml パターンはリソースを作成せずに有効なYAMLを生成します。ファイルにリダイレクトし、異なるフィールドのみ編集して適用します。手動YAML作成より速く、構文エラーの可能性も低くなります。> file.yamlとの組み合わせで正確な編集が可能です。