Kubernetes集群内服务调用504网关超时问题求助

根据你提供的配置和问题描述，从以下几个方向逐步排查：

一、优先排查ClusterIP调用失败的核心问题 #

你提到通过ClusterIP调用SERVICE1也失败，这是服务间通信的基础，先解决这个：

1. 验证服务DNS解析
   在SERVICE2的Pod内执行命令，检查是否能正确解析SERVICE1的ClusterIP：

   kubectl exec -it <svc-service2-pod-name> -- nslookup svc-service1
   

   • 如果解析失败：检查CoreDNS是否正常运行（kubectl get pods -n kube-system | grep coredns），或确认SERVICE1的Service标签与Deployment Pod标签完全匹配（你的配置里app: svc-service1是匹配的，但可再核对）。
2. 测试端口连通性
   在SERVICE2的Pod内直接测试SERVICE1的端口是否可达：

   kubectl exec -it <svc-service2-pod-name> -- telnet svc-service1 3000
   # 或用curl测试实际请求路径
   kubectl exec -it <svc-service2-pod-name> -- curl -v http://svc-service1:3000/api/service1
   

   • 注意：外部通过Ingress访问的路径是/api/service1，但SERVICE1的应用是否真的监听这个路径？如果SERVICE1的接口根路径是/，那ClusterIP调用时应该用http://svc-service1:3000/，而非带/api/service1——这是常见的路径匹配误区。
3. 检查SERVICE1的Pod状态与日志
   • 确认SERVICE1的Pod处于Running状态：kubectl get pods | grep svc-service1
   • 查看Pod日志，确认是否收到SERVICE2的请求，或是否有内部错误：

     kubectl logs <svc-service1-pod-name>
     

   • 检查Pod资源占用，是否因CPU/内存耗尽导致无法处理请求：

     kubectl top pod <svc-service1-pod-name>
     

4. 排查网络策略限制
   检查是否存在NetworkPolicy阻止了SERVICE2的Pod访问SERVICE1：

   kubectl get networkpolicy
   

   默认无NetworkPolicy时集群内部Pod可自由通信，若存在需确认规则是否允许SERVICE2的标签访问SERVICE1的标签。

二、排查Ingress域名调用超时问题 #

若ClusterIP调用正常，但通过api.example.com/api/service1调用超时，需关注ALB的配置与路由环路问题：

1. 检查ALB目标组健康状态
   在AWS控制台查看ALB的目标组，确认SERVICE1对应的目标组中Pod的健康状态为「健康」——外部访问正常说明健康检查大概率通过，但需确认健康检查路径与实际请求路径是否一致（若健康检查用/health，但实际请求路径是/api/service1，需确保SERVICE1两个路径都能响应）。
2. 验证安全组配置
   • ALB的安全组：需允许集群内部CIDR（或节点子网CIDR）访问80/443端口（internet-facing的ALB默认允许0.0.0.0/0，但若集群用了私有子网，需确认规则）。
   • 节点/Pod的安全组：需允许ALB的安全组访问Pod的3000端口（因ALB的target-type: IP，直接与Pod IP通信）。
3. 排查内部访问Ingress的路由环路
   当集群内部Pod访问internet-facing的ALB域名时，可能出现路由环路：Pod流量经NAT网关到ALB，ALB再试图将流量打回集群，但VPC路由或安全组拦截了返回流量。
   • 可尝试在SERVICE2的Pod内修改hosts，将api.example.com指向SERVICE1的ClusterIP，绕过ALB测试：

     kubectl exec -it <svc-service2-pod-name> -- bash -c 'echo "<svc-service1-cluster-ip> api.example.com" >> /etc/hosts && curl -v http://api.example.com/api/service1'
     

   • 若此方法可行，说明是ALB的内部访问路由问题，可考虑将Ingress改为internal模式（修改alb.ingress.kubernetes.io/scheme: internal），或配置VPC的内部DNS解析，让集群内部访问api.example.com直接指向ClusterIP。

三、Ingress路径配置的潜在问题 #

你的Ingress中SERVICE1的路径是/api/service1（Prefix类型），ALB会转发所有以/api/service1开头的请求到SERVICE1。需确认：

• SERVICE2调用时的请求路径是否完整，比如是否漏加了前缀，或多了斜杠（如/api/service1/ vs /api/service1）。
• 若需要路径重写（比如将/api/service1转发到SERVICE1的/），需添加ALB的重写annotation：

  alb.ingress.kubernetes.io/rewrite-target: /
  alb.ingress.kubernetes.io/conditions.service1: "path-prefix('/api/service1')"
  

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