在云原生时代，Kubernetes（K8s）已经成为容器编排的绝对标准。然而，K8s虽然强大，但其架构的复杂性也让无数运维和开发人员“踩坑”无数。从Pod启动失败到网络不通，从存储挂载超时到集群崩溃，排查K8s故障往往像是在迷宫里找出口。

为了帮助大家快速定位问题，本文盘点了Kubernetes在生产环境中最常见的十大故障，并提供了相应的排查思路。掌握这些，你的云原生运维之路会顺畅很多。

一、Kubernetes十大常见问题排查

1.Pod一直处于Pending状态

现象：Pod创建后一直卡在Pending，不进入Running。

原因：通常是调度器无法为Pod找到合适的节点。最核心的原因是资源不足（CPU/内存不足），或者节点存在污点（Taints），导致Pod无法容忍。也可能是PVC未绑定。

排查：执行`kubectl describe pod<pod-name>`，查看底部的`Events`信息，通常会提示`Insufficient cpu/memory`或`node(s)had taint`。

2.Pod陷入CrashLoopBackOff循环

现象：Pod启动后立刻退出，反反复复重启，状态为CrashLoopBackOff。

原因：这是应用层面的致命错误。可能是启动命令写错、配置文件缺失、环境变量不对，或者是端口被占用。

排查：执行`kubectl logs<pod-name>--previous`查看上一次崩溃前的日志。这是定位代码或配置错误的最有效途径。

3.拉取镜像失败(ImagePullBackOff/ErrImagePull)

现象：节点无法下载容器镜像。

原因：镜像名拼写错误、镜像仓库网络不可达、或者拉取私有镜像时缺少认证（ImagePullSecrets）。

排查：检查`Events`提示。如果是网络问题，尝试在节点上手动`docker pull`或`crictl pull`。如果是私有库，检查Secret配置。

4.服务无法访问或Pod网络不通

现象：集群内部或外部无法通过Service的IP/域名访问应用。

原因：常见于CNI网络插件（如Calico、Flannel）故障、Service的Label Selector匹配不到Pod、或Kube-proxy规则未生效。

排查：先看Pod是否Ready；检查Service的`Endpoints`是否有对应的Pod IP；检查目标机房的底层网络是否存在丢包或防火墙拦截。

5.PVC卡在Pending状态

现象：有状态应用（StatefulSet）无法启动，因为存储卷绑定失败。

原因：StorageClass配置错误、后端存储系统（如Ceph、NFS）故障、或者云厂商的云盘配额不足。

排查：`kubectl describe pvc<pvc-name>`查看存储提供商的报错信息。

6.节点状态变为NotReady

现象：控制台显示节点离线，该节点上的Pod被驱赶。

原因：Kubelet进程挂了、节点资源耗尽（如磁盘打满）、或者节点到API Server的网络断开。

排查：登录该节点，执行`systemctl status kubelet`和`journalctl-u kubelet`查看日志，重点检查磁盘使用率`df-h`。

7.容器被OOMKilled（内存溢出）

现象：Pod突然重启，退出代码为137。

原因：容器使用的内存超过了YAML中配置的`limits`上限，被内核强制杀死。

排查：查看`kubectl describe pod`中的`Last State`，确认退出原因为OOMKilled。需要调大内存`limits`，或排查应用是否存在内存泄漏。

8.集群内部DNS解析失败

现象：Pod之间无法通过Service名称互相访问，报错`Could not resolve host`。

原因：CoreDNS Pod挂掉、网络插件配置冲突、或节点的`resolv.conf`被篡改。

排查：启动一个测试Pod（如`busybox`），使用`nslookup kubernetes.default`测试解析，并检查CoreDNS的运行状态。

9.API Server响应缓慢或超时

现象：执行`kubectl get pods`极度缓慢，甚至报错`etcdserver:request timed out`。

原因：控制平面节点（Master）性能不足，ETCD磁盘I/O遭遇瓶颈，或者集群内存在大量高频的Watch请求。

排查：检查Master节点的CPU和磁盘IO。ETCD对磁盘延迟极其敏感，建议必须使用高性能SSD。

10.Ingress配置后网站502或404

现象：流量到达入口网关，但无法正常转发到后端服务。

原因：Ingress路由规则（Path、Host）写错；后端Service端口不匹配；或者Ingress Controller无法连通Pod网络。

排查：查看Ingress Controller的访问日志，确认请求是否被正确匹配，并检查后端Service的端口映射。

二、为什么你的K8s总是“玄学”报错？

排查上述问题时，很多运维人员会发现，YAML配置检查了无数遍，代码也没有bug，但K8s就是不稳定。网络时断时续、存储卷挂载超时、Pod莫名被驱逐。

这种时候，问题的根源往往不在K8s本身，而在于底层基础设施的短板。

Kubernetes是一个极度依赖底层网络和磁盘I/O的分布式系统。如果你的云服务器使用的是廉价共享带宽，晚高峰丢包严重，ETCD之间的心跳和节点通信就会超时，导致集群误判；如果你的云盘IOPS不足，频繁的日志写入和镜像拉取就会卡死，直接拖垮节点。

华纳云的云服务器方案，正是从底层基础设施维度，为K8s集群扫除了这些“木桶短板”：

高可用网络底座：华纳云香港及美国节点接入CN2 GIA精品线路，三网直连优化，晚高峰丢包率稳定在0.1%以下。稳定的底层网络意味着K8s节点间的通信、API Server的交互不会因为跨境拥堵而频繁超时，极大降低了“网络玄学”故障的发生率。

高性能NVMe存储：ETCD是K8s的大脑，对磁盘延迟极其苛刻。华纳云全系标配企业级NVMe SSD，提供极高的随机读写IOPS。无论是运行Master节点还是Worker节点，都能保障镜像秒级拉取、日志流畅写入，避免因I/O阻塞导致节点NotReady。

资源严格隔离：基于KVM的硬件级虚拟化，加上全系独享带宽，避免了“吵闹邻居”抢占资源导致的Pod意外OOM或被驱逐。

Kubernetes的稳定不仅取决于你的运维功力，更取决于你把它部署在什么样的基石上。掌握正确的排错思路，搭配一台底子扎实、性能不打折的服务器，才能让K8s真正成为业务腾飞的引擎。