【背景】 先给结论：liveness 探针是 K8s 里最容易被低估的故障源，它不是部署模板里的勾选项，而是一条隐式的「自动重启回路」。
去年大促前一周，我们一个 8G 堆的 Java 服务（JDK 17，K8s 1.28，containerd 1.7）在压测里复现了一次：流量上来触发一次 Full GC 停顿约 6.2s，而 liveness 是 TCP 探针、periodSeconds=10、failureThreshold=3、timeoutSeconds=1——三次探测窗口内服务都「活着但没响应」，kubelet 直接 kill 容器重启。更糟的是根因（堆内存不足）并没有因为重启消失，新 Pod 起来 90s 后又进入同样的 GC 循环，12 副本在 20 分钟内被滚动打崩，最终靠手动 kubectl cordon 节点止血，服务整体不可用约 40 分钟。复盘后我们把 liveness 改成 httpGet、failureThreshold=5、periodSeconds=15，同时把 readiness 单独收紧——从那之后线上再没发生过探针触发的重启风暴。
这件事让我意识到一个口径问题：应用层的超时预算，我们按 P99 设；但 liveness 的容忍窗口，很多人也在按 P99 设。 这两个语义完全不同：应用超时是「慢了就放弃这次请求」，而 liveness 一旦失败，动作是「杀掉进程重启」——这是不可逆的、有扩散效应的操作。liveness 的容忍窗口理论上应该覆盖「最坏可恢复停顿」（GC 停顿、磁盘 flush、依赖抖动后的恢复窗口），而不是业务 P99。
【常见分歧 / 几种做法】 我见过三种典型姿势：
- 激进派：liveness = P99 口径，failureThreshold=3，快速失败快速拉起。适合无状态、冷启动 <30s、且已经确认 GC/IO 停顿上界的服务。
- 保守派：liveness 拉得很宽（periodSeconds=15~30，failureThreshold=5~10），宁可让坏 Pod 多活几秒，也不允许探针误杀。我们最终就是这套。
- 中间派 / 争论中：认为 K8s 缺一档「不健康但不重启」的状态——readiness 摘流量，liveness 重启，中间没有「标记降级、保留进程、等自愈」的档位。这个 feature 社区讨论了很多年（SIG-node 有过几次提案），至今没有标准方案，只能靠应用自己暴露 /health 的分级端点 + 外部控制器（KEDA、OPA、自研 operator）补。
还有一种更底层的分歧：liveness 探针到底应该测「进程存活」还是「服务可用性」？TCP 探针只证明端口在听；httpGet /health 证明进程能响应；但「能响应」和「能正确处理请求」是两回事。测得太浅会漏掉「活着但所有请求都 500」的僵尸 Pod，测得太深又会把「慢但活着」误判成死。
【我的倾向与理由】 我倾向保守派，并且把 liveness 的语义收窄为「只捕获确定性死锁 / 不可恢复故障」：
- 所有「慢」的情况交给 readiness 摘流量 + 上游熔断兜底；
- liveness 的容忍窗口按「最坏可恢复停顿上界」设，这个上界必须从 GC 日志（
-Xlog:gc*抓 max pause）、磁盘 iostat、依赖调用链里实测出来，不能拍脑袋； - 冷启动单独用 startupProbe 兜住，避免启动期的慢启动被 liveness 误杀。
理由很简单：liveness 失败的代价是「杀进程 + 重新冷启动 + 可能的重启风暴」，这是所有 K8s 自愈动作里扩散半径最大的一个。误判一次的代价，比让它多活 30 秒大得多。
【想听大家在什么场景下怎么选】
- 你们线上 liveness 的容忍窗口，是拍脑袋定的，还是真的从 GC / IO 停顿分布里量出来的？量过的话，上界一般是多少？
- 有没有团队给 liveness 做过分级（比如 /health/live 只测进程、/health/ready 测依赖、/health/deep 测业务）？外部控制器怎么接的？
- 「慢但活着」这个中间态，你们是靠 readiness + 熔断兜底，还是自己写了 operator 做「标记降级不重启」？踩过什么坑？
- 一个更尖锐的问题：如果 liveness 探针的误杀已经发生过一次，你们的事故复盘里，是把锅记在「探针配置」上，还是记在「根因（GC/IO/内存）」上？这两者的修复动作完全不同，团队里有没有共识？