Pod 优雅终止时间由 terminationGracePeriodSeconds 控制，需结合 preStop 钩子、就绪探针快速失效及云环境同步延迟综合配置，确保无损下线。
Pod 的优雅终止时间由 terminationGracePeriodSeconds 字段控制，它定义了从 Kubernetes 发送 SIGTERM 到强制发送 SIGKILL 之间的最大等待时长。合理配置这个值，是实现无损下线的关键前提。
设置 terminationGracePeriodSeconds 参数
该字段直接写在 Pod 或其控制器（如 Deployment）的 spec 中，单位为秒。默认值为 30 秒，但多数业务场景需要根据实际关闭逻辑调整：
- 普通 Web 服务（如 HTTP API）：建议设为 30–60 秒，覆盖连接 draining 和请求完成时间
- 批处理或长事务型应用（如数据导出、模型推理）：可设为 120–300 秒，确保任务不被中断
- 若应用完全不处理 SIGTERM 或无清理逻辑，可设为 0（立即 SIGKILL），但不推荐
配合 preStop 钩子协同使用
preStop 钩子会在 SIGTERM 前执行，其运行时间也会计入总 grace period。因此必须确保：
Kubernetes Skills
下载
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
- preStop 执行耗时 ≤ terminationGracePeriodSeconds 设置值
- 常见用法：执行健康检查探针降级、调用注销接口、休眠等待负载均衡器同步（如云厂商 LB 同步延迟约 10–15 秒）
- 示例：
lifecycle: { preStop: { exec: { command: ["sh", "-c", "sleep 10"] } } }
就绪探针需快速失效
优雅终止的前提是新流量不再进入。就绪探针（readinessProbe）必须能在收到 SIGTERM 后迅速失败，否则 kube-proxy 不会及时摘除 Endpoint：
- 避免将 /health 检查与存活探针（livenessProbe）共用同一路径，否则可能掩盖终止状态
- 推荐做法：在 preStop 中主动修改健康接口返回码，或让应用在收到 SIGTERM 后立即返回 503
- 就绪探针的
periodSeconds建议 ≤ 2 秒，failureThreshold设为 1，加快摘除速度
验证与调优建议
配置生效后，需通过真实操作验证行为是否符合预期：
- 手动触发删除：
kubectl delete pod <name> --grace-period=60，观察 Pod 状态变化和日志 - 监控指标：关注 Pod 终止耗时、Service Endpoint 更新延迟、请求 5xx 率突增情况
- 云环境注意：AWS ALB、腾讯云 CLB 等存在同步延迟，建议 grace period 至少预留 20 秒缓冲
