3. AKS网络模型
在 AKS 中，“网络模型”并不是一个单一开关，而是由三层决策叠加而成：Pod 地址从哪里来（CNI 模式）、Pod 之间与 Pod 到外部如何转发（数据平面）、南北向流量如何进入集群（Ingress 或网关）。这三层选错任意一层，都会在后期表现为 IP 耗尽、跨节点延迟异常、NetworkPolicy 不生效或入口链路难以观测。本节按“先定地址模型，再定数据平面，最后定入口”的顺序展开。
一、四种 CNI 模式的本质差异
Kubenet 是最早的默认模式。节点从 VNet 子网获得一个 IP，Pod 使用节点内独立的逻辑网段（如 10.244.0.0/24），出节点时通过 NAT 转换。它的优点是节省 VNet 地址，缺点是 Pod IP 在 VNet 中不可路由，跨节点通信需要路由表或 UDR 配合，且不支持 Windows 节点池与部分高级特性。
Azure CNI（传统模式） 让每个 Pod 直接从 VNet 子网分配 IP，Pod IP 在 VNet 内原生可路由，可直接被本地网络、对等 VNet 或防火墙访问。代价是地址消耗大：若节点池子网为 /24（254 个可用地址），按每节点 30 个 Pod 计算，实际只能容纳约 8 个节点。规划时必须用“节点数 ×（1 + maxPods）”估算子网大小。
Azure CNI Overlay 是折中方案：节点仍占用 VNet IP，Pod 使用独立的 Overlay 私有网段（如 10.244.0.0/16），通过隧道封装在节点间传输。Pod IP 不消耗 VNet 地址，因此子网只需按节点数量规划；同时支持 NetworkPolicy 与 Windows 节点池。需要注意的是，Overlay Pod IP 默认不能从 VNet 外部直接访问，跨 VNet 通信需借助网关或 Load Balancer。
Cilium（Azure CNI Powered by Cilium） 在 Azure CNI 之上用 eBPF 替换 kube-proxy 与部分 iptables 链路，提供更高的转发性能、更细的 NetworkPolicy（含 L7 与 FQDN 策略）以及 Hubble 可观测性。它既可与传统 Azure CNI 结合，也可与 Overlay 结合使用。
二、如何选择：三个判断问题
第一问：Pod 是否需要被 VNet 外部直接访问？若需要（例如本地数据中心通过 ExpressRoute 直连 Pod、或防火墙需按 Pod IP 做策略），选 Azure CNI 或 Cilium + Azure CNI；若不需要，Overlay 更省地址。
第二问：子网地址是否紧张？若 VNet 地址段有限、节点规模大，Overlay 是首选。示例：计划 50 个节点、每节点 30 Pod，传统 Azure CNI 需要 50×31≈1550 个 IP，至少 /21；Overlay 只需 50 个节点 IP，/26 即可。
第三问：是否需要 L7 策略与流级可观测？若需要按域名或 HTTP 路径限制出站、或要求 Hubble 级别的调用链观测，选 Cilium。
三、创建集群时的关键参数
# Azure CNI Overlay + Cilium 示例
az aks create \
--resource-group rg-aks-prod \
--name aks-prod \
--network-plugin azure \
--network-plugin-mode overlay \
--pod-cidr 10.244.0.0/16 \
--network-dataplane cilium \
--node-count 3 \
--max-pods 30 \
--vnet-subnet-id /subscriptions/.../subnets/snet-aks
# 传统 Azure CNI（Pod 直接占 VNet IP）
az aks create \
--network-plugin azure \
--network-plugin-mode default \
--vnet-subnet-id /subscriptions/.../subnets/snet-aks注意 --pod-cidr 不能与 VNet 网段重叠，且创建后不可更改；--network-dataplane cilium 只能在创建时指定，已有集群无法从 kube-proxy 切换到 Cilium。若使用 Overlay，节点池子网按节点数规划即可，但需为 --pod-cidr 预留足够空间（如 /16 可容纳约 6.5 万 Pod）。
四、Ingress 与网关方案的选择
南北向入口有三条主流路径：NGINX Ingress Controller（成熟、注解丰富、社区生态大）、Application Gateway Ingress Controller（AGIC）（直接使用 Azure 应用网关的 WAF、TLS 卸载与自动扩缩）、Gateway API + Istio/Envoy（面向多团队、多协议、细粒度路由）。选择依据是：是否需要 WAF 与 Azure 原生集成（选 AGIC）、是否需要复杂 L7 路由与 mTLS（选 Gateway API）、是否追求最低迁移成本（选 NGINX）。
一个常见组合是：外部入口用 AGIC 承接公网流量并启用 WAF，集群内部东西向用 Cilium 做 L7 策略与可观测，两者通过 Service 与 NetworkPolicy 衔接。部署后应验证：kubectl get pods -n kube-system 确认 cilium-agent 与 ingress controller 均 Running；用 kubectl run 起一个临时 Pod，kubectl exec 内 curl 目标 Service 的 ClusterIP 与外部域名，分别验证东西向与南北向链路；再用 hubble observe 查看实际流日志，确认策略命中与丢包位置。