来源：不爱笑的青年 | 发布日期：2026-07-15

K8s 故障排查快速参考 — 从现象到根因

不靠重启玄学，靠分层定位。铁律：先看后动，不要上来就 delete pod 或 restart 容器运行时——这会清空最关键的排查现场。

黄金五步思维模型

90% 的 K8s 故障，kubectl describe + kubectl logs 就能定位。

Pod 常见故障定位

Pending（调度不出去）

第一步： kubectl describe pod <pod> -n <ns> — 重点看 Events 段落。

ImagePullBackOff / ErrImagePull

CrashLoopBackOff

定位顺序：

1. 看日志：kubectl logs <pod> --previous（上一个崩溃容器的日志）
2. 看退出码：kubectl describe pod 里 Last State: Terminated, Exit Code

OOMKilled 与 Exit Code

Node NotReady

⚠️ 真实踩坑： 磁盘满是最常见的 NotReady 原因。告警链：磁盘 >85% → kubelet 驱逐 Pod → 100% → NotReady。磁盘监控必须配上。

Service 不通 / Ingress 502

Service 访问不通定位链路

Endpoints 为空的经典原因： Service 的 Selector 和 Pod 的 Label 对不上。用 kubectl get pods --show-labels 核对。

Ingress 502/504

PVC Pending

kubectl describe pvc 的 Events 会直接告诉你为什么绑不上——这一步能解决 80% 的存储故障。

CPU Throttling 与 OOM

OOM 建议： limits.memory ≥ 峰值用量 × 1.2，并用监控观察实际 RSS。

⚠️ 经典误区： requests=limits 设成一样，Pod 变成 Guaranteed 等级，一点点超发就被 OOM 或 Throttling。普通无状态服务建议 limits 略大于 requests，给一点弹性空间。

黄金排查命令速查表

# ① 看Pod状态与原因
kubectl get pods -n <ns> -o wide
kubectl describe pod <pod> -n <ns>   # 重点看Events

# ② 看日志（上一个崩溃容器加 --previous）
kubectl logs <pod> -n <ns>
kubectl logs <pod> --previous -n <ns>

# ③ 进容器调试
kubectl exec -it <pod> -n <ns> -- sh

# ④ 看Service与Endpoint
kubectl get svc,endpoints -n <ns>
kubectl describe svc <svc> -n <ns>

# ⑤ 看节点
kubectl get nodes
kubectl describe node <node>
kubectl get events -n <ns> --sort-by=.lastTimestamp

# ⑥ 看资源使用（需metrics-server）
kubectl top pods -n <ns>
kubectl top nodes

# ⑦ 看系统组件日志（Master节点上）
journalctl -u kubelet -n 100
journalctl -u containerd -n 100

# ⑧ 网络连通性测试
kubectl run test --rm -it --image=busybox -- nslookup <svc>.<ns>.svc.cluster.local

故障决策树

关联页面