核心是配置prestop钩子延迟退出、合理设置readinessprobe与terminationgraceperiodseconds，并结合maxunavailable:0、minreadyseconds等参数，确保旧pod处理完长连接、新pod完全就绪且网络层同步完成后再终止。
要解决 Kubernetes 滚动更新中旧连接无法平滑释放的问题，核心在于让旧 Pod 在终止前继续处理已有连接、拒绝新连接，并确保流量调度层（如 kube-proxy 或 Service）有足够时间同步状态。这不是单纯靠“加快更新”或“多加副本”能解决的，而是依赖一组协同工作的生命周期控制机制。
配置合理的 preStop 钩子延迟退出
旧 Pod 被标记为 Terminating 后，默认会立即停止接收新请求，但正在处理的长连接（如 HTTP 流、WebSocket、gRPC 流）可能还没结束。此时若直接终止进程，连接会被强制中断。
- 在容器 termination 开始前，通过 preStop 执行轻量清理并留出缓冲时间，例如：
sleep 15或调用应用自身的优雅下线接口 - 该延迟必须小于或等于 terminationGracePeriodSeconds（默认 30s），否则会被强制 kill
- 避免在 preStop 中执行耗时操作（如上传日志、远程调用），以防超时被强杀
启用就绪探针并合理设置初始等待
就绪探针（readinessProbe）决定 Pod 是否加入 Service 的 Endpoints。它不只影响新 Pod 上线，也间接影响旧 Pod 下线节奏——因为只有新 Pod 就绪后，Service 才会逐步将流量切走，从而降低对旧 Pod 的新连接压力。
- 设置 initialDelaySeconds 略大于应用实际启动耗时（如 Java 应用可设为 20–40s），避免过早探测失败导致反复重启
- 使用轻量健康端点（如
/healthz），不查询数据库或依赖外部服务 - 避免与 Dockerfile 中的 HEALTHCHECK 冲突；K8s 探针应作为唯一权威，禁用容器内冗余健康检查
调整滚动策略参数保障最小可用性
即使探针和钩子都配置正确，若更新策略过于激进，仍会导致旧 Pod 被过早驱逐、新 Pod 尚未承接全部流量，从而放大连接中断风险。
- 设置 maxUnavailable: 0，确保任意时刻至少有一个旧 Pod 在线，直到新 Pod 完全就绪
- 设置 maxSurge: 1（或按需略增），控制资源开销的同时提供过渡实例
- 添加 minReadySeconds（如 10–30s），要求新 Pod 就绪后持续健康一段时间才视为真正可用，防止短暂就绪即被误判
确认网络层同步行为不拖后腿
即便 K8s 已从 Endpoints 移除旧 Pod，客户端节点上的 kube-proxy 可能因 watch 延迟或 iptables 更新滞后，仍在向已终止的 Pod 发送新连接。
- preStop 中的 sleep 延迟，本质就是为 kube-proxy 的规则刷新预留窗口（通常 5–15s 足够）
- 避免使用 hostNetwork 模式，因其绕过 kube-proxy，使 Endpoint 变更失效
- 如使用 Istio 等服务网格，可开启 connection draining 功能，由 sidecar 主动接管连接迁移
