Apigee通过Cloud DNS私有连接GKE时出现超时问题求助

核心问题拆解 #

你遇到的问题是Apigee调用GKE无头服务时，先出现DNS解析失败（TARGET_CONNECT_HOST_NOT_REACHABLE），配置DNS peering后转为连接超时（TARGET_CONNECT_TIMEOUT）。结合你的环境（同一项目、Default VPC、VPC Native GKE、Apigee与VPC对等），核心原因大概率集中在网络连通性限制或无头服务的特殊处理逻辑上。

排查与解决步骤 #

1. 验证Apigee运行时能否访问GKE Pod的IP范围 #

• 首先，获取GKE集群的Pod CIDR范围：

  gcloud container clusters describe [CLUSTER_NAME] --zone us-west1-a --format="value(clusterIpv4Cidr)"
  

• 确认Apigee与VPC的对等连接是否包含该CIDR：Apigee的默认对等连接会自动关联VPC的所有子网，但如果GKE使用了自定义Pod CIDR（非VPC子网范围），需要手动将该CIDR添加到Apigee的对等连接允许列表中。
• 用项目内的私有VM测试访问GKE Pod的IP（比如curl http://[POD_IP]:[PORT]），如果能通，说明网络基础连通性没问题，问题出在Apigee侧的访问控制。

2. 检查Default VPC的防火墙规则 #

• 确保存在允许Apigee的IP范围访问GKE Pod端口的防火墙规则：
  • Apigee运行时的IP范围可以通过以下命令获取：

    gcloud compute networks peerings describe apigee-vpc-peering --network default --format="value(peerIpRanges)"
    

  • 创建或更新防火墙规则，允许上述IP范围访问GKE Pod的端口（比如nginx的80端口）：

    gcloud compute firewall-rules create allow-apigee-to-gke-pods \
      --network default \
      --allow tcp:80 \
      --source-ranges [APIGEE_PEER_IP_RANGES] \
      --target-tags gke-[CLUSTER_NAME]-node
    

  注意：gke-[CLUSTER_NAME]-node是GKE节点的默认标签，确保目标标签正确。

3. 处理无头服务的DNS与连接特性 #

• 无头服务（clusterIP: None）的DNS查询会返回所有后端Pod的IP地址，而非单个ClusterIP。Apigee的HTTP客户端可能不支持自动轮询多个IP，或者在连接时没有正确处理多IP返回的情况。
• 临时测试：将无头服务改为普通ClusterIP服务，验证Apigee能否正常调用。如果能通，说明问题出在无头服务的多IP处理上。
• 解决方案：如果必须使用无头服务，可以在Apigee中添加负载均衡策略（比如轮询），或者在GKE侧部署一个普通的ClusterIP服务作为无头服务的代理。

4. 确认DNS peering的有效性 #

• 虽然你已经创建了DNS peering，但需要确认Apigee的运行时能否正确解析nginx-svc.default.svc.gkeapi.：
  • 在Apigee的Trace工具中查看DNS解析结果，确认是否返回了Pod的IP列表。
  • 验证Cloud DNS的peering配置是否正确：

    gcloud services peered-dns-domains describe gke-apigee --network default
    

    确保dns-suffix与GKE的服务域名后缀完全匹配（你的是gkeapi.，要确认GKE的服务域名确实是default.svc.gkeapi.）。

5. 检查区域网络延迟与连通性 #

• 虽然Apigee和GKE都在us-west1，但需要确认两者的运行时是否在同一可用区，或者VPC内的区域连通性是否正常。可以通过在Apigee中添加一个简单的延迟测试，或者查看GKE节点的网络监控数据，确认没有丢包或高延迟问题。

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