GKE多集群服务跨集群导出异常：从gke-2/3到gke-1调用报503

以下是针对该场景的分步排查方案：

1. 确认VPC Peering双向连通性 #

• 检查两个VPC之间的防火墙规则，确保双向允许集群Pod CIDR段之间的流量（目标端口为服务使用的80端口或实际端口）。注意Auto Pilot集群的Pod CIDR是自动分配的，可通过gcloud container clusters describe gke-1命令或GKE控制台确认。
• 在gke-1的Pod中直接telnet gke-2后端Pod的IP和端口，验证底层网络是否可达；同时在gke-2的Pod中反向测试连通gke-1的Pod，排除单向连通问题。

2. 校验MCS导出/导入资源状态 #

• 确认gke-2上的ServiceExport资源状态为Ready：

  kubectl get serviceexport -n <服务命名空间> --context=gke-2
  

• 确认gke-1上对应的ServiceImport资源状态为Ready：

  kubectl get serviceimport -n <服务命名空间> --context=gke-1
  

• 检查ServiceImport的spec.ipFamilies字段，确保与gke-1集群的IP家族（IPv4/IPv6）一致，避免IP类型不匹配导致的连接失败。

3. 排查Traffic Director后端组实际状态 #

• 虽然Traffic Director显示全局健康，但需检查具体后端组的实例状态：
  • 确认后端组的健康检查配置与服务实际监听的端口、路径完全匹配，Auto Pilot集群对健康检查的来源IP、协议可能有额外限制。
  • 查看后端组中gke-2的Pod实例是否被标记为不健康，部分情况下全局健康状态会与实际后端状态不同步。

4. 检查Auto Pilot集群的网络限制 #

• Auto Pilot集群有严格的默认安全策略：
  • 临时添加允许所有出站流量的网络策略，测试是否是网络策略拦截了流量：

    kubectl apply -f - <<EOF
    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-all-outbound
      namespace: <你的应用命名空间>
    spec:
      podSelector: {}
      policyTypes:
      - Egress
      egress:
      - {}
    EOF
    

  • 确认Auto Pilot集群的Master Authorized Networks未限制跨集群的控制平面通信（MCS的数据平面流量依赖底层VPC连通，但控制平面同步也需要正常）。

5. 验证集群集DNS解析 #

• 在gke-1的Pod中解析服务的集群集域名，确认DNS返回正确的VIP：

  nslookup <服务名>.<命名空间>.svc.clusterset.local
  

• 如果解析失败，检查gke-1的CoreDNS配置是否加载了MCS插件，Auto Pilot集群默认应启用该支持，但需确认未被自定义配置覆盖。

6. 排查服务网格Sidecar配置（若有） #

• 如果集群部署了Istio或其他服务网格，确认gke-1的Pod已正确注入Sidecar，且Sidecar配置允许跨集群流量。Auto Pilot集群的Sidecar注入可能需要额外的权限配置，需确认相关ServiceAccount权限正常。

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