Kubernetes 探针配错，Pod 会反复重启而不是直接报错

探针是 k8s 里最容易被复制粘贴带错的东西。三个探针各管一件事，配错的后果不是报错，而是 Pod 被无声无息地重启，日志里只有一行容器退出。

livenessProbe 管的是「活着吗」。失败就往死里重启。它只该检查进程本身还能不能响应，绝对不要在这里查数据库和下游服务。把下游依赖写进 liveness 是最常见的错配：下游抖三秒，你的整个服务被 kubelet 连环重启，本来只是慢查询，最后变成雪崩。原则是 liveness 的检查范围不要超出本进程边界。

readinessProbe 管的是「能接流量吗」。失败只是从 Service endpoints 里摘掉，容器不重启。依赖检查、预热未完成、连接池未建立，这些该放这里。滚动更新时它决定新 Pod 什么时候算就绪，配得太宽松会把还没热好的实例放进负载均衡，用户看到的是一波 502。

startupProbe 管的是「启动完了吗」。它通过之前，另外两个探针都不生效。给 JVM 应用准备启动时间最合适，避免为了迁就启动慢而把 liveness 的 initialDelaySeconds 调到 120 秒——那样真的死锁也要等两分钟才发现。

几个具体数值上的坑。timeoutSeconds 默认只有 1 秒，业务接口 GC 停顿一下就成了失败，建议至少 3 秒。failureThreshold 默认 3，配合 periodSeconds 10 秒，意味着 30 秒内连续失败才动作，这个组合对 liveness 来说通常太激进，可以放到 5 次。exec 探针每次都要 fork 一个进程，在高频下本身就有开销，能用 httpGet 就别用 exec。

排查方法：kubectl describe pod 看 Events 里的 Liveness probe failed 和 Killing container，再看 restarts 计数和间隔。如果是固定周期重启，基本就是探针问题；间隔不规律，更像是资源压力下的 OOMKilled，去查 lastState 的 exitCode 是不是 137。

一个经验值：任何探针配置上线前，把 periodSeconds 乘 failureThreshold 算成一个总容忍时间，问自己一句「我的服务真的能在这么久内恢复吗」。算不出来就是没想清楚。