如何在GKE中调试"Steam timeout"与"upstream request timeout"问题

针对你遇到的外部访问首次/隔段时间超时、Pod内部访问正常的问题，按以下步骤排查：

1. 检查Ingress及后端服务的超时配置 #

• 查看Ingress的注解配置，确认是否存在过短的代理超时设置：

  kubectl get ingress <你的Ingress名称> -o yaml
  

  重点关注nginx.ingress.kubernetes.io/proxy-read-timeout、nginx.ingress.kubernetes.io/proxy-connect-timeout这类注解，如果值设置过小（比如小于10秒），会导致首次请求因服务初始化耗时触发超时。
• 若使用GKE原生负载均衡器（GCLB），通过GCP控制台导航到「负载均衡」→ 对应负载均衡器 → 后端服务，查看「超时」参数，默认是30秒，若你的应用首次初始化耗时超过这个值，会触发超时。

2. 验证Service与Pod的端点状态 #

• 确认Service关联的Pod端点是否正常就绪：

  kubectl describe service <你的Service名称>
  

  查看Endpoints字段，确保所有Pod的IP都在列表中，且没有标记为NotReady。
• 检查Pod的就绪探针配置，确认探针是否过早标记Pod为就绪：

  kubectl get pod <你的Pod名称> -o yaml
  

  查看readinessProbe的initialDelaySeconds、periodSeconds参数，如果initialDelaySeconds设置过短，可能Pod还未完成初始化就被Ingress转发请求，导致首次超时。

3. 查看Ingress控制器的日志 #

• 若使用Nginx Ingress控制器，查看控制器日志定位超时请求细节：

  kubectl logs -n kube-system <nginx-ingress-controller-Pod名称> | grep "upstream timed out"
  

  日志会显示具体的超时请求路径、后端Pod IP，帮助判断是单个Pod问题还是全局转发问题。
• 若使用GCLB，通过GCP控制台查看负载均衡的「日志」面板，搜索timeout关键词，查看请求的生命周期耗时，定位是连接阶段还是响应阶段超时。

4. 排查应用初始化与连接池问题 #

• 在Pod内部测试首次请求的响应时间，对比外部访问的耗时：

  kubectl exec -it <你的Pod名称> -- curl -w "总耗时: %{time_total}s\n" http://localhost:<应用端口>/<请求路径>
  

  如果Pod内部首次请求耗时接近Ingress的超时阈值，说明是应用自身初始化（比如数据库连接池、缓存预热）导致的超时，需要优化应用启动后的初始化逻辑，或者调整Ingress的超时设置。
• 查看应用自身的日志，确认首次请求时是否有大量初始化操作的耗时记录。

5. 检查网络空闲连接回收机制 #

• 检查Pod内的TCP保活参数，避免中间网络设备断开空闲连接：

  kubectl exec -it <你的Pod名称> -- sysctl net.ipv4.tcp_keepalive_time
  

  默认的tcp_keepalive_time是7200秒（2小时），如果间隔访问的时间超过这个值，Ingress到Pod的连接可能被中间设备断开，下次访问需要重建连接，触发超时。可以通过Pod的sysctl配置调整该参数。
• 检查Ingress控制器的连接复用设置，比如Nginx的keepalive_timeout、keepalive_requests，确保允许足够的长连接复用，减少重建连接的耗时。

6. 测试会话亲和性影响 #

• 检查Service的会话亲和性设置：

  kubectl get service <你的Service名称> -o yaml | grep sessionAffinity
  

  如果设置了ClientIP，可能导致同一客户端的请求一直打到同一个Pod，若该Pod的连接被断开，下次访问会触发超时。可以临时将sessionAffinity改为None测试是否解决问题。

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