liveness 探针在下游故障时「杀自己」到底对不对：重启风暴 vs 僵尸实例，你们线上是怎么划这条线的？

【背景】 做了 5 年网络工程，最近在 K8s 上踩到一个很典型的连环事故，想借这个帖把「探针语义」这条线彻底吵清楚：

• 某订单服务，12 副本，K8s 1.27，前后各一层 LB（LVS + nginx upstream）。
• liveness 和 readiness 用的是同一个 HTTP endpoint（/healthz 里顺手 check 了一下 MySQL 和 Redis）。
• 某天 MySQL 主库切换，P99 从 20ms 飙到 8s，实例请求队列开始堆积。
• liveness 连续 3 次超时（timeoutSeconds=1, failureThreshold=3, periodSeconds=10）→ K8s kill → 重启后 JIT 没热、连接池冷启动，前 30s 更慢 → 继续被 kill。
• 一轮下来 12 副本里有 7 个在反复重启，流量挤到剩余 5 个，LVS 那边又因为 check_port 只看监听端口，把这批「进程活着但基本没服务」的实例当健康——最后全组雪崩，恢复靠人工 drain。

复盘时最大的分歧不是「怎么查下游」，而是：liveness 探针到底该不该感知下游状态？

【常见分歧 / 几种做法】

1. 严格分离派：liveness 只看进程级自检（事件循环活着、线程池没耗尽、GC 没卡死），readiness 才看下游依赖。理由：K8s 的 liveness 语义是「重启能自愈」，下游故障是外部事件，重启不但无效，还额外制造连接风暴和缓存冷启动的负外部性。
2. 统一派：同一个 endpoint，下游挂了实例就是僵尸（线程全被挂起请求占着），不如 kill 掉；重启速率有 failureThreshold 和 PDB 兜底，不会失控。
3. 熔断派：探针都别信，靠进程内熔断（Resilience4j / Hystrix）主动 shed load，探针只看「进程 + 线程池饱和度」。
4. LB 对齐派：真正咬人的是两层健康检查语义不一致——LVS/nginx 探「能不能收包」，K8s 探「能不能服务」，两边的「健康集合」根本不是同一个集合，流量调度在打架。

【我的倾向与理由】 我倾向严格分离，且 liveness 里绝不 check 下游依赖：

1. 从语义上，liveness 的前提是「故障是进程内部状态」——线程池耗尽、死锁、GC 卡死，这些重启有效；下游挂了重启无效，只会把「一次故障」放大成「一次重启风暴」。
2. 重启风暴是实测过的负资产：kill → 冷启动（JIT / 连接池 / 本地缓存）→ 更慢 → 再 kill，恢复时间被拉长一个量级；而 readiness 把实例摘出 endpoints 是「可控降级」——流量集中到剩余实例，配合容量余量和 HPA，至少是收敛的。
3. 网络层的同构经验：LVS 只 check 监听端口是 502 风暴的经典根因之一，健康检查应该探「能服务」而不是「还活着」；K8s 这层如果连「能服务」都让 liveness 去背，等于把两个语义揉成了一个，出事时没人知道该信谁。

但要留一个例外：如果「下游」其实是进程内嵌的（内嵌 DB、本地状态机、文件句柄），那它是内部状态，重启有效，这时 liveness check 它是合理的。这条边界怎么划，是我目前最想听大家掰扯的。

【想听大家在什么场景下怎么选】

• 你们的 liveness / readiness 具体怎么实现的？liveness 里有没有 check 下游？
• 有没有真实命中过「越重启越糟」的重启风暴？最后怎么收的（PDB？HPA？进程内熔断？还是干脆把 liveness 降级成 TCP 端口探测）？
• LVS/nginx + K8s 双层 LB 的「健康集合」语义，你们是怎么对齐的？
• 你们判断「重启能自愈」的具体指标是什么（线程池饱和度？队列长度？GC pause 阈值？），有没有可复用的自检清单？

参考了站内两篇相关讨论：《HikariCP 连接池 P99 抖动：pending 线程 / active 占比预警》和《一次请求拆 N 条 DB 查询的超时预算分配》——资源饱和与超时预算是「僵尸实例」的成因侧，本帖想聊的是「探测语义」这一侧。