GCP IAP连接器无法路由请求至本地环境，报“No healthy upstream”错误

我之前处理过几乎一模一样的跨VPC+IAP连通性场景，结合你的描述，Pod无法访问远端VM确实是导致503 "No healthy upstream"的核心原因——毕竟IAP最终要通过Connector（或者你的应用Pod）转发流量到后端服务，连通性断了，负载均衡器自然认为上游不健康。咱们从几个核心维度一步步排查：

1. 先确认Pod的路由是否指向远端VPC #

节点能ping通但Pod不行，大概率是Pod所在子网的路由没覆盖到远端模拟项目的VPC CIDR：

• 随便找一个主项目的应用Pod，执行ip route，看看输出里有没有远端VPC的CIDR条目，以及对应的下一跳是不是VPN隧道/Cloud Router；
• 去主项目的VPC控制台，检查Pod所在子网的自定义路由，确认有没有添加远端VPC CIDR的路由，下一跳选择对应的VPN隧道；
• 额外检查IAP Connector所在GCE实例的IP转发是否开启：登录实例执行sysctl net.ipv4.ip_forward，如果返回net.ipv4.ip_forward = 0，立刻执行sysctl -w net.ipv4.ip_forward=1临时开启，还要在实例模板里加启动脚本永久生效——IP转发没开的话，实例没法把Pod的流量转发到VPN。

2. 检查双向防火墙规则 #

别只看一边的防火墙，两边都要验证：

• 主项目侧：
  • 允许Pod子网的CIDR出站访问远端VM的80/443端口；
  • 允许远端VPC CIDR的入站流量到Pod子网（因为Pod的源端口是随机的，回包需要放行）；
• 模拟本地的项目侧：
  • 允许主项目Pod子网的CIDR访问VM的80/443端口；
  • 允许GCP健康检查IP段（35.191.0.0/16和130.211.0.0/22）访问VM的健康检查端口/路径——这一步很容易漏，健康检查失败的话LB直接标记后端不健康，也会出503。

3. 验证VPN的路由传播是否正常 #

VPN隧道通了不代表路由能自动传过去，得看Cloud Router的BGP学习情况：

• 主项目和模拟项目的Cloud Router控制台，查看「已学习的路由」，确认两边都能获取到对方VPC的CIDR；
• 如果没学到路由，检查Cloud Router的BGP配置：两边的ASN不能相同，邻居IP要填对，并且要开启「路由传播」选项。

4. 检查IAP Connector的网络权限 #

IAP Connector是流量转发的关键节点，得确保它能拿到后端服务的流量：

• 确认Connector所在的GCE实例属于主项目的正确子网，并且该子网有到远端VPC的路由；
• 在Connector实例上测试访问远端VM的443端口：curl -v https://<远端VM IP>，如果连不通，先解决Connector到VM的连通性，再看Pod的问题。

5. 排查Network Policy（如果启用了） #

如果主项目的K8s集群开了Network Policy，很可能是规则阻止了Pod的出站流量：

• 临时禁用Network Policy（kubectl delete networkpolicy --all）测试一下，如果能通了，就需要添加允许Pod访问远端VPC CIDR的出站规则。

最后总结 #

你的场景里节点能通，说明VPN隧道本身是正常的，问题就出在Pod层面的路由/转发/防火墙限制。先解决Pod到远端VM的ping通问题，再回头看IAP的503——只要后端服务能被正常访问，IAP的健康检查就会通过，503自然消失。

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