机制定位
删除 Pod 不是瞬间消失，而是走一套固定流程：对象标记为 Terminating、从端点列表摘除、发送 SIGTERM 给容器主进程、等待 terminationGracePeriodSeconds 秒、仍未退出则发送 SIGKILL。适用平台是 Kubernetes。可以在信号之前用 preStop 钩子执行收尾动作（比如等负载均衡摘除、通知注册中心下线）。理解这套时序，才能解释「发布时出现的秒级 502」和「Pod 迟迟不退」。
基本信息
| 适用平台 | Kubernetes，Pod 级生命周期 |
|---|---|
| 宽限期 | terminationGracePeriodSeconds，默认 30 秒 |
| 信号顺序 | preStop 钩子 → SIGTERM → 宽限期到 → SIGKILL |
| 摘除时机 | 终止开始即标记，端点摘除与信号发送存在并行，故需要缓冲 |
典型使用场景
- 消除发布抖动：用 preStop sleep 等端点摘除完成，再开始退出接收新请求
- 缩短下线时间：任务型容器提前处理信号，宽限期可从 30 秒调到更短
- 长任务收尾：数据同步类容器需要更长的宽限期完成落盘
- 排查 Pod 卡在 Terminating：确认是进程不响应信号还是卷未释放
- 排查优雅关闭失败：应用未注册信号处理时会被强杀，连接被硬切
配置示例
配置示例
spec:
terminationGracePeriodSeconds: 60
containers:
- name: app
lifecycle:
preStop:
exec:
command: ["sh", "-c", "sleep 5"] # 等负载均衡摘除后再开始退出观察终止过程
观察终止过程
kubectl delete pod web-x --wait=false # 不阻塞，观察整个过程
kubectl get pod web-x -w # 状态从 Running 到 Terminating 再到消失
kubectl describe pod web-x | grep -i -A3 graceful # 宽限期与终止原因
kubectl get pod web-x -o jsonpath='{.metadata.deletionGracePeriodSeconds}'
kubectl get endpoints web-svc # 观察端点摘除时间点时序与影响
| 阶段 | 发生的事 | 常见问题 |
|---|---|---|
| 标记终止 | 对象进入 Terminating，开始摘除端点 | 摘除有延迟，此时仍可能有流量打到 |
| preStop | 钩子执行，计入宽限期 | 钩子写太久会挤掉应用自身的退出时间 |
| SIGTERM | 主进程收到信号，应停止接收并排空 | 应用不处理信号则直接进入下一步 |
| SIGKILL | 宽限期结束强行终止 | 连接被硬切，出现 502 与超时 |
宽限期默认 30 秒；超过未退出 kubelet 发 SIGKILL，preStop 的执行时间也计入宽限期，两者要一起核算。
终态 Pod 的删除是终止而非隔离，误删有状态服务的 Pod 会立刻触发重建，数据落盘与连接排空都需要应用配合。