Istio 1.14 AKS集群出站HTTPS流量故障排查求助

从现象来看，Cluster 2在ALLOW_ANY模式下HTTPS出站请求失败，但添加ServiceEntry后恢复正常，结合Istio配置一致的前提，问题大概率与集群网络配置相关，而非Istio自身配置问题。优先排查以下内容：

1. 集群节点层面的出站网络限制 #

• 检查Cluster 2节点的NSG（网络安全组）规则，确认是否允许443端口的出站流量，对比Cluster 1的NSG配置差异
• 在Cluster 2的节点上直接执行curl https://www.google.com，验证节点本身能否正常访问外部HTTPS服务，排除节点级别的网络阻塞

2. Istio Sidecar的DNS解析能力 #

• 进入Cluster 2中注入了istio-proxy的Pod，执行nslookup www.google.com，查看域名解析是否正常，对比Cluster 1的解析结果
• 检查sidecar容器内的/etc/resolv.conf配置，确认DNS服务器地址是否与Cluster 1一致，排查是否存在DNS解析失败的情况

3. 集群的出站代理配置差异 #

• 对比两个集群的Pod环境变量，检查Cluster 2是否配置了HTTP_PROXY/HTTPS_PROXY变量，但Istio sidecar未正确继承这些代理配置
• 验证非注入sidecar的Pod在Cluster 2中能否正常发起HTTPS请求，判断是否是代理配置导致的sidecar流量异常

4. Istio Sidecar的流量拦截日志分析 #

• 在Cluster 2的sidecar容器中开启debug日志：

  kubectl exec <目标Pod名称> -c istio-proxy -- curl -X POST http://localhost:15000/logging?level=debug
  

• 执行失败的curl https://www.google.com请求后，查看sidecar日志：

  kubectl logs <目标Pod名称> -c istio-proxy
  

  重点查找HTTPS流量的拦截、转发错误信息，比如连接超时、SSL握手失败等细节

5. 集群CNI插件配置差异 #

• 确认两个AKS集群使用的CNI插件是否一致（如Azure CNI或Kubenet），不同CNI的流量拦截逻辑可能存在差异
• 在Cluster 2中创建一个未注入istio-proxy的Pod，执行curl https://www.google.com，验证Pod网络本身的HTTPS访问能力

6. 节点内核参数与网络工具差异 #

• 对比Cluster 1和Cluster 2节点的内核参数，重点检查与TCP/SSL相关的配置（如tcp_tw_reuse、SSL加密套件设置等）
• 排查Cluster 2节点是否安装了影响SSL连接的第三方工具，比如透明代理、SSL拦截设备等

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