K8s 优雅退出：preStop sleep 30s 到底是不是「祖传补丁」？SIGTERM 之后到底该等谁？

【背景】 做了 5 年 K8s 运维，最近半年帮 3 个团队排查「发布期 502 / 连接被 RST」，根因惊人地一致：不是探针配错，而是对「优雅退出到底在保护什么」没有共识。我抽出来的典型现象：

1. Service 摘流（iptables/endpoint 更新）和内核给进程发 SIGTERM 之间没有顺序保证，摘流慢的那几百毫秒里，流量还在打到「正在关闭」的 Pod；
2. 应用收到 SIGTERM 后没有真正 drain，直接走 Spring 的 shutdown 钩子关连接池，in-flight 请求被截断；
3. terminationGracePeriodSeconds 默认 30s，但应用里还有 Kafka consumer 要 commit offset、HTTP 长连接要优雅断开——30s 根本不够，而调大到 120s 又拖慢整个滚动发布。

【常见分歧 / 几种做法】

• 做法 A（最普遍）：lifecycle.preStop 里 sleep 30，赌「内核发 SIGTERM 时摘流已完成」。这是事实上的祖传补丁，能缓解但不能根治，而且 sleep 时间写死在 Pod 里，跟实际摘流耗时（节点网络、CNI、endpoint controller 负载）完全脱钩；
• 做法 B：应用侧做真 drain——收到 SIGTERM 后先停止接新请求、等 in-flight 完成、commit offset、再退出，preStop 不设 sleep 或只留 5s 兜底；
• 做法 C：sidecar 代理模式（Envoy/Istio 之类），让 sidecar 持有连接和 drain 逻辑，主容器只管业务；
• 做法 D：干脆把 terminationGracePeriodSeconds 拉到 120s，「多等不会错」，代价是发布窗口翻倍、故障 Pod 回收也变慢。

【我的倾向与理由】 我倾向 B + 最小 preStop（3~5s 只用于覆盖「摘流还没生效」的窗口），理由：

1. 保护的对象应该明确：优雅退出的本质是「摘流 → 停止接新请求 → 排空 in-flight → 释放资源」四步，preStop sleep 只覆盖了第一步和第二步之间的缝隙，把 sleep 当主手段等于把四步里的三步交给运气；
2. 应用侧 drain 可观测：可以打一个 draining 指标，发布平台据此判断「这批 Pod 是否全部排空」，比 sleep 完就认为成功要可靠；
3. terminationGracePeriodSeconds 应该按「P99 in-flight 时长 + offset commit 时长 + 安全余量」算出来，而不是拍脑袋 30/120。我们一个订单服务算下来 P99 in-flight 800ms + commit 2s + 10% 余量，8s 就够，发布窗口从 30s 缩到 10s，滚动发布快了 3 倍。
4. 做法 C 适合跨语言、多协议混部的场景，但多一层 sidecar = 多一个故障域，单体服务没必要。

【想听大家在什么场景下怎么选】

• 你们的 preStop 里到底写了什么？sleep 多少？这个数是拍的还是测出来的？
• 摘流耗时你们量过吗？在哪些节点 / 哪些 CNI 上最慢？
• 应用侧 drain 你们做到什么粒度：只停接新请求，还是连连接池 / Kafka offset / 长连接都一起排空？
• terminationGracePeriodSeconds 你们是怎么定的？有没有因为「调大了回收慢 / 调小了 502」来回折腾过？
• sidecar 代理模式你们在哪类服务上真正用起来了，代价（资源、排障复杂度）值不值？

欢迎贴你们的 Pod spec 片段（脱敏）和 drain 实现，我想收集一份「优雅退出配置样本集」。