在Kubernetes中排查Pod和Container崩溃的根本原因,建议采用以下系统化方法:
-
Pod状态检查:
- 使用
kubectl describe pod <pod-name>
查看Events字段,重点关注Warning/Error事件(如OOMKilled、CrashLoopBackOff)。 - 检查Pod状态是否为
CrashLoopBackOff
,这可能表明容器反复崩溃且重启策略为Always。
- 使用
-
容器日志分析:
- 通过
kubectl logs <pod-name> --previous
获取前一次崩溃的日志(适用于已重启的容器)。 - 使用
-c
参数指定多容器Pod中的特定容器(如Sidecar容器)。
- 通过
-
退出代码诊断:
- 非零退出码往往指向具体问题: • 137(128+9):OOMKilled(内存不足) • 143(128+15):SIGTERM终止 • 其他自定义错误码需结合应用逻辑分析
-
存活探针检查:
- 验证livenessProbe配置是否过于敏感(如检查间隔/超时设置不合理导致误杀)。
- 检查探针目标端点是否健康(HTTP GET路径/端口是否正确)。
-
资源限制验证:
- 确认requests/limits设置是否过小导致CPU/内存争抢
- 使用
kubectl top pod
监控实际资源消耗
-
镜像问题排查:
- 检查ImagePullBackOff错误(镜像权限/标签错误/仓库不可达)
- 验证容器启动命令(ENTRYPOINT/CMD)是否适配K8s环境
-
运行时调试:
- 通过
kubectl exec
进入容器检查文件系统状态 - 检查核心转储文件(需预先配置coredump路径)
- 通过
-
集群级分析:
- 使用
kubectl get events --field-selector involvedObject.name=<pod-name>
过滤相关事件 - 检查节点资源水位(CPU/内存/磁盘压力)
- 使用
建议结合Prometheus/Grafana建立监控基线,并通过EFK(Elasticsearch+Fluentd+Kibana)日志系统实现长期跟踪。对于偶发性崩溃,可临时设置Pod的restartPolicy为Never以保留崩溃现场。