kubernetes滚动更新时长连接未收敛导致请求失败，根本原因是service不主动终止长连接，需通过prestop hook、terminationgraceperiodseconds配置及nginx优雅退出协同解决。
滚动更新时 Nginx 负载均衡后端 Pod 变更，但客户端长连接仍维持在已终止的旧 Pod 上，导致请求失败或超时——这不是 Nginx 配置问题，而是 Kubernetes 与应用协同机制缺失所致。核心在于：长连接不会被 Service 自动“踢下线”，必须靠主动干预来收敛。
确保旧 Pod 在退出前完成连接清理
Pod 进入 Terminating 状态后，Kubernetes 会从 Endpoints 中移除它，但 kube-proxy 更新 iptables/ipvs 规则、云厂商 SLB 同步后端列表都存在延迟。此时若 Nginx（作为反向代理或 Ingress Controller）仍把新流量打到该 Pod，或客户端长连接尚未关闭，就会出问题。
关键做法是让旧 Pod 主动拒绝新连接、并等待已有连接自然结束：
- 配置 preStop Hook：在容器收到 SIGTERM 前执行清理动作，例如
nginx -s quit或sleep 10，给长连接留出释放窗口 - 设置足够长的 terminationGracePeriodSeconds（如 30–60 秒），且必须大于 preStop 执行时间，否则会被强制 kill
- 业务层配合：Nginx 容器内应监听 SIGTERM 并触发优雅退出逻辑（如关闭监听端口、拒绝 accept 新连接）
让 Nginx 主动感知后端变化并断连旧连接
如果 Nginx 是独立部署的反向代理（非 Ingress Controller），它不会自动 watch Endpoint 变化。默认使用静态 upstream，长连接会一直复用旧 IP，直到超时或错误才重试。
解决方式取决于部署模式：
- 用 Ingress Controller（如 nginx-ingress）：它原生监听 Endpoints 和 Service 变更，自动更新 upstream，并支持
keepalive_timeout+keepalive_requests控制连接复用生命周期 - 自建 Nginx + DNS 解析：将 upstream 指向 Service 名（如
backend-service.default.svc.cluster.local），配合resolver kube-dns和短 TTL（如 5s），但不推荐用于长连接场景，因 DNS 缓存不可控 - 自建 Nginx + 动态配置生成：通过 Sidecar 或 Operator 监听 Endpoint 变更，生成新配置并触发
nginx -s reload，注意 reload 本身不中断已有连接，但会新建 worker 进程处理新连接
客户端侧配合：容忍连接中断并自动重连
服务端再完善，也无法完全避免极短时间内的连接抖动。对长连接客户端（如 WebSocket、gRPC、MQTT），必须设计容错逻辑：
- 启用连接健康检查（如 TCP keepalive、HTTP/2 ping），及时发现断连
- 实现指数退避重连机制，避免雪崩式重连冲击新 Pod
- 避免在连接层做强状态绑定；关键业务逻辑应具备幂等性，能承接重试请求
验证是否生效的简单方法
更新前可快速确认几个关键点：
-
kubectl get endpoints <your-service></your-service>—— 更新中观察旧 IP 是否及时消失 - 进旧 Pod 执行
ss -tnp | grep :80—— 看连接数是否随 preStop sleep 逐步下降 - Nginx access log 中是否有大量
502/504或连接 reset 记录 —— 若仍有，说明 termination 流程未对齐
