Skip to main content
排查的核心是快速缩小范围。本章给出一套可复用的方法论,再逐个击破最常见的故障场景。

排查方法论:自顶向下

1

确认集群层

kubectl get nodeskubectl get --raw='/readyz' 确认控制平面和节点整体健康。集群层有问题就先修集群,别在 Pod 上浪费时间。
2

定位到节点

kubectl describe node 查看节点 Conditions,确认是否有 DiskPressureMemoryPressureNotReady
3

定位到 Pod

kubectl get pods -A -o wide 找到异常 Pod,用 kubectl describe pod 看事件,事件里通常直接写着原因。
4

深入容器

kubectl logs 看应用输出,kubectl exec 进容器验证环境和网络。

万能命令组合

Pod 常见状态故障逐个击破

Pending:Pod 一直无法调度

现象:Pod 状态停留在 Pending,没有分配到节点。 原因:资源不足、节点污点未容忍、PVC 未绑定。 处理:
按事件提示处理:资源不足就扩容节点或调小 requests;污点问题就加 tolerations;PVC 未绑定就检查 StorageClass 和 PV 供给。

ImagePullBackOff:镜像拉取失败

现象:状态在 ImagePullBackOffErrImagePull 之间循环。 原因:镜像名或标签写错、私有仓库缺凭证。 处理:核对 image 字段拼写;私有镜像检查 imagePullSecrets 是否存在且凭证有效。

CrashLoopBackOff:容器反复崩溃

现象:容器启动后立刻退出,重启次数不断增加。 原因:应用自身报错、存活探针配错、启动命令有问题。 处理:
日志无输出时检查 command/args 是否正确;探针失败则放宽 initialDelaySeconds 给应用足够启动时间。

OOMKilled:内存超限被杀

现象:Pod 被终止,describe 中 Reason 显示 OOMKilled,Exit Code 为 137。 原因:容器实际内存超过 limits.memory,或节点内存耗尽。 处理:调大内存 limit,或排查应用内存泄漏。Java 应用注意堆参数与容器 limit 匹配。
OOMKilled 不是节点报错,是内核 OOM Killer 按 cgroup 限制杀容器。先看 limit,再看应用。

Service 不通的排查链

按顺序逐环验证:
在集群内起一个临时 Pod 测连通性:kubectl run test --rm -it --image=busybox:1.28 -- wget -qO- <svc>:<port>

节点 NotReady 排查

现象:kubectl get nodes 中节点状态为 NotReady 原因:kubelet 停止或报错、磁盘/内存压力、网络插件故障。 处理:
最常见的是磁盘写满。清理镜像 crictl rmi --prune 和日志后,kubelet 通常自动恢复。

debug 工具:kubectl debug

Kubernetes 1.25 起提供 Ephemeral Containers(临时容器),可以在不重启 Pod 的情况下注入调试容器:
临时容器无法配置资源限制,也不会被存活探针管理。用完即弃,不影响原应用。

延伸阅读