在 Kubernetes 集群中，当我们需要发布新版本、手动删除 Pod 或者控制器因缩容而移除实例时，Pod 并不会被立刻强制销毁。系统会先尝试让其中的容器“优雅退出”，也就是完成已接收的请求、释放资源后再关闭。这种机制被称为 Graceful Shutdown，能否配置好直接决定了线上服务是否会在发布期间出现 502 或数据不一致。
要理解配置方式，首先得清楚 kubectl delete pod 之后集群内部发生了什么。API Server 将 Pod 状态置为 Terminating，Endpoint 控制器会将其从 Service 的可用后端中摘除，接着 kubelet 向容器主进程发送 SIGTERM 信号，并启动 terminationGracePeriodSeconds 倒计时。若容器在倒计时结束前未退出，kubelet 会发送 SIGKILL 强制杀死进程。
很多团队以为只靠 SIGTERM 就足够了，但实际网络中，从 Endpoint 摘除到负载均衡器停止转发可能存在秒级延迟。如果进程收到信号马上退出，仍会有少量旧请求被打到正在关闭的 Pod 上。因此，Graceful Shutdown 是一个“停止接流 + 处理在途 + 平滑退出”的组合动作，而不是单一信号捕获。
核心配置参数解析
terminationGracePeriodSeconds 是 Pod 级别的基础超时设定，默认值为 30 秒。它定义了从发送 SIGTERM 到强制 SIGKILL 之间的最大等待时间。若你的服务关闭需要刷盘、上报监控或等待长连接断开，应适当调大，例如设为 60 或 90。但也不宜过长，否则节点资源回收变慢，影响调度效率。
另一个重点是 containers 下的 lifecycle.preStop 字段。preStop 是一个在 SIGTERM 之前或同时触发的钩子，常用于通知注册中心下线或sleep 几秒等待流量切走。例如通过 exec 执行 sleep 10，让负载均衡层先收敛连接，再进入进程退出逻辑，能有效避免边界请求丢失。
典型 YAML 配置示例
下面是一段经过生产验证的片段，展示了如何组合使用上述字段：
- 设置 terminationGracePeriodSeconds: 60，给予充足退出时间
- preStop 执行 sleep 15，等待 Service 端点完全摘除
- 容器内进程需监听 SIGTERM 并主动关闭监听端口
注意：preStop 的执行时间会计入 terminationGracePeriodSeconds 总时长，若 preStop 自身卡住，会挤压进程退出的可用时间。
容器内信号处理实践
无论编排层怎么配置，最终都要落回到应用代码。以 Java Spring Boot 为例，其内嵌 Tomcat 在收到 SIGTERM 后会触发 Shutdown Hook，先不再接收新请求，随后等待活跃请求完成。但前提是 JVM 确实收到了信号，而不是被 shell 脚本用 exec 覆盖成了子进程导致信号丢失。
对于 Node.js 服务，应监听 process.on('SIGTERM', () => { server.close(); }) 并在 close 回调中调用 process.exit(0)。若使用 Docker 的 shell 形式启动（如 CMD node app.js 前包了一层 sh），信号可能只发给 shell，需在 Dockerfile 用 exec 形式保证信号直达 Node 主进程。
常见误区与排查思路
不少开发者发现 Pod 删除后仍报错，便盲目加大超时。其实应先看日志确认是否收到 SIGTERM，以及 preStop 是否执行。可通过 kubectl describe pod 观察 Events 中的 Killing 时间戳，对比容器日志末尾的退出动作时间差，定位是配置问题还是代码未处理信号。
还有一种情况是使用了第三方 Sidecar，主容器退出了但 Sidecar 仍运行，导致 Pod 整体未达终止状态。此时需要明确 sidecar 的终止逻辑，或使用 K8s 1.29 之后提供的 Sidecar 原生支持，确保辅助容器随主容器一同优雅关闭。
配置对比参考
不同策略在请求成功率和发布体验上有明显差异，下表列出常见组合效果：
| 策略 | 是否配 preStop | 是否捕获 SIGTERM | 发布中断率 |
|---|---|---|---|
| 默认配置 | 否 | 否 | 高 |
| 仅调大超时 | 否 | 是 | 中 |
| preStop + 信号捕获 | 是 | 是 | 低 |
从表格可以看出，只有将等待流量切走与进程内平滑退出结合起来，才能真正实现用户无感知的 Pod 终止。建议所有面向用户的微服务都按此标准落地配置。
总结建议
Graceful Shutdown 不是高级特性，而是 K8s 工作负载的必备项。运维侧设置合理的 terminationGracePeriodSeconds 与 preStop，研发侧保证进程正确处理 SIGTERM，两者配合即可消除绝大多数下线故障。在接入服务网格或独立注册中心时，还应把注销动作放进 preStop，让下线更彻底。
实际落地时，可先在测试环境用删除 Pod 配合日志观察来验证，确认无报错后再推到生产。当每次发布都不再引起错误率抖动，便说明你的 Kubernetes Pod 终止 Graceful Shutdown 配置已真正生效。
KubernetesGraceful_Shutdownpod_termination修改时间：2026-08-10 23:21:18