获课地址：xingkeit.top/15462/

Kubernetes（K8s）虽然强大，但其复杂的架构和分布式特性意味着故障在所难免。在 2025 年的云原生环境里，随着集群规模扩大和多集群架构的普及，故障排查的难度也水涨船高。本文总结了 19 个在日常运维和开发中最高频出现的 K8s 故障，涵盖 Pod、节点、网络与应用层面，助你快速定位“元凶”，从容应对线上危机。

一、 Pod 状态异常：应用层的第一道防线

1. ImagePullBackOff / ErrImagePull

   • 现象： Pod 一直处于 ContainerCreating 状态，事件中报镜像拉取失败。
   • 原因： 镜像名称/Tag 拼写错误、私有仓库密钥配置错误、或镜像不存在。
   • 速查： 检查 Pod 的 .spec.containers.image 字段，确认 ImagePullSecret 是否正确，或直接在节点上尝试 docker pull/crictl pull 验证。

2. CrashLoopBackOff (CLBO)

   • 现象： Pod 启动后立刻退出，反复重启。
   • 原因： 应用进程内部错误（如 Java OOM、Python 语法错）、健康检查失败导致被杀、容器启动命令执行失败。
   • 速查： 查看 kubectl logs 寻找应用报错栈。如果日志为空，可能是应用启动瞬间崩溃，需查看前一个退出的容器日志 kubectl logs --previous。

3. Pending 状态（资源不足）

   • 现象： Pod 长期处于 Pending，无法调度。
   • 原因： 集群资源（CPU/内存）耗尽、节点设置了不满足的亲和性/反亲和性规则、Toleration（污点容忍）缺失。
   • 速查： 使用 kubectl describe pod 查看 Events，确认是 “Insufficient cpu” 还是 “Node didn’t match node selector”。

4. Pending 状态（PVC 绑定失败）

   • 现象： Pod 挂起，事件提示 PVC 无法绑定。
   • 原因： StorageClass 动态创建失败、没有可用的 PV、或处于不同可用区（AZ）导致跨区挂载失败。
   • 速查： 检查对应的 PVC 状态，确认 StorageClass 是否配置正确，底层存储是否已满。

5. RunContainerError / OOMKilled

   • 现象： 容器被终止，退出码为 137。
   • 原因： 内存使用超过了 Pod 设置的 Limits（内存限制）。
   • 速查： 查看监控，确认内存使用峰值。若为 Java 应用，检查堆外内存或 JVM 堆内存设置是否超出容器 Limit。

二、 节点与集群故障：底层的稳定性危机

1. Node NotReady

   • 现象： 节点状态显示为 NotReady，无法调度新 Pod。
   • 原因： Kubelet 进程挂掉、节点磁盘压力（DiskPressure）、PID 耗尽、网络插件（CNI）故障。
   • 速查： 登录该节点，使用 systemctl status kubelet 检查服务状态，使用 kubectl describe node 查看具体压力条件。

2. 节点 CPU/内存资源碎片化

   • 现象： 集群总体资源利用率看似很低，但新 Pod 无法调度。
   • 原因： 大量小 Pod 占用了节点资源，导致剩余资源不连续（例如：节点剩 1核，但 Pod 需要 2核）。
   • 速查： 使用 kubectl top nodes 结合资源请求分析，考虑部署碎片整理工具或配置 Pod 优先级抢占。

3. Kube-proxy 异常导致 Service 失联

   • 现象： Service IP 或 ClusterIP 无法连接，但 Pod IP 正常。
   • 原因： iptables/IPVS 规则未同步、Kube-proxy 容器挂了。
   • 速查： 进入任意节点，检查 iptables -t nat -L | grep <ServiceName> 是否有规则，或查看 Kube-proxy 日志。

4. Docker/CRI 运行时挂掉

   • 现象： 节点 NotReady，docker ps 无响应。
   • 原因： 存储驱动 Bug、Docker 守护进程死锁。
   • 速查： 重启容器运行时服务。如果频繁发生，检查磁盘是否已满或内核版本是否与容器运行时兼容。

三、 网络与存储故障：看不见的“血管”堵塞

1. DNS 解析失败（CoreDNS 故障）

   • 现象： 应用无法通过域名访问服务，IP 访问正常。
   • 原因： CoreDNS Pod 崩溃、DNS 缓存污染、 /etc/resolv.conf 配置错误。
   • 速查： 进入一个 Pod，nslookup kubernetes.default.svc.cluster.local。检查 CoreDNS 副本数是否健康，是否开启了 Endpoints 检查。

2. Pod 无法访问集群外网

   • 现象： Pod 无法解析外网域名，也无法 Ping 通外网 IP。
   • 原因： NAT 出口规则配置错误、节点未开启 IP 转发、DNS 策略限制。
   • 速查： 检查节点 cat /proc/sys/net/ipv4/ip_forward 是否为 1，确认 CNI 插件的 Masquerade 配置是否正确。

3. 网络 Pod 间互访不通（CNI 问题）

   • 现象： 跨节点 Pod 无法 Ping 通。
   • 原因： VxLAN/Overlay 封装问题、云厂商安全组未放行 NodePort、VPC 路由表缺失。
   • 速查： 抓包分析。确认节点路由表是否有对 Pod CIDR 的路由，检查 CNI 插件（如 Calico、Flannel）的 DaemonSet 是否正常运行。

4. PV 挂载卡死（MountTimeout）

   • 现象： Pod 一直处于 ContainerCreating，事件提示 “MountVolume.SetUp failed: timeout”。
   • 原因： NFS 服务器无响应、云硬盘驱动卡死、节点网络隔离。
   • 速查： 在节点上手动执行 mount 命令测试，确认存储服务端是否存活。

5. 文件系统 Read-Only（磁盘只读）

   • 现象： 节点突然 NotReady，日志显示 “Transport endpoint is not connected” 或 Read-only file system。
   • 原因： 磁盘坏道、I/O Error 导致内核挂起文件系统。
   • 速查： 登录节点执行 dmesg | grep error。这是严重硬件/内核故障，通常需要重启节点或隔离节点进行磁盘修复。

四、 业务与应用性能问题：隐性杀手

1. 应用启动极慢（Slow Start）

   • 现象： Pod 状态是 Running，但长时间无法响应请求。
   • 原因： 镜像过大、JVM 预热耗时、依赖的下游服务未就绪。
   • 速查： 检查 Readiness Probe（就绪探针）配置是否合理。优化镜像构建，使用 Init Container 等待依赖服务。

2. Rolling Update 卡住

   • 现象： 更新 Deployment 时，新 Pod 起不来，旧 Pod 不杀，更新卡住。
   • 原因： 健康检查配置错误（一直不健康）、maxSurge 和 maxUnavailable 设置为 0。
   • 速查： 检查 Deployment 的滚动更新策略，确保至少允许一个不可用 Pod。

3. Session 丢失

   • 现象： 用户刷新页面后登录状态消失。
   • 原因： Pod 重启后内存 Session 清空，且未配置共享 Session 或 Sticky Session。
   • 速查： 对于无状态服务，请确保将 Session 存入 Redis；对于有状态需求，配置 Service 的 sessionAffinity。

4. 日志采集丢失

   • 现象： ELK 或 Loki 平台看不到某段时间的日志。
   • 原因： Fluentd/Filebeat 繁忙、缓冲区溢出、Pod 退出太快来不及采集。
   • 速查： 检查日志采集组件的 Buffer 大小设置，确保其配置了 terminate_policy 为 flush 以捕获退出时的最后日志。

5. Helm Chart 回滚失败

   • 现象： 执行 helm rollback 后集群状态混乱或报错。
   • 原因： Chart 版本间的 CRD 不兼容、存在 Finalizer 导致资源无法删除。
   • 速查： 手动清理无法删除的 Finalizer，检查 Kubernetes API 版本在不同 Chart 中的变化，必要时强制删除资源后重新安装。

结语

在 2025 年，K8s 的故障排查虽然有了更多 AI 辅助工具，但核心逻辑依然离不开对这些基础组件原理的理解。遇到问题时，保持冷静，遵循“从 Pod 到 Node，从网络到存储”的排查路径，善用 kubectl describe 和 kubectl logs，绝大多数“不可知”的错误都能在几分钟内找到蛛丝马迹。希望这份手册能成为你运维口袋中的得力助手。