AKS运行k6压测遇dial tcp I/O超时，本地/虚拟机运行正常

• 核心差异明确：AKS环境下请求全部超时失败，本地/虚拟机有60%通过率，说明AKS集群到目标服务的网络通路存在严格限制，而非目标服务本身的性能瓶颈。以下是针对性排查步骤：

1. 检查AKS集群的出站网络规则 #

• 确认AKS网络模式：
  • 若用Azure CNI，节点出站流量受子网关联的网络安全组（NSG）和路由表控制；
  • 若用Kubenet，出站流量通常走负载均衡器公网IP，需检查负载均衡器出站规则及路由表。
• 排查对应NSG的出站规则：确保存在允许访问目标服务IP/端口的规则，且无优先级更高的"拒绝所有出站"规则拦截流量。
• 检查子网路由表：确认未将目标服务流量导向未配置对应权限的防火墙、NAT网关等设备。

2. 验证AKS内部到目标服务的连通性 #

• 在AKS集群创建临时测试Pod，直接测试网络连通性：

  kubectl run -it --rm --image=curlimages/curl curl-test
  

• 进入Pod后，用telnet <目标IP> <端口>或curl -v <目标URL>测试，观察是否同样超时：
  • 若Pod内也无法连通，可确定是集群层面的网络限制；
  • 若Pod内能正常连通，则排查k6 Pod的网络策略或配置问题。

3. 检查AKS网络策略 #

• 若集群启用了Calico或Azure原生网络策略，检查k6所在Namespace或Pod是否被策略限制出站流量：
  • 查看当前生效的网络策略：kubectl get networkpolicies -n <k6-namespace>
  • 可临时删除或禁用可疑策略，重新运行k6测试验证结果。

4. 确认目标服务的访问控制 #

• 检查目标服务的防火墙、安全组或WAF规则：是否仅允许本地/虚拟机的IP段访问，而AKS集群的出站公网IP未加入白名单。
• 获取AKS的出站公网IP：
  • Azure CNI模式：查看节点公网IP；
  • Kubenet模式：查看负载均衡器公网IP；
• 将这些IP添加到目标服务白名单后，重新测试。

5. 排查k6配置差异 #

• 对比本地与AKS环境的k6脚本/配置：是否存在代理设置、超时时间、目标地址解析等差异。
• 在k6 Pod内执行nslookup <目标域名>，验证DNS解析是否正确，排除域名解析失败导致的超时。

内容的提问来源于stack exchange，提问作者Andrés