平滑下线依赖就绪探针和prestop钩子，而非存活探针：就绪探针失效可立即摘流，prestop执行业务清理，terminationgraceperiodseconds保障优雅终止；并发状态仅用于就绪探针，存活探针须保持轻量、无依赖。
不能用并发状态配合存活探针实现平滑下线。存活探针（Liveness Probe）的职责是判断容器是否“还活着”，它只管重启——一旦失败，Kubelet 就会杀掉容器并拉起新实例。这与“下线”逻辑完全冲突：下线需要先停流量、再清理、最后终止，而存活探针触发的是无差别重启，会中断长连接、丢失请求、加剧抖动。
平滑下线靠的是就绪探针 + preStop 钩子
真正承担下线职责的是就绪探针（Readiness Probe）和生命周期钩子（preStop），不是存活探针：
- 就绪探针失效 → 流量立即停止进入：当微服务因高并发导致通道阻塞（如 DB 连接池耗尽、HTTP 队列堆积、RPC 超时率飙升），/health/ready 端点应主动返回非 200，K8s 会立即将该 Pod 从 Service 的 Endpoints 中剔除，新请求不再打进来
- preStop 钩子 → 执行业务级清理：在 SIGTERM 发出前，K8s 会执行 preStop，此时可调用应用内部关闭接口（如 /shutdown）、向注册中心发起主动下线、释放连接池、取消异步任务、写入下线日志等
- terminationGracePeriodSeconds → 保障宽限期：preStop 和后续的优雅关闭过程必须在这个时间内完成，建议设为 ≥20s，避免被强制 SIGKILL 中断
并发状态必须只用于就绪探针，不能掺进存活探针
高并发通道状态（如 DB 连接池使用率、HTTP 线程队列长度、下游超时率）反映的是服务“能否可靠处理请求”，这是就绪性问题，不是存活性问题：
- 把数据库连通性检查放进 liveness 端点，一次网络抖动就会触发重启，新旧 Pod 同时卡顿，雪崩风险陡增
- 存活端点（如 /health/live）应只做本地、无依赖、毫秒级判断：读取内存标志位、检查 /proc/self/stat 状态、或 echo ok > /tmp/alive
- 就绪端点（如 /health/ready）才应集成并发指标校验，例如“DB 活跃连接数 ≥95%”或“gRPC 健康连接数
滚动更新与故障节点下线要区分场景
滚动更新时的“下线”是计划内行为，靠就绪探针+启动探针协同；而故障节点的“下线”是被动响应，依赖实时通道状态驱动就绪探针快速摘流：
- 新 Pod 启动慢？用 startupProbe 延迟启用其他探针，避免 initialDelaySeconds 不够导致误判
- 旧 Pod 已出现 CPU 飙高或部分功能失效？就绪探针需足够敏感（periodSeconds: 10, failureThreshold: 3），但又不误判（加缓冲阈值，如队列长度 > 200 才标未就绪）
- 人工介入时，可直接 patch Pod 的 readinessGates 或调用 /health/ready 返回 503，强制提前摘流
