首页 / Kubernetes (k8s) 入门教程 / 常见故障排查

Kubernetes (k8s) 入门教程

常见故障排查

本教程共 65 篇 · 第 64 篇 · 更新于 2026-08-14 · 约 10 分钟阅读

Kubernetes故障排查PendingCrashLoopBackOffOOM

本节目标:掌握 Pod 与节点常见异常状态的含义,熟练使用 describe / logs / get 三件套定位问题,并建立”先看事件再下结论”的排错习惯。

玩 Kubernetes,迟早会碰到 Pod 一直起不来、节点突然 NotReady。排错不可怕,可怕的是瞎猜。这一章给你一套最常用的方法论。

64-1 三件套是起点

无论 Pod 什么状态,先跑这三样,绝大多数线索都在里面:

# 看配置对不对
kubectl get pod <pod> -o yaml

# 看事件,排错最核心
kubectl describe pod <pod>

# 看容器日志
kubectl logs <pod> [-c <容器>]

describeEvents 一节记录了调度、拉镜像、挂载卷、启动的每一步和失败原因——先读事件再动手,能省下大把时间。

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

这个状态说明容器起来了,但很快又崩了,反复重启。成因和排查三步(describelogslogs --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 排查的通用心法

给你一套顺序,照着走不容易乱:

  1. kubectl get 看整体状态,定位哪个对象异常。
  2. kubectl describe 读事件,这一步能解决八成问题。
  3. kubectl logs 看应用说了什么。
  4. 还不行,登录节点看 kubelet / 容器运行时日志。
  5. 控制平面组件(apiserver、调度器、控制器)日志,用 kubectl -n kube-system logs 按标签取。
Tip

善用标签取日志:比如 kubectl -n kube-system logs -l component=kube-apiserver --tail 100,能精准拿到 apiserver 的最近日志,不用去 grep 一堆 Pod。

一句话:排错不是玄学,是一套”看状态→读事件→查日志→下结论”的纪律。把 describe 读熟,你已经超过一大半新手了。