K8s PodCrashLoopBackOff假阳性排查

K8s Pod CrashLoopBackOff"假阳性"排查------技术复盘

问题现象

测试环境某服务部署后，Pod 反复进入 CrashLoopBackOff 状态。kubectl describe pod 显示 Liveness probe failed: HTTP probe failed with statuscode: 503。但容器内应用日志没有任何异常，进程也没有 OOM。

诡异的是：同样的镜像在本地 Docker 跑完全正常，JVM 启动只要 8 秒，但 K8s 里就是反复被杀。

排查过程

Step 1 --- 看 Events

复制代码

Warning  Unhealthy   Liveness probe failed: Get "http://10.244.1.23:8080/health": dial tcp 10.244.1.23:8080: connect: connection refused

以为是端口没起来，但容器日志显示应用在第 9 秒已经开始监听 8080。

Step 2 --- 看 Probe 配置

yaml 复制代码

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
  failureThreshold: 3

关键数字：5 + 5×3 = 最多给 20 秒。但问题出在这里------这个应用在 K8s 环境首次启动时要做 DB 连接池预热 + 配置中心拉取，实际耗时约 12-15 秒。initialDelaySeconds: 5 太短，probe 从第 5 秒就开始打，连打 3 次都失败后直接 kill。

Step 3 --- 验证根因

用 kubectl logs --previous 看上一次被杀容器的日志：应用在第 9 秒打印 "Server started on 8080"，但 liveness probe 已经在第 15 秒判定失败并 kill 了容器。应用刚起来就被杀，重启后又是同样循环。

根因

initialDelaySeconds 配置太激进，少于应用实际启动耗时。Liveness probe 在应用还没准备好时就开始探测，达到 failureThreshold 后 Kubelet 直接 kill 容器。每次重启又是同一个循环 → 雪崩。

解决方案

立即止血

yaml 复制代码

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 5
  failureThreshold: 3

# 更优方案：用 startupProbe 替代 initialDelaySeconds
startupProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 0
  periodSeconds: 10
  failureThreshold: 6
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  periodSeconds: 10

startupProbe 的正确使用姿势

K8s 1.16+ 原生支持
先等 startupProbe 通过，再开始 liveness 检查
慢启动应用专用，避免 initialDelaySeconds 的"一刀切"陷阱

复盘总结

维度	要点
Liveness ≠ Startup	Liveness 用于运行时健康检查，不是启动检查。K8s 1.16+ 引入 startupProbe，专门解决慢启动被杀的问题
initialDelaySeconds 的坑	这个值是对"所有场景"的兜底，而 pod 启动耗时可能因节点负载、网络延迟、镜像拉取速度而异
Probe 三条黄金法则	① 有慢启动应用 → 加 startupProbe；② initialDelaySeconds ≥ 90% 分位启动耗时；③ liveness probe 要轻量，别做 DB 查询
排查技巧	kubectl logs --previous 看上次被杀容器的日志，kubectl get events --sort-by='.lastTimestamp' 按时间排序 events

一句话：如果你的 Pod 在 K8s 里反复 CrashLoopBackOff 但本地完全正常，99% 是探针配置问题。先加 startupProbe，再调参。

#K8s #DevOps #故障排查 #每日技术复盘