优雅下线的核心是readinessProbe摘流与preStop清理配合：先通过readinessProbe将Pod从Service端点移除停止新请求，再执行preStop钩子完成注册注销、连接关闭等清理，最后发送SIGTERM并等待terminationGracePeriodSeconds宽限期。
存活探针（LivenessProbe）本身不用于“下线”，而是用于“重启”——它检测的是容器是否还健康运行。想靠它实现优雅下线，方向错了。真正承担优雅下线职责的，是就绪探针（ReadinessProbe）和生命周期钩子（preStop），配合合理的流程控制才能完成。
就绪探针才是下线的关键开关
当一个微服务实例开始故障但尚未崩溃时，它可能还在响应请求，只是响应缓慢或返回错误。此时 LivenessProbe 若配置不当，会反复杀掉容器、触发重启，反而加剧抖动；而 ReadinessProbe 可以及时将该实例从流量池中摘除：
- 在应用内部暴露可靠的健康检查端点（如
/actuator/health或自定义逻辑），能真实反映业务就绪状态（例如数据库连接正常、缓存加载完成、下游依赖可用） - 配置
readinessProbe，让 K8s 在探测失败后立即从 Service 的 Endpoints 中移除该 Pod IP —— 新请求再也不会进来 - 避免把 LivenessProbe 和 ReadinessProbe 指向同一个端点：若共用 /health，一次故障会同时触发摘流 + 重启，失去“观察窗口”
preStop 钩子处理残留连接与注册注销
就绪探针摘流后，已有长连接、异步任务、注册中心心跳等仍可能维持。preStop 是唯一能在 SIGTERM 前执行自定义逻辑的时机：
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 调用本地 HTTP 接口（如
http://localhost:8080/shutdown）触发应用层优雅关闭：关闭线程池、断开 DB 连接、取消定时任务 - 向注册中心（如 Nacos、Eureka、Consul）发送主动下线请求，确保其他服务不再发现该实例
- 执行 shell 脚本清理临时文件、释放锁、写入下线日志等
- 注意 preStop 执行时间计入
terminationGracePeriodSeconds，需预留足够缓冲（建议 ≥20s）
流程控制要点：顺序不能乱
K8s 终止流程有严格时序，必须按节奏配合：
- 第一步：ReadinessProbe 失败 → Service 自动剔除 Endpoints（流量停止进入）
- 第二步：K8s 发起删除 Pod 请求 → 状态变为
Terminating - 第三步：执行 preStop 钩子（如有）→ 完成业务级清理
- 第四步：发送 SIGTERM 给主进程 → 应用捕获信号，停止接受新请求、等待活跃请求结束
- 第五步：等待
terminationGracePeriodSeconds（默认30s）→ 超时则发 SIGKILL 强制终止
故障节点的特殊应对策略
对已出现故障但未完全宕机的节点（如 CPU 飙高、OOM 后部分功能失效），仅靠探针不够，需叠加人工干预：
- 通过
kubectl patch pod xxx -p '{"spec":{"readinessGates":[{"conditionType":"node.kubernetes.io/unreachable"}]}}'主动标记为不就绪（需启用 readinessGates） - 对关键服务，可配合 HPA 或自定义 Operator 监控指标（如 5xx 率 >10%、P99 延迟 >5s），自动打标并触发滚动更新
- 避免直接
kubectl delete pod：跳过探针校验和 preStop，极易导致请求中断或注册信息残留
