AKS 在 Azure CNI Pod Subnet 模式下的流量路由

在排查一个 AKS Pod 的网络出站流量时，我发现了一个奇怪的现象：

Node 所在子网：nodes（没有关联 NAT Gateway）
Pod 出站出口 IP：匹配的是子网 pods 上绑定的 NAT Gateway 公网 IP。

为什么 Node 所在子网明明没有挂载 NAT Gateway，运行在它上面的 Pod 出网却走到了另一个子网的 NAT Gateway？

排查过程与原因

第一反应是去 Azure Portal 检查 AKS 的网络配置，但在 Portal UI 的集群和 NodePool 页面上，只展示了 Node 所在的子网（nodes），完全找不到 pods 的影子。

为了搞清楚真相，我导出了 AKS 节点的底层资源 JSON 属性（或通过 Azure CLI 查看）。最终在 agentPoolProfiles 配置中找到了答案：

"agentPoolProfiles": [
  {
    "name": "nodepool1",
    "vnetSubnetID": "/subscriptions/.../subnets/nodes",
    "podSubnetID": "/subscriptions/.../subnets/pods"
  }
]

结合 Networking 页面，可以确认集群使用的是 Azure CNI Pod Subnet（动态 IP 分配）模式。

在该模式下，AKS 会将 Node 与 Pod 的 IP 分离在两个不同的子网中：

Node Subnet：专门为 VMSS 节点分配 IP（例如 nodes）。
Pod Subnet：专门为 Pod 动态分配 Azure VNet 内的真实 IP（例如 pods）。

在物理网络层面，流量的路由逻辑是：流量从谁所在的子网吐出，就走哪个子网绑定的路由/NAT Gateway规则。

因此，即便 Node 所在的子网没有绑定 NAT Gateway，只要 Pod Subnet 绑定了 NAT Gateway，Pod 的公网请求就会直接从 Pod Subnet 吐出，带上该 NAT Gateway 的出口 IP。

横向对比：其他 AKS 网络模式的流量出口行为

以下是 Gemini 给出的不同网络模式的对比：

网络模式	Pod 的 IP 来源	物理网络出口归属	公网出站行为逻辑
Azure CNI Pod Subnet	Pod 专用子网 (`pods`)	Pod Subnet	流量直接从 Pod 子网发出，只受 Pod 子网的 NAT Gateway / UDR 路由控制，忽略 Node 子网的配置。
Azure CNI（标准模式）	Node 节点子网 (`nodes`)	Node Subnet	Pod 和 Node 共享同一个物理子网，Pod 的出站出口 IP 完全取决于 Node 子网绑定了什么（如 NAT Gateway 或负载均衡器）。
Azure CNI Overlay	集群内部虚拟网段 (如 `10.244.0.0/16`)	Node Subnet	Pod IP 在 VNet 中不存在。流量在发出宿主机前会被 Node 做一层 SNAT（源地址改写为 Node IP），出口完全受 Node 子网的路由和 NAT 策略控制。
Kubenet	集群内部虚拟网段	Node Subnet	同样采用 Node 侧 SNAT 机制，出口流量完全依赖 Node 子网的出口路由配置。

总结与踩坑心得

出口由底层物理网卡子网决定：在 Azure CNI Pod Subnet 模式下，Pod 拥有真实的 VNet 子网身份。决定 Pod 出站 IP 的是 podSubnetID 绑定的规则，而非 vnetSubnetID（Node 子网）。
Azure Portal UI 并不展示全貌：Portal 界面有时会隐去 podSubnetID 这种高级网络配置。当发现网络行为与 UI 显示不符时，直接查看 ARM Resource JSON 或使用 Azure CLI 查询 agentPoolProfiles 才是最准确的依据。