Istio multi-primary multi-cluster同步异常：跨集群服务负载均衡失效排查

核心问题定位 #

从cluster1的istiod日志中failed creating config configStore for cluster cluster2: Get "https://172.26.0.2:8443/apis/apiextensions.k8s.io/v1/customresourcedefinitions": context deadline exceeded这条错误可以确定：cluster1的istiod组件无法成功访问cluster2的Kubernetes API服务器。

这种情况下，istiod无法同步cluster2的服务、端点等配置信息，自然无法实现跨集群的服务版本负载均衡。

可能的诱因 #

• 远程密钥配置错误：生成的istio-remote-secret-cluster2中，cluster2的API地址使用了集群内部私有IP（如172.26.0.2），而cluster1的istiod所在网络无法直接访问该内部地址——你提到测试Pod能访问cluster2 API，大概率是测试Pod用的是cluster2 API的外部可访问地址（如LoadBalancer地址），但远程密钥里配置的是内部地址。
• 网络权限限制：cluster1的istio-system命名空间存在网络策略/防火墙规则，阻止了istiod Pod访问cluster2的API服务器8443端口；而测试Pod所在的命名空间没有这类限制，所以能正常访问。
• TLS证书问题：cluster2的API服务器TLS证书配置不符合要求（如SAN不包含访问地址、证书未被cluster1的istiod信任），导致连接过程中出现隐性中断，表现为请求超时。
• 集群间网络不稳定：网络延迟过高或存在丢包，导致istiod的API请求超时。

排查建议 #

1. 检查远程密钥配置：查看istio-system/istio-remote-secret-cluster2 Secret中的内容，确认cluster2的API地址是否为cluster1可访问的外部地址（如API的LoadBalancer地址）。
2. 直接在istiod Pod内测试连通性：

   # 进入cluster1的istiod Pod
   kubectl exec -n istio-system <istiod-pod-name> -- /bin/bash
   # 测试访问cluster2的API
   curl -v https://172.26.0.2:8443/apis/apiextensions.k8s.io/v1/customresourcedefinitions
   

   观察是否能正常获取响应，以此确认网络连通性。
3. 检查网络策略与防火墙：确认cluster1和cluster2之间的防火墙允许istio-system命名空间的Pod访问cluster2 API的8443端口；同时检查cluster1内的网络策略，是否存在限制istiod对外访问的规则。
4. 验证TLS证书有效性：检查cluster2 API服务器的TLS证书，确认其包含正确的访问地址SAN，且cluster1的istiod信任该证书的根CA。

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