K8s 优雅退出到底要做到多细？聊聊落地成本与收益

背景 15 年嵌入式出身，早期 MCU 上"退出"就是把外设时钟关掉、把中断清掉、关键变量落 flash，然后系统复位——几乎没有"优雅"空间，因为资源就那么点，多一毫秒都是钱。这两年主力转容器化和 K8s 运维，反而发现"优雅退出"在容器里变成了一个"看似简单、实则每个团队都做得不一样"的灰色地带。最近帮两个团队做服务收敛（把 sidecar 并回主进程、把一次性任务改成常驻容器），被问得最多的一句话就是："preStop 到底要不要写？terminationGracePeriodSeconds 设多少？"

常见分歧

• 一派：能不做就不做。K8s 默认 30s + SIGTERM 就够了，业务进程只要别"硬扛"就行；写 preStop 是过度设计，脚本挂了、依赖 curl 挂了，退出反而更慢，维护成本不低。
• 一派：必须做，而且要做"三段式"——preStop 先摘流量（更新 readiness / 调网关 / 写状态）→ 主进程收到 SIGTERM 后 drain 在途请求 → 最后 kill。理由是不做就会在发布窗口里出现 5xx。
• 还有一派：干脆不用 preStop，把"摘流量"做进 readinessProbe 的健康检查里，让 K8s 自己控制流量进出；preStop 只用来做"清理本地状态"（flush、落盘、通知对端）。
• 边缘/嵌入式场景更极端：节点可能随时断电断网，"优雅退出"窗口可能只有几百毫秒。做不做、做到哪一步，完全取决于"断电概率 × 单次退出失败的业务损失"。

我的倾向 我倾向于"分级做"，而不是一刀切。判断标准是三个数：

1. L：单次优雅退出失败的业务损失（一条未落盘的事务、一个未 ack 的消息、一次未通知的对端）；
2. F：发布 / 缩容 / 节点维护的频次（一天几次、一个 release 周期几次）；
3. C：实现与回归测试的成本（脚本、依赖健康、超时窗口、可观测性、CI 里能不能模拟）。

只有 L × F 显著大于 C 时，才值得把"三段式"做完整；否则一个"SIGTERM 默认 30s + readiness 摘流量"的极简方案就够了。嵌入式里我管这个叫"按故障率分配资源"——把最复杂的退出逻辑留给最贵的那类故障，而不是给每个服务都配一套。另外我会强制要求退出逻辑"幂等 + 可重入"，因为 SIGKILL 是兜底，你写的所有清理都要能重复执行不报错。

想听大家

• 你们线上服务现在退出逻辑做到哪一级？是 preStop + 三段式，还是只靠 readiness 摘流量？
• terminationGracePeriodSeconds 你们一般怎么定？有没有按"最大在途请求时长 + 缓冲"去算的？
• 边缘 / 断网场景下，你们怎么权衡"退出窗口"和"断电概率"？有没有把退出逻辑做成幂等 + 可重入来兜底？
• 有没有踩过"preStop 脚本挂了导致 Pod 卡 Termination"的坑？怎么防的？
• 对一次性任务（Job / CronJob），你们是怎么定义"退出成功"的？看 exit code 就行，还是要落一份"完成态"？

欢迎贴你团队的退出策略片段（脱敏即可），我们一起对一下"成本 / 收益"账。