Kubernetes(k8s)中如何排查Pod和Container崩溃的根本原因？

1. 检查Pod状态：

   • kubectl get pods -o wide 查看Pod状态（如CrashLoopBackOff、Error）及所在节点。
   • kubectl describe pod <pod-name> 获取Pod事件，重点关注Events中的Warning信息（如镜像拉取失败、资源不足）。

2. 查看容器日志：

   • kubectl logs <pod-name> -c <container-name> 查看当前容器日志。
   • 若容器已重启，添加--previous参数查看崩溃前的日志：kubectl logs --previous ...

3. 分析容器退出码：

   • kubectl describe pod 中查找Last State: Terminated的Exit Code。
   • 常见退出码：
     • 137（OOMKilled，内存不足）→ 调整资源限制。
     • 1/255（应用错误）→ 检查应用日志。

4. 检查资源限制：

   • kubectl describe pod 查看Requests/Limits配置，确认是否因CPU/内存超限被终止。
   • 节点资源监控：kubectl top node 确认节点负载。

5. 探针配置验证：

   • 检查livenessProbe/readinessProbe的配置（如检测路径、端口、超时时间），错误探针会导致容器重启。

6. 镜像与启动命令：

   • 确认镜像版本和启动命令（command/args）正确，测试镜像本地运行：docker run <image>。

7. 进入容器调试：

   • 若容器未崩溃，直接进入：kubectl exec -it <pod-name> -- sh。
   • 若崩溃频繁，临时修改启动命令为sleep infinity保持容器运行。

8. 检查依赖服务：

   • 查看应用日志是否因数据库、API等依赖服务不可用导致崩溃。
   • 验证Service/DNS配置：kubectl get endpoints确认服务可达。

9. 集群事件排查：

   • kubectl get events --field-selector involvedObject.name=<pod-name> 过滤Pod相关事件。
   • kubectl get events --sort-by='.metadata.creationTimestamp' 查看全局异常事件。

10. 内核/系统日志：

    • 登录Pod所在节点，通过journalctl -u kubelet 或 /var/log/messages 检查系统级错误（如磁盘满、内核崩溃）。

在Kubernetes中排查Pod和Container崩溃的根本原因，建议采用以下系统化方法：

1. Pod状态检查：

   • 使用 kubectl describe pod <pod-name> 查看Events字段，重点关注Warning/Error事件（如OOMKilled、CrashLoopBackOff）。
   • 检查Pod状态是否为CrashLoopBackOff，这可能表明容器反复崩溃且重启策略为Always。

2. 容器日志分析：

   • 通过 kubectl logs <pod-name> --previous 获取前一次崩溃的日志（适用于已重启的容器）。
   • 使用 -c参数指定多容器Pod中的特定容器（如Sidecar容器）。

3. 退出代码诊断：

   • 非零退出码往往指向具体问题： • 137（128+9）：OOMKilled（内存不足） • 143（128+15）：SIGTERM终止 • 其他自定义错误码需结合应用逻辑分析

4. 存活探针检查：

   • 验证livenessProbe配置是否过于敏感（如检查间隔/超时设置不合理导致误杀）。
   • 检查探针目标端点是否健康（HTTP GET路径/端口是否正确）。

5. 资源限制验证：

   • 确认requests/limits设置是否过小导致CPU/内存争抢
   • 使用kubectl top pod监控实际资源消耗

6. 镜像问题排查：

   • 检查ImagePullBackOff错误（镜像权限/标签错误/仓库不可达）
   • 验证容器启动命令（ENTRYPOINT/CMD）是否适配K8s环境

7. 运行时调试：

   • 通过kubectl exec进入容器检查文件系统状态
   • 检查核心转储文件（需预先配置coredump路径）

8. 集群级分析：

   • 使用kubectl get events --field-selector involvedObject.name=<pod-name>过滤相关事件
   • 检查节点资源水位（CPU/内存/磁盘压力）

建议结合Prometheus/Grafana建立监控基线，并通过EFK（Elasticsearch+Fluentd+Kibana）日志系统实现长期跟踪。对于偶发性崩溃，可临时设置Pod的restartPolicy为Never以保留崩溃现场。