容器频繁重启主因是livenessprobe配置不当：initialdelayseconds过短、timeoutseconds过小或failurethreshold过低，导致应用未就绪即被误判失败而重启；需结合kubectl describe、日志、端点实测及资源监控综合排查。
容器存活探针（LivenessProbe）频繁超时，意味着 Kubernetes 正在反复重启你的 Pod，服务无法稳定运行，必须立刻定位是应用响应慢、探针配置不合理，还是底层资源或网络异常。
确认是否真为 LivenessProbe 超时触发重启
执行 kubectl describe pod <pod-name></pod-name>，重点查看 Events 区域中是否有类似 Liveness probe failed: HTTP probe failed with statuscode: 0 或 Container <name> failed liveness probe, will be restarted</name> 的记录。
若 Events 中没有 Liveness 失败日志，但 Pod 仍在频繁重启，请先检查 restartPolicy 和容器退出码——【LivenessProbe 不会触发重启，除非 kubelet 明确判定其失败】，否则可能是应用自身崩溃导致的重启，与探针无关。
检查探针配置参数是否合理
方法一：核对 initialDelaySeconds 是否小于应用真实就绪时间
用 kubectl get pod <pod-name> -o yaml</pod-name> 提取当前 LivenessProbe 配置，重点关注 initialDelaySeconds。若该值为 10，但应用从启动到能响应 /health 请求实际耗时 45 秒，则前 3～4 次探测必超时，连续 failureThreshold 次后立即重启，形成“启动即死”循环。
方法二：验证 periodSeconds 与 timeoutSeconds 组合是否过激
默认 timeoutSeconds=1 秒，若后端依赖数据库连接或远程配置拉取，单次健康检查本身就要 2.3 秒，timeoutSeconds=1 必然失败。此时应将 timeoutSeconds 至少设为预期最大处理时长的 1.5 倍，例如设为 4。
方法三：检查 failureThreshold 是否过低
failureThreshold=1 表示只要一次超时就杀容器，毫无容错余地。生产环境建议设为 ≥3，配合合理的 periodSeconds（如 10s），可容忍短时抖动。注意：【successThreshold 对 livenessProbe 强制为 1，不可修改】。
验证健康端点实际响应行为
第一步：进入容器内部直连健康接口
执行 kubectl exec -it <pod-name> -- sh</pod-name>，然后运行 curl -v http://localhost:8080/health（端口和路径按实际调整）。观察是否返回 2xx 状态码、响应体是否为空、耗时是否超过 timeoutSeconds。
第二步：模拟 kubelet 探测频率持续压测
在容器内执行：while true; do curl -o /dev/null -s -w "%{http_code} %{time_total}s\n" http://localhost:8080/health; sleep 10; done。若出现大量 000 或超时，说明端点本身不稳定；若偶发慢，需结合 metrics 查看 GC、CPU 或线程阻塞情况。
第三步：检查端点逻辑是否引入副作用
很多团队把 /health 实现成“全链路自检”，包含查 DB、调下游、读磁盘文件。这违反了 LivenessProbe 幂等性原则——它只应反映进程是否存活，而非业务可用性。一旦 DB 临时抖动，/health 就失败，容器被误杀。应改为仅检查本地进程状态（如读取 /proc/self/stat）或轻量心跳。
排查底层资源与网络干扰
执行 kubectl top pod <pod-name></pod-name>，确认 CPU 和内存使用率是否长期接近 limit。若 CPU 使用率持续 95%+，则 HTTP handler 可能因调度延迟无法在 timeoutSeconds 内完成响应，表现为“超时”，实为资源争抢。
检查节点层面是否存在网络策略干扰：运行 kubectl get networkpolicy -A，确认无策略误拦截 localhost 流量；某些 CNI 插件（如 Cilium）在启用 eBPF 时会对 loopback 流量做额外校验，导致 probe 请求被静默丢弃。
最后验证 kubelet 日志：登录对应工作节点，执行 journalctl -u kubelet -n 1000 | grep -i "liveness\|probe\|<pod-uid>"</pod-uid>，查找是否出现 probe timeout after X seconds 或 failed to execute command 等原始错误，这是绕过 YAML 配置、直达问题根因的关键线索。
