就绪探针是实现高并发下故障节点平滑降级的核心机制，需将DB连接池、HTTP队列等通道状态嵌入/health/ready端点并配置合理探测参数，而存活探针必须仅做轻量本地检查以避免误重启。
高并发通道状态本身不是K8s原生概念，它通常指微服务在高负载下对自身关键链路（如DB连接池使用率、HTTP线程队列长度、RPC超时率、消息积压量等）的实时监控指标。要实现“故障微服务节点的平滑降级”，核心不是靠通道状态直接触发K8s动作，而是将这些状态**转化为就绪探针（Readiness Probe）的判断依据**，再配合存活探针（Liveness Probe）做分层处置。关键在于：通道状态用于决定“是否该接流量”，存活探针只管“进程是否卡死”，二者职责必须分离。
把通道状态接入就绪探针，让Service自动摘流
就绪探针是实现平滑降级的主力。当某Pod因高并发导致内部通道阻塞（比如数据库连接池耗尽、HTTP请求队列堆积超过阈值），它应该主动向kubelet报告“未就绪”，从而被Service从Endpoint中移除，新流量不再打入，但已有长连接可自然处理完——这就是平滑降级的起点。
- 在应用中暴露一个健康检查端点（例如
/health/ready），该端点不仅返回HTTP 200，还同步校验关键通道状态：检查DB连接池活跃数是否≥95%、Redis响应P99是否＞500ms、下游gRPC健康连接数是否＜3个等 - 避免简单返回
{"status":"UP"}。Spring Boot可自定义HealthIndicator；Golang可用http.HandlerFunc内嵌指标判断逻辑；Node.js可在Express路由中读取Prometheus client本地指标或调用内部metrics接口 - 就绪探针配置需留出缓冲余量：
initialDelaySeconds: 60（给启动时间），periodSeconds: 10（高频感知抖动），failureThreshold: 3（连续3次失败才摘流，防瞬时毛刺误判）
存活探针保持轻量，绝不与通道状态耦合
存活探针的目标是发现不可恢复的僵死状态（如JVM full GC卡死、goroutine全部阻塞、主线程panic后未退出）。如果把它也绑定到数据库连通性或外部依赖上，一次DB短暂抖动就会触发重启，新旧Pod同时抖动，反而加剧雪崩。
- 存活端点应只做本地快速检查：例如
/health/live仅读取一个内存标志位、检查/proc/<pid>/stat确认进程状态为R/S、或执行echo ok > /tmp/alive这类无网络、无IO、无锁的原子操作 - 探测频率不宜过高：
periodSeconds: 15–30，timeoutSeconds: 2，failureThreshold: 3，避免在GC或IO高峰时误判 - 绝对不要在liveness中发起HTTP调用、执行SQL、访问Redis或调用下游服务——它必须是毫秒级、确定性、无副作用的
结合启动探针，覆盖冷启动与热抖动全周期
Java/Golang微服务常有长启动时间（60–120秒）和运行中突发通道拥塞两种场景。单靠就绪探针无法兼顾：initialDelaySeconds设太短会误摘流，设太长又拖慢滚动更新。此时启动探针（Startup Probe）是关键桥梁。
- 为启动阶段单独配置startupProbe：路径同就绪端点（如
/actuator/health），但只关注“进程是否已监听端口+基础上下文加载完成”，不检查DB/Redis等依赖 - 设置足够宽松的容忍窗口，例如
failureThreshold: 60、periodSeconds: 1，允许最长60秒启动期，期间就绪和存活探针完全不生效 - 启动成功后，就绪探针立即接管，持续监控通道健康度；存活探针则始终只盯住进程存活信号
降级不是终点，需配套可观测与人工干预闭环
就绪探针摘流只是第一道防线。若大量Pod频繁进入“未就绪”状态，说明系统已处于亚健康边缘，必须触发后续动作：
- 所有健康端点应返回结构化JSON，包含
status、checks明细（如"db": {"status":"DOWN","error":"connection timeout"}），方便Prometheus抓取并告警 - 配置告警规则：当集群内就绪失败Pod数占比＞10%，或某服务连续5分钟就绪失败率＞30%，立即通知SRE介入
- 在CI/CD流程中加入探针配置校验：禁止liveness与readiness共用同一路径、禁止liveness中出现external-http-get字段、禁止failureThreshold＜2
