服务冷启动要 90 秒，livenessProbe 配的 initialDelaySeconds 是 10，Pod 每 2 分钟被杀一次，RESTARTS 已经 12。乍看像缓存或者权限的锅，追下去往往不是。
kubectl get pod api-5f7c9d8b4-lm2qx -o yaml | grep -A8 livenessProbe kubectl describe pod api-5f7c9d8b4-lm2qx | grep -i liveness
追下去是这么回事：存活探针从容器启动就开始计时，进程还没监听端口，探针连续失败达到 failureThreshold 就触发重启。重启后又从头冷启动，形成固定周期的循环。
「慢启动存活探针」这类改动最怕改一半，回滚脚本先准备好，再动生产。验证用真实数据走一遍，测试数据太干净，边界情况根本碰不到。
能分两步做的操作就别合成一步，中间看一眼返回值，出问题好判断。报错里带路径的，先去看那个路径在不在、权限对不对。
同一份配置存在多处的，先确认改的是被加载的那一份。
具体做法是，先看 describe 里 Liveness probe failed 的时间和重启间隔是否吻合；给慢启动服务加 startupProbe 成功一次后再交给 liveness；把 initialDelaySeconds 调到覆盖最慢启动时间 failureThreshold 留三次余量；用 exec 探针检查本地端口 别依赖还没起来的 HTTP 路由。
验收就看一点，新 Pod 启动后 90 秒内不再出现 Liveness probe failed RESTARTS 保持 0。