Istio路由404问题排查：跨GKE集群Prometheus指标采集失败

需求可行性 #

该需求完全可行。通过GCP对等连接打通网络，结合Istio的Gateway、ServiceEntry、VirtualService配置，能够实现Linux服务器通过集群A代理访问集群B的Prometheus指标。

问题定位与排查步骤 #

出现404（route_not_found）的核心原因是Istio的路由链路未正确匹配请求——集群A的Pod能正常访问集群B，说明跨集群网络连通性无问题，问题出在路由配置的某个环节：

可能的配置问题点 #

• 集群A的ServiceEntry配置错误
  • 未正确定义集群B Prometheus服务的hosts、address、ports（尤其是协议类型，比如HTTP）
  • ServiceEntry的hosts与后续VirtualService的hosts不匹配
• 集群A的VirtualService配置错误
  • 未将VirtualService关联到集群A的Ingress Gateway（gateways字段未包含istio-ingressgateway）
  • 路由规则的hosts、路径未与ServiceEntry对应，导致请求无法转发到集群B
• 集群B的VirtualService配置错误
  • 未允许来自集群A的请求（hosts未包含集群A ServiceEntry定义的域名/地址）
  • 路径规则未精确匹配Prometheus的指标路径（通常为/metrics）
  • VirtualService未绑定到集群B的Ingress Gateway
• 路径匹配精度问题
  • VirtualService的路径规则使用模糊匹配（如/）而非精确匹配（如/metrics），导致无法命中正确路由

具体排查步骤 #

1. 验证集群A的ServiceEntry有效性
   在集群A的Istio Ingress Gateway Pod内执行：

   curl -v <集群B_Prometheus地址>:<端口>/metrics
   

   若能正常返回指标数据，说明ServiceEntry配置正确；否则检查ServiceEntry的hosts、address、ports字段。

2. 检查集群A的VirtualService配置
   确认：

   • gateways字段包含集群A的Ingress Gateway实例（如istio-ingressgateway）
   • hosts字段与ServiceEntry的hosts完全一致
   • http.route.destination.host指向ServiceEntry定义的host
   • 路径规则精确匹配/metrics，示例：

     http:
       - match:
           - uri:
               exact: /metrics
         route:
           - destination:
               host: <service_entry_host>
               port:
                 number: <prometheus_port>
     

3. 检查集群B的VirtualService配置
   确认：

   • gateways字段包含集群B的Ingress Gateway
   • hosts字段允许集群A ServiceEntry的host（或临时设置为*测试）
   • 路径规则精确匹配/metrics，且destination指向集群B内部的Prometheus Service

4. 定位404来源
   在Linux服务器执行：

   curl -v <集群A_IngressGateway_IP>:<端口>/metrics
   

   结合集群A和B的Istio日志，判断404是集群A返回（路由未匹配）还是集群B返回（集群B路由未匹配），针对性调整配置。

5. 验证网络防火墙规则
   确保：

   • Linux服务器所在项目防火墙允许访问集群A Ingress Gateway的对应端口
   • 集群A与B的对等连接规则允许该端口的流量通行

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