AZ700-CORE#90
AKS (Azure Kubernetes Service) のネットワーク モデル「Azure CNI」と「Kubenet」を比較した時、Azure CNI の特徴はどれですか?
解説
【正解: A】の理由
Azure CNI (Container Network Interface) では各 Pod が VNet サブネットの IP を直接取得し、VNet 内の VM、Private Endpoint、Service Bus 等に NAT なしで直接通信できます。Kubenet は Pod が VNet 外のオーバーレイ ネットワーク IP を使い、ノード経由で NAT する仕組みのため、VNet 内 PaaS との直接通信は不可です。
【ネットワーク モデル 比較】
| 項目 | Kubenet | Azure CNI | Azure CNI Overlay |
|---|---|---|---|
| Pod IP | オーバーレイ範囲 | VNet サブネット IP | オーバーレイ範囲 |
| VNet 内リソース直接通信 | × (NAT 経由) | ○ | △ (条件付き) |
| 必要 IP 数 | 少ない | 多い (Pod × Node 数) | 少ない |
| サブネット サイズ | /24 で十分 | 大規模 /22 等 | /24 で十分 |
| Network Policy | Calico のみ | Calico / Azure / Cilium | Calico / Cilium |
| パフォーマンス | NAT オーバーヘッド | 最高 | 最高 (オーバーヘッド最小) |
| 用途 | 小規模、シンプル | 大規模、PaaS 統合 | 大規模、IP 節約 |
【Azure CNI の IP 計画】
- Pod IP がサブネットから消費されるため、サブネット サイズを Pod 数で見積もる
- ノード あたり Max Pods (既定 30) × Node 数 + Node 自身の IP + バッファ
- 例: 100 Node + 30 Pods/Node = 3,000 + 100 + 余裕 = /20 (4096 IP)
- サブネット サイズ過小だと Pod 起動失敗
【Azure CNI Overlay (最新 推奨)】
- 2023 年 GA の新モード、CNI の利点 (Network Policy 等) + Kubenet の IP 効率を両立
- Pod はオーバーレイ範囲 (任意 CIDR、例: 192.168.0.0/16) の IP
- Node は VNet サブネット IP
- 大規模クラスタ (10,000 Pod 以上) で推奨
【他選択肢が違う理由】
- B. NAT 経由のみ: これは Kubenet の動作で、CNI ではない。
- C. CNI 旧式: 逆、CNI が現代的な標準です。Kubenet は廃止予定。
- D. Windows 非対応: CNI は Windows ノードもサポート (Kubenet が一部 Windows 非対応)。
コメント