Kubernetes 故障排查手册：从 Pod 异常到集群级事故

Kubernetes 故障排查最怕两件事：一是看到 Pod 不正常就直接重启，二是被大量 YAML 和组件名淹没。有效排障需要分层思维：先判断影响面，再定位责任域，然后验证假设，最后执行最小修复动作。

这篇文章给出一套生产可用的排障路径，适合值班、故障演练和团队 runbook 建设。

第一步：判断影响面

先回答三个问题：

• 是单个 Pod、单个服务、单个 namespace，还是整个集群？
• 是用户请求失败，还是内部监控发现异常？
• 是刚发布后出现，还是没有变更也出现？

影响面决定优先级。如果核心入口 5xx 正在上升，应先考虑回滚、扩容、摘流量等止血动作，再深入分析根因。如果只是单个非核心 Pod CrashLoop，可以按常规流程排查。

Pod 异常

查看 Pod 状态：

kubectl get pod -n <namespace> -o wide
kubectl describe pod <pod> -n <namespace>
kubectl logs <pod> -n <namespace> --previous

常见状态：

• Pending：调度失败、PVC 未绑定、镜像拉取等待。
• CrashLoopBackOff：容器启动后崩溃。
• ImagePullBackOff：镜像地址、凭证、网络或仓库异常。
• OOMKilled：内存超过限制或节点内存压力。
• Terminating 卡住：finalizer、存储卸载、节点失联或进程不退出。

CrashLoopBackOff 不要只看当前日志，很多容器已重启，关键错误在 previous 日志里。

调度失败

Pending 的第一入口是 Events：

kubectl describe pod <pod> -n <namespace>

如果看到 Insufficient cpu 或 Insufficient memory，说明 requests 无法被满足。看节点实际使用率没有意义，调度器看的是可分配资源和已请求资源。

如果看到污点不容忍或亲和性不匹配，要检查：

• nodeSelector
• nodeAffinity
• tolerations
• topologySpreadConstraints
• namespace ResourceQuota
• 节点池标签

如果 PVC 未绑定，要检查 StorageClass、PV、可用区和 CSI 状态。

Service 不通

Service 故障要确认 selector 和 endpoint：

kubectl get svc -n <namespace>
kubectl describe svc <service> -n <namespace>
kubectl get endpointslice -n <namespace> -l kubernetes.io/service-name=<service>

如果 endpoint 为空，通常是 Pod labels 不匹配，或 Pod readinessProbe 未通过。Ingress 返回 503 时，endpoint 为空是高频原因。

如果 endpoint 存在但访问失败，用临时 Pod 在集群内测试：

kubectl run net-debug --rm -it --image=curlimages/curl -- sh
curl -v http://service.namespace.svc.cluster.local:port/health

这样可以把外部负载均衡和 Ingress 排除掉。

Ingress 异常

Ingress 排查按链路走：

1. DNS 是否解析正确。
2. 外部负载均衡是否健康。
3. Ingress Controller 是否 Ready。
4. Ingress host/path 是否匹配。
5. Service 是否有 endpoint。
6. 应用是否监听正确端口。

查看 Ingress Controller 日志通常能快速区分 502、503、504 的原因：

kubectl logs -n ingress-nginx deploy/ingress-nginx-controller

不同 Controller 命名空间和对象名称不同，要按实际环境调整。

DNS 故障

DNS 问题表现为服务名解析失败、应用启动慢、偶发连接超时。先测试集群 DNS：

kubectl run dns-test --rm -it --image=busybox:1.36 -- nslookup kubernetes.default
kubectl -n kube-system logs deploy/coredns

关注 CoreDNS 副本、CPU、内存、错误日志、上游 DNS 延迟。如果业务请求量大，CoreDNS 副本太少会成为瓶颈。

应用层也可能放大 DNS 问题。例如短连接频繁创建、每次请求都解析域名、连接池配置不合理。

节点异常

节点 NotReady 或压力状态会影响大量 Pod。查看：

kubectl get nodes
kubectl describe node <node>

关注 Conditions：

• MemoryPressure
• DiskPressure
• PIDPressure
• NetworkUnavailable
• Ready

节点磁盘压力常见于容器日志未轮转、镜像堆积、emptyDir 失控。内存压力可能触发驱逐，导致 Pod 重建。PID 压力通常与进程泄漏有关。

存储异常

PVC 挂载失败通常出现在 Events 中。常见原因：

• CSI Controller 或 Node 插件异常。
• 卷和节点不在同一可用区。
• 文件系统损坏。
• 多节点写入模式不支持。
• 云盘达到挂载数量限制。

对数据库类服务，存储故障排查要谨慎。不要随意删除 PVC 或强制重建 Pod，先确认数据副本和备份状态。

控制面异常

控制面问题会表现为 kubectl 慢、资源创建失败、控制器不同步、调度延迟。重点看：

• APIServer 请求延迟和错误率。
• etcd 延迟和磁盘。
• controller-manager 队列。
• scheduler 调度失败和延迟。
• Webhook 超时。

准入 Webhook 是常见隐患。某个 Webhook 服务不可用，可能导致所有 Deployment 创建失败。查看错误信息中是否包含 webhook timeout、certificate 或 service not found。

变更关联

生产事故中，最近变更通常是最重要线索。排查时快速确认：

• 最近是否发布新镜像。
• 是否修改 ConfigMap 或 Secret。
• 是否升级 Ingress、CNI、CSI。
• 是否调整 HPA、资源限制、探针。
• 是否有节点维护、云网络变更、安全组变更。

如果事故影响用户，优先回滚最近变更，再做深度根因分析。不要在事故高压中追求一次性解释所有现象。

总结

K8s 排障要有层次感：先影响面，再链路，再对象，再事件和日志。Pod、Service、Ingress、DNS、节点、存储、控制面都有自己的入口信号。把这些路径写成 runbook，并通过演练让团队熟悉，比临时搜索命令可靠得多。真正高效的排障不是记住最多命令，而是知道每个现象背后可能是哪一层在说话。