本文定位：面向滚动发布、缩容和节点维护场景，按K8s优雅终止的流量摘除、preStop、SIGTERM和宽限期给出配置与验证口径。
K8s优雅终止要解决的不是“Pod能不能退出”，而是退出期间请求是否还会被继续打进来、应用是否有时间完成收尾、宽限期是否足够覆盖真实耗时。滚动发布、HPA缩容、节点维护和手动删除Pod都会触发终止流程，建议按“先摘流量，再处理SIGTERM，最后验证宽限期”的顺序配置。
先理解Pod终止生命周期
当Pod进入Terminating状态时，Kubernetes会触发容器终止流程。应用侧看到的通常是preStop钩子执行、进程收到SIGTERM、宽限期倒计时，以及宽限期结束后可能出现SIGKILL。很多请求中断问题就发生在这些步骤之间的时间差里。
图1：K8s优雅终止的关键时间线
可以把终止过程拆成四个判断点：
- 入口层是否已经停止把新请求分配给这个Pod。
- preStop是否执行了必要的摘流或等待动作。
- 应用进程是否正确响应SIGTERM并停止接收新任务。
- `terminationGracePeriodSeconds`是否覆盖preStop、请求处理和应用退出总耗时。
优雅终止属于Kubernetes应用生命周期治理的一环。如果你正在系统梳理发布、扩缩容和工作负载运行机制，可以从 Kubernetes容器专题 继续阅读相关内容。
preStop适合做什么，不适合做什么
preStop是容器终止前执行的生命周期钩子。它适合做轻量、可预测、耗时可控的退出准备，例如通知应用停止接收新请求、等待短暂摘流窗口、刷新本地状态或触发内部健康状态切换。
它不适合承担复杂迁移、长时间数据处理或依赖不稳定外部服务的任务。preStop执行时间也会消耗Pod的终止宽限期，如果这里写得过长，应用真正处理SIGTERM的时间反而会被压缩。
下面是一个常见的HTTP服务配置示例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-api
namespace: app-prod
spec:
replicas: 3
template:
spec:
terminationGracePeriodSeconds: 60
containers:
- name: web-api
image: example/web-api:1.0.0
ports:
- containerPort: 8080
lifecycle:
preStop:
exec:
command:
- /bin/sh
- -c
- |
wget -qO- http://127.0.0.1:8080/drain || true
sleep 10这个示例表达的是一种思路：先让应用进入drain状态，再等待入口层和连接逐步停止。`sleep 10`不是固定答案，实际值要根据网关、Service、Ingress、应用请求耗时和观测结果调整。
preStop不要替代应用退出逻辑
真正可靠的优雅退出仍要在应用内部处理。preStop可以帮助触发状态变化，但应用进程应该在收到SIGTERM后停止接收新任务、等待正在处理的请求完成，并在超时前退出。
如果应用本身忽略SIGTERM，只依赖preStop里的`sleep`，通常只能降低一部分中断概率，不能解决长请求、后台任务和连接池清理问题。
SIGTERM策略要落到应用代码和运行方式
SIGTERM是应用进程接收到的终止信号。Kubernetes可以发出信号，但是否能优雅退出，取决于应用运行方式和代码逻辑。常见问题包括入口脚本没有转发信号、主进程不是PID 1、应用框架没有注册退出钩子，或者关闭顺序没有考虑连接池和队列消费。
上线前至少检查：
- 容器主进程是否能直接接收SIGTERM。
- 如果使用shell脚本启动，脚本是否用`exec`把应用进程替换为主进程。
- 应用是否在SIGTERM后停止接收新请求。
- 正在处理的HTTP请求、队列消息或批处理任务是否有退出上限。
- 日志中是否能看到明确的shutdown开始和结束记录。
一个更容易处理信号的启动脚本通常会避免让shell长期占据PID 1：
#!/bin/sh
set -e
exec /app/server --config /etc/app/config.yaml对于HTTP服务，SIGTERM处理逻辑通常需要完成三件事：停止监听新请求、等待已有请求完成、关闭数据库连接或消息队列客户端。不同语言和框架写法不同，但目标一致：不要让进程在仍有请求处理时直接退出。
宽限期要覆盖完整退出预算
`terminationGracePeriodSeconds`不只是给应用的时间，它覆盖preStop和容器退出的总窗口。假设preStop等待10秒，应用最长请求处理需要25秒，关闭连接池还需要5秒，那么宽限期配置为30秒就可能偏紧。
更稳妥的做法是先估算退出预算，再留出少量缓冲：
| 退出阶段 | 需要估算的时间 | 风险信号 |
|---|---|---|
| 流量摘除 | 网关、Ingress、Service端点更新和负载均衡收敛时间 | Terminating后仍有新请求进入 |
| preStop执行 | 钩子命令、drain接口和等待窗口耗时 | preStop未结束应用已接近宽限期 |
| 请求处理 | 常规请求和少量长请求完成时间 | 502、连接重置、客户端超时 |
| 资源清理 | 数据库连接、队列消费者、缓存刷新 | 退出日志不完整或重复处理 |
宽限期过长也会影响发布效率
宽限期不是越长越好。过短会导致应用被强制结束，过长则可能让滚动发布、缩容和节点维护等待时间变长。建议把宽限期设置为“覆盖绝大多数正常退出场景”，同时用日志和指标识别极端长请求，再针对业务层做超时治理。
配置顺序：先摘流，再退出，再验证
优雅终止的配置不要从某一个字段孤立开始。更推荐按请求路径倒推：请求从入口进入服务，Pod即将退出时，要先让入口停止分配新请求，再让应用处理已有请求，最后确认Pod在宽限期内退出。
- 应用实现drain或readiness降级逻辑。
- preStop调用drain接口或执行轻量等待。
- 应用处理SIGTERM，停止接收新请求并等待已有任务完成。
- 设置`terminationGracePeriodSeconds`覆盖完整退出预算。
- 用滚动发布、缩容和手动删除Pod验证行为。
在容器平台运维中，优雅终止应和发布策略、健康检查、弹性伸缩一起看，而不是只改一个YAML字段。更多K8s工作负载和运维基础内容，可以参考 K8s容器 分类下的相关文章。
验证路径：不要只看Pod是否消失
很多配置看起来已经生效，是因为Pod最终退出了；但真正要验证的是退出过程中是否仍有新请求进入、是否出现连接重置、是否被SIGKILL强制结束，以及应用日志是否完整记录收尾过程。
可以从三个场景验证：
kubectl rollout restart deployment/web-api -n app-prod
kubectl scale deployment/web-api -n app-prod --replicas=2
kubectl delete pod <pod-name> -n app-prod配合观察事件、端点和日志：
kubectl get pod -n app-prod -w
kubectl get endpointslice -n app-prod -w
kubectl describe pod <pod-name> -n app-prod
kubectl logs <pod-name> -n app-prod --previous
图2：优雅终止的三类验证场景
验证结果要回到请求链路
如果验证时仍出现请求中断，不要只把宽限期调大。先判断中断发生在哪一段：入口层是否继续分配流量，应用是否及时进入drain，SIGTERM处理是否生效，还是长请求超过了退出预算。不同位置的问题，对应的修复动作完全不同。
常见误区和调整建议
优雅终止配置最常见的误区，是把一个字段当成完整方案。只配置preStop、不处理SIGTERM，或者只调大宽限期、不验证流量摘除，都可能让问题在下一次高峰发布时再次出现。
建议优先避免这些做法：
- 只在preStop里写固定`sleep`，但应用不感知退出状态。
- 宽限期设置很长，却没有观察是否仍有新请求进入。
- 入口网关、Service和应用各自配置，没有统一验证场景。
- 发布验证只看Deployment完成，不看客户端错误率和应用退出日志。
- 把长任务和短请求放在同一退出策略里处理。
对于长连接、批处理、消息队列消费者和AI推理服务，优雅终止还要结合业务请求时长、队列确认机制和连接释放策略做专项设计。普通HTTP服务的配置经验不能直接套到所有工作负载上。
小结
K8s优雅终止的核心是把Pod退出变成可控流程：入口不再分配新请求，preStop触发轻量摘流，应用正确响应SIGTERM，宽限期覆盖完整退出预算。它不能保证所有极端请求都不中断，但可以显著降低滚动发布、缩容和节点维护中的突发失败概率。
如果你正在排查Terminating阶段的请求中断，建议先按时间线定位问题：新请求是否还进来、preStop是否耗尽宽限期、应用是否处理SIGTERM、是否发生强制结束。定位清楚后，再决定是改YAML、改应用退出逻辑，还是调整入口层策略。
常见问题
1. K8s优雅终止只配置preStop就够了吗？
通常不够。preStop可以触发摘流或等待，但应用进程仍需要正确处理SIGTERM。如果应用收到终止信号后直接退出，preStop只能延缓问题，不能让已有请求安全完成。更稳妥的组合是preStop触发drain，应用处理SIGTERM，宽限期覆盖完整退出窗口。
2. terminationGracePeriodSeconds应该设置多大？
建议按退出预算估算，而不是套固定值。你需要计算流量摘除时间、preStop执行时间、最长正常请求处理时间和资源清理时间，再留出少量缓冲。过短容易触发强制结束，过长会拖慢发布和缩容，因此要结合日志、指标和业务SLO逐步调整。
3. 为什么Pod已经Terminating，还会有请求打进来？
可能是端点更新、负载均衡、Ingress或网关摘流存在传播延迟，也可能是长连接或客户端重试让请求继续命中旧连接。此时应同时观察EndpointSlice变化、网关日志和应用访问日志，判断问题出在入口层还是应用退出逻辑。
4. 如何确认SIGTERM处理真的生效？
可以在应用退出钩子里记录shutdown开始、停止接收新请求、等待任务完成和退出完成等日志，再通过滚动发布或手动删除Pod触发验证。如果只看到容器退出但没有shutdown日志，可能是信号未传到应用进程，或应用没有注册退出处理逻辑。
