GKE部署Nginx 1.24 Pod重启排查：探针失败与上游连接报错分析

核心问题定位 #

Pod重启的直接触发原因是存活/就绪探针失败，结合日志中的两个info级错误，问题根源大概率在Nginx自身的缓存锁竞争或探针配置不合理——上游服务已确认正常，且扩副本无效也印证了这是单Pod内部的处理瓶颈问题。

具体排查与解决步骤 #

1. 优先排查探针配置（最可能的直接诱因） #

• 检查探针路径是否依赖上游转发：如果探针请求（比如/api/health）需要经过Nginx转发到上游，即使上游正常，Nginx的缓存锁超时也会导致探针请求无法及时响应，触发失败。建议将探针路径改为Nginx本地的健康检查端点，新增配置示例：

  location /healthz {
      access_log off;
      return 200 'ok';
  }
  

  随后将探针的path设为/healthz，验证是否还会出现重启。
• 调整探针参数：检查timeoutSeconds（建议设为3-5s）、periodSeconds（建议5-10s）、failureThreshold（建议3-5）。如果超时设置过短，Nginx处理缓存锁的时间会超过探针超时阈值，直接触发失败。

2. 解决Nginx缓存锁超时问题 #

日志中的cache lock timeout是关键线索，说明Nginx在获取缓存锁时超过了默认5s的超时限制：

• 调整缓存锁相关配置：在Nginx的proxy缓存配置块中添加或修改：

  proxy_cache_lock on;
  proxy_cache_lock_timeout 10s; # 延长超时时间
  proxy_cache_lock_age 5s; # 超时后允许后续请求直接转发上游，避免持续等待锁
  

• 优化缓存key粒度：如果大量请求命中同一个缓存key，会加剧锁竞争。可以在proxy_cache_key中加入更多请求维度（比如$request_uri$args），分散锁竞争压力。
• 禁用非必要缓存：如果某些业务路径不需要缓存，直接关闭proxy_cache，彻底避免锁竞争问题。

3. 排查Nginx连接与资源瓶颈 #

• 检查Nginx worker连接数：确认worker_connections设置是否足够（建议设为10240或更高，根据Pod资源调整），避免连接队列溢出导致请求阻塞。
• 优化上游连接复用：配置Nginx与上游的长连接，减少连接创建开销：

  upstream backend {
      server {{k8s-service-name}}:8080;
      keepalive 32; # 保持上游长连接数量
  }
  
  server {
      ...
      proxy_http_version 1.1;
      proxy_set_header Connection "";
  }
  

• 监控Pod资源使用：用kubectl top pod <pod-name>查看CPU、内存是否有突增或持续高位。如果Pod CPU被GKE资源限制（requests/limits），会导致Nginx worker进程无法及时处理请求，进而阻塞探针请求。

4. 验证与观察 #

修改配置后，滚动更新Nginx Deployment，观察Pod是否还会因探针失败重启，同时监控Nginx日志中cache lock timeout的出现频率。

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