平滑降级依赖就绪探针、prestop 钩子与 k8s 生命周期协同：就绪探针主动摘流，prestop 执行业务清理，严格遵循终止时序，区分可恢复过载与僵死状态，避免雪崩。
不能靠存活探针（Liveness Probe）实现平滑降级——它只负责重启僵死容器，不是为降级设计的。真正起作用的是就绪探针（Readiness Probe）配合 preStop 钩子与 K8s 生命周期流程，形成一套可预期、不中断、不雪崩的故障节点处置链。
就绪探针是摘流的第一道闸门
当微服务因高并发出现通道阻塞（如 DB 连接池耗尽、HTTP 请求队列堆积、RPC 超时率飙升），它必须主动“说自己不行”，而不是等 K8s 杀掉再重启。关键动作是：
- 暴露独立的 /health/ready 端点，内部校验真实业务就绪状态：比如检查连接池使用率是否 ≥95%、本地缓存是否加载完成、下游依赖是否健康
- 避免和存活端点共用同一路径（如都指向
/health），否则一次数据库抖动会同时触发摘流 + 重启，失去观察窗口 - 配置合理探测参数：
initialDelaySeconds: 60（留足启动时间）、periodSeconds: 10（高频感知异常）、failureThreshold: 3（连续失败才摘流，防毛刺误判）
preStop 是清理残留的关键窗口
就绪探针失败后，Pod 已从 Service Endpoints 中移除，新请求不再进入。此时必须在进程被终止前完成业务级收尾：
- 调用应用内 shutdown 接口（如
POST /shutdown），关闭线程池、释放 DB 连接、取消定时任务 - 向注册中心（Nacos/Eureka/Consul）发送主动下线请求，防止其他服务继续发现该实例
- 执行 shell 脚本清理临时文件、释放分布式锁、写入下线日志
-
注意：preStop 执行时间会计入
terminationGracePeriodSeconds，建议设为 ≥20s，避免被强制 SIGKILL 中断
严格遵循 K8s 终止流程节奏
平滑降级依赖 K8s 原生生命周期的时序保障，顺序错一步就可能丢请求或卡住：
- 就绪探针失败 → Service 自动剔除该 Pod IP（流量停止流入）
- K8s 发起删除请求 → Pod 状态变为
Terminating - 立即执行 preStop 钩子（如有）→ 完成注册注销与连接清理
- 发送 SIGTERM 信号 → 应用捕获后拒绝新请求，等待活跃请求自然结束
- 等待
terminationGracePeriodSeconds（默认 30s）→ 超时则发 SIGKILL 强制终止
故障节点要区分“可恢复”和“已僵死”
对不同状态的节点，处理逻辑必须分层：
- 若只是短暂过载（如 CPU 突增、慢 SQL 拖累响应），就绪探针应快速摘流，preStop 清理后让其自然恢复，避免重启引入抖动
- 若进程已卡死（如 goroutine 全阻塞、JVM full GC 卡住），存活探针应仅做轻量本地检查（如读内存标志位、查 /proc/pid/stat），在确认不可恢复时触发重启
- 绝对不要在 liveness 中调用 DB、Redis、HTTP 或下游服务——那是就绪探针的事，混用会导致雪崩式重启
