不能用通道状态配合存活探针实现平滑降级下线，因其仅用于检测进程卡死并触发强制重启，跳过摘流、preStop和优雅终止；正确做法是就绪探针实时反馈通道健康度以摘除流量，配合preStop执行业务清理及terminationGracePeriodSeconds保障收尾时间。
不能用通道状态配合存活探针实现平滑降级下线。
存活探针（Liveness Probe）的唯一职责是判断容器进程是否“卡死”——比如 JVM 全线程阻塞、goroutine 死锁、主线程 panic 后未退出等不可恢复状态。它触发的是重启，不是下线；一旦失败，Kubelet 会直接 kill 容器并拉起新实例，中间没有摘流、没有清理、不走 preStop，也不等 graceful termination。
把数据库连接池耗尽、HTTP 队列堆积、RPC 超时率飙升这类高并发通道状态放进存活探针，等于让一次 DB 瞬抖或 GC 尖峰就强制重启服务，极易引发雪崩。
真正用于平滑降级下线的，是以下组合：
就绪探针（Readiness Probe） + preStop 钩子 + terminationGracePeriodSeconds
-
就绪探针暴露 /health/ready 端点，实时检查通道健康度
- DB 连接池使用率 ≥95%？
- HTTP 请求队列长度 > 200？
- Redis P99 响应 > 500ms？
- 下游 gRPC 可用连接数 < 3？
任一条件不满足，就返回 503，K8s 自动从 Service Endpoints 中移除该 Pod IP，新流量停止进入
-
preStop 钩子在 SIGTERM 前执行业务清理
- 调用 /shutdown 触发应用层优雅关闭（关闭线程池、释放 DB 连接、取消定时任务）
- 主动向注册中心（Nacos/Eureka）注销服务
- 写入下线日志、刷新本地缓存快照
-
terminationGracePeriodSeconds 设为足够长（建议 60–120s）
- 给 preStop 和活跃请求收尾留出缓冲时间
- 避免超时后被 SIGKILL 强杀
如果节点本身需整体下线，正确做法是：
- 先给节点打污点（如 node.kubernetes.io/out-of-service）驱逐 Pod
- 或用 kubectl cordon + drain，让 K8s 自动完成就绪摘流 → preStop → graceful termination 全流程
System.exit、存活探针失败、直接删 Pod 这些操作都会跳过整个优雅流程，导致请求中断、连接泄漏、数据丢失。
