常见故障排查
本教程共 65 篇 · 第 64 篇 · 更新于 2026-08-14 · 约 10 分钟阅读
本节目标:掌握 Pod 与节点常见异常状态的含义,熟练使用 describe / logs / get 三件套定位问题,并建立”先看事件再下结论”的排错习惯。
玩 Kubernetes,迟早会碰到 Pod 一直起不来、节点突然 NotReady。排错不可怕,可怕的是瞎猜。这一章给你一套最常用的方法论。
64-1 三件套是起点
无论 Pod 什么状态,先跑这三样,绝大多数线索都在里面:
# 看配置对不对
kubectl get pod <pod名> -o yaml
# 看事件,排错最核心
kubectl describe pod <pod名>
# 看容器日志
kubectl logs <pod名> [-c <容器名>]
describe 的 Events 一节记录了调度、拉镜像、挂载卷、启动的每一步和失败原因——先读事件再动手,能省下大把时间。
Note集群级问题(节点、控制平面)先看
kubectl get nodes/kubectl describe node <节点>的 Event。
64-2 Pod 一直 Pending
Pending 表示 Pod 还没被调度到任何节点。看 describe 的事件,常见原因:
- 资源不够:所有节点都满足不了 Pod 申请的 CPU、内存、GPU 或临时存储。要么删掉不用的 Pod,要么加节点。
- HostPort 被占:Pod 想用某个宿主机端口,但已被占用。一般改用 Service 暴露。
- 污点/亲和:节点有污点,Pod 没有对应容忍;或节点亲和规则太苛刻,没有节点匹配。
Tip事件里出现
0/x nodes are available: ... Insufficient cpu,答案就写在脸上——资源不足。
64-3 ImagePullBackOff
镜像拉不下来,Pod 会停在 ImagePullBackOff。常见原因:
- 镜像名拼错,比如把
alpine写成a1pine。 - 私有镜像没配拉取密钥(imagePullSecret)。
- 网络问题,节点访问不了镜像仓库。
可以先在节点上手动 crictl pull <镜像>(containerd 自带 CLI)验证能不能拉。私有镜像用 kubectl create secret docker-registry 创建 kubernetes.io/dockerconfigjson 类型的 Secret,再在 Pod 里引用:
spec:
containers:
- name: app
image: <私有镜像>
imagePullSecrets:
- name: my-secret
64-4 CrashLoopBackOff
这个状态说明容器起来了,但很快又崩了,反复重启。成因和排查三步(describe → logs → logs --previous)第 12 章 12-5 已讲过,这里只补两个角度:
- 先分清”真崩溃”还是”被杀”:
OOMKilled是内存超 limit 被杀,不是代码 bug,加内存只是止血(根因:limit 配低或应用泄漏);liveness 失败被杀是”假崩溃”,去查探针配置(第 14 章)。 - 与 ImagePullBackOff 是先后关系:先”拉镜像”再”启动”。镜像拉不下来停在
ImagePullBackOff,镜像就绪但进程起不来才进CrashLoopBackOff——看到后者说明镜像没问题,直接查启动命令和日志。
Warning看到
OOMKilled别只想着加内存:先确认是 limit 配太低还是应用真泄漏,盲目加 limit 会掩盖问题、拖垮节点。
64-5 其他常见状态
- Error:启动过程就报错。常因依赖的 ConfigMap/Secret/PV 不存在,或违反了安全策略、RBAC 没配好。
- Terminating/Unknown:节点失联时,其上的 Pod 会被标记为这两种状态。等节点恢复通常会自动清理;强制删除用
kubectl delete pod <pod> --grace-period=0 --force,但 StatefulSet 的 Pod 强制删容易导致数据问题,慎用。 - ContainerCreating 卡住:多半是网络插件(CNI)或存储挂载出问题。看 describe 事件,再翻 kubelet 日志。
64-6 Node NotReady
节点变成 NotReady,工作负载就没法调度上去。先 describe node 看事件,再查 kubelet 日志。常见原因:
- kubelet 进程挂了,重启它。
- CNI 网络插件没部署或异常,节点上 Pod 网络起不来。
- 磁盘满了,kubelet 自我保护停止工作,清一清镜像和临时文件。
- 资源(CPU、内存)被吃光,节点压力太大。
Note大规模集群里,API 服务器自身也可能 OOM。症状是
kubectl响应慢、List 操作失败、apiserver Pod 频繁重启。这种要调大 apiserver 的资源限制,或优化大型 List 的参数。
64-7 排查的通用心法
给你一套顺序,照着走不容易乱:
kubectl get看整体状态,定位哪个对象异常。kubectl describe读事件,这一步能解决八成问题。kubectl logs看应用说了什么。- 还不行,登录节点看 kubelet / 容器运行时日志。
- 控制平面组件(apiserver、调度器、控制器)日志,用
kubectl -n kube-system logs按标签取。
Tip善用标签取日志:比如
kubectl -n kube-system logs -l component=kube-apiserver --tail 100,能精准拿到 apiserver 的最近日志,不用去 grep 一堆 Pod。
一句话:排错不是玄学,是一套”看状态→读事件→查日志→下结论”的纪律。把 describe 读熟,你已经超过一大半新手了。