同虚拟网络下跨AKS集群Pod通信失败（仅允许VNet通信）

一、检查AKS网络插件与子网配置 #

• 确认两个AKS集群使用相同的网络插件（Azure CNI或Kubenet）。混合使用不同插件会导致Pod IP不在同一VNet地址空间内，VNet级规则无法生效。
• 若使用Azure CNI，验证两个集群的Pod/节点子网地址范围属于VNet总地址空间，且无重叠。

二、验证NSG规则的有效性 #

• 检查规则优先级：允许VNet内通信的规则优先级需高于拒绝所有连接的规则（数字越小优先级越高）。例如允许规则设为100，拒绝规则设为1000，确保前者先匹配。
• 确认源/目标地址范围：允许规则的源应设为VNet完整地址前缀（如10.0.0.0/16），目标覆盖健康服务所在的Pod/节点子网范围，避免仅指定单一子网导致跨子网流量被拦截。
• 检查NSG关联对象：确认NSG同时关联了节点子网和Pod子网（若Azure CNI使用独立Pod子网）。部分AKS部署会自动为Pod子网创建独立NSG，需同步配置允许VNet内通信的规则。

三、排查DNS解析问题 #

• 在新AKS集群的Pod内执行 nslookup <your-domain>，确认解析结果为健康服务的VNet内IP（而非公网IP）。若解析到公网IP，说明流量会走公网路径，VNet规则无法匹配：
  • 检查自定义DNS配置，避免域名被解析到公网端点；若使用Azure DNS，确认私有DNS区域已关联VNet，且记录指向服务的ClusterIP/Pod IP。
• 尝试直接访问健康服务的ClusterIP（curl http://<cluster-ip>:<port>/health），排除域名解析的干扰。

四、检查Kubernetes网络策略限制 #

• 查看旧AKS集群中健康服务所在Namespace的网络策略：kubectl get networkpolicies -n <health-service-namespace>
• 若存在限制策略，确认是否仅允许本集群内的Pod/Namespace访问。需添加规则允许新AKS集群的Pod IP范围或Namespace标签。

五、验证路由与流量捕获 #

• 在新AKS集群节点上执行 route -n，确认到旧集群Pod/子网的流量路由指向VNet内部网关，而非公网网关。
• 在旧AKS集群的节点或Pod上执行 tcpdump port <health-port>，检查是否收到新集群的流量：
  • 无流量：说明流量在节点层被NSG或路由拦截；
  • 有流量但无响应：检查健康服务的监听地址是否为0.0.0.0（而非仅localhost）。

六、检查LoadBalancer配置（若使用） #

• 若健康服务通过LoadBalancer暴露，确认启用的是内部LoadBalancer。公网LoadBalancer会导致VNet内流量先出公网再回流，此时VNet规则不生效，需切换为内部LB确保流量在VNet内流转。

内容的提问来源于stack exchange，提问作者SQLProfiler