GKE多集群内部服务调用故障：A→B→C链路异常排查请求

结合你描述的GKE集群配置和故障现象，我来梳理下几个最可能的问题点，以及对应的排查和解决方向：

1. Cluster A与Cluster B的VPC对等连接缺失 #

你提到已经为Cluster B和C配置了VPC对等，但**Cluster A和B之间的VPC对等是不是没做？**这是最容易忽略的核心点：

• 如果A和B的VPC没打通，Service A1就算改用B1的内部地址调用，也会因为网络不通导致请求失败，进而让B1没有机会去调用C1（甚至B1本身就没收到A1的请求）。
• 排查：登录GCP控制台，检查VPC对等连接列表，确认Cluster A所在的VPC和Cluster B的VPC是否建立了对等关系，并且路由表已经同步了双方的Pod CIDR和Service CIDR。

2. Service A1仍在使用公网地址调用B1 #

你说要把A1→B1改成内部调用，但可能A1的配置里还是用了B1原来的公网Ingress域名，而不是B1的内部服务地址（比如ClusterIP、Internal LoadBalancer地址）：

• 这种情况下，A1的请求还是走公网，可能被后续的内部网络策略拦截，或者B1收到请求后，因为来源是公网，触发了其他限制导致无法调用C1。
• 排查：查看Service A1的配置文件或代码里的B1调用地址，确认是否替换成了B1的内部访问地址（比如b1.default.svc.cluster.local这种集群内服务名，或者Internal LB的私有IP）。

3. NetworkPolicy限制了Pod层面的跨集群流量 #

虽然Cluster B的节点能直接调用C1，但Pod的流量可能被NetworkPolicy拦截：

• 比如Cluster B里的NetworkPolicy只允许节点IP发起的流量访问外部，而拒绝了B1 Pod IP的流量；或者Cluster C的NetworkPolicy只接受Cluster B节点的IP段，不接受B1所在的Pod CIDR。
• 排查：
  • 查看Cluster B中B1所在命名空间的NetworkPolicy，确认是否允许该命名空间的Pod向Cluster C的VPC/CIDR发起出站流量。
  • 查看Cluster C中C1所在命名空间的NetworkPolicy，确认是否接受来自Cluster B Pod CIDR的入站流量。

4. 跨集群服务发现配置缺失 #

如果B1是通过服务名（比如c1.default.svc.cluster.local）调用C1，那Cluster B的DNS可能无法解析Cluster C的服务名：

• GKE默认的ClusterDNS只能解析本集群的服务，跨集群服务发现需要额外配置（比如启用GKE的跨集群服务发现功能，或者配置DNS转发）。
• 排查：在Cluster B的任意一个Pod里执行nslookup c1.default.svc.cluster.local（替换成C1的实际服务名和命名空间），看是否能解析到正确的ClusterIP。如果解析失败，就需要配置跨集群DNS。

5. VPC路由或防火墙规则未覆盖Pod CIDR #

即使VPC对等配置了，路由表可能没有包含集群的Pod CIDR，或者GCP防火墙规则限制了Pod之间的流量：

• 比如Cluster B的VPC路由表没有添加Cluster C的Pod CIDR路由，或者GCP防火墙规则只允许节点之间的流量，不允许Pod跨VPC的流量。
• 排查：
  • 检查VPC对等连接的路由配置，确认三个集群的Pod CIDR和Service CIDR都已经在对应的路由表中存在。
  • 检查GCP防火墙规则，确认是否允许Cluster A的Pod CIDR访问Cluster B的服务端口，以及Cluster B的Pod CIDR访问Cluster C的服务端口。

内容的提问来源于stack exchange，提问作者Dat Pham Tat