Kubernetes生产环境故障排查指南：20个最常见问题与根因分析

Kubernetes 功能强大，但在复杂的生产环境中，一旦出现问题，排查往往涉及多个层面。大多数故障并非源于 Kubernetes 自身缺陷，而是资源、配置、网络与权限等组合因素导致的结果。

本文将系统梳理 K8s 生产环境中最常见的 20 类故障现象，并按排查方向进行分类归纳，帮助你在面对问题时能够快速定位，思路清晰。

01 Pod 启动与运行类故障（最常见）

1） Pod 一直处于 Pending 状态

常见原因：

• 节点资源不足：CPU 或内存（Memory）耗尽。
• 调度规则不匹配：NodeSelector / Affinity 条件无法满足。
• 存储未就绪：PersistentVolumeClaim (PVC) 处于 Pending 状态，未绑定到可用的 PV。
• 污点不容忍：节点存在 Taint，而 Pod 未配置相应的 Toleration。

排查指令：kubectl describe pod <pod-name> 查看详细事件。

2）ImagePullBackOff / ErrImagePull

常见原因：

• 镜像信息错误：镜像名称或标签（tag）拼写错误。
• 私有仓库认证失败：未正确配置 imagePullSecrets。
• 网络不通：节点无法访问指定的镜像仓库地址。

排查建议：查看 Pod 的 Events 信息通常比查看容器日志更直接有效。

3） CrashLoopBackOff

常见原因：

• 应用自身崩溃：容器启动后，主进程立即退出。
• 配置错误：应用配置文件、环境变量有误。
• 端口冲突：容器内端口已被占用。
• 探针配置过严：Liveness 或 Readiness 探针过早失败，导致重启循环。

排查重点：

• 查看容器最近一次的启动日志：kubectl logs <pod-name> --previous。
• 关注 Pod 的 restartCount。

4） Readiness 探针失败，Pod 不接收流量

常见原因：

• 探针配置错误：检查路径、端口或命令不正确。
• 应用启动缓慢：在探针超时前，应用尚未完成初始化。
• 依赖未就绪：Pod 依赖的数据库、缓存等外部服务不可用。

典型表现：Pod 状态为 Running，但通过 Service 无法访问。

5） Liveness 探针导致 Pod 频繁重启

典型问题：

• 探针误用：将业务逻辑检查（如依赖数据库）放入 Liveness 探针，一旦依赖抖动，Pod 就会被重启。
• 网络抖动误判：因网络瞬间波动导致探针失败，触发不必要的重启。

生产建议：Liveness 探针应用于判断进程本身是否存活，配置应相对保守，避免过度敏感。

02 节点与资源类故障

6） 节点状态为 NotReady

常见原因：

• Kubelet 异常：进程崩溃或配置错误。
• 磁盘空间耗尽：根目录或特定分区 100% 使用。
• 内存耗尽：节点 OOM，系统不稳定。
• 网络分区：节点与控制平面网络中断。

排查路径：使用 kubectl describe node <node-name> 查看节点条件，并登录节点检查 kubelet 服务日志。

7） Pod 被 OOMKilled

原因：

• 内存限制过小：Pod 或容器的 memory.limits 设置低于应用实际需求。
• 应用内存泄漏：应用自身存在 Bug，内存使用量持续增长直至突破限制。

核心认知：OOMKilled 是 Linux 内核行为，不是 Kubernetes 的 Bug，本质是资源规划问题。

8） CPU 被限流，应用性能下降

典型表现：

• CPU Limit 设置过低：应用在业务高峰期的实际 CPU 需求超过了预设的 limits。
• 负载预估不足：未充分考虑突发流量或批处理任务的资源需求。

重要提示：CPU limits 是硬性上限，一旦达到，容器进程将被内核限流（Throttling），导致响应变慢。在云原生/IaaS环境中，需结合监控数据合理设定。

9） 节点磁盘压力（DiskPressure）

常见来源：

• 容器日志膨胀：未配置日志轮转（logrotate）或日志级别不当。
• emptyDir 滥用：临时卷写入大量数据且未清理。
• 镜像层堆积：未定期执行镜像垃圾回收。

关联影响：磁盘满往往是导致 Node NotReady 的深层原因之一。

03 网络与 Service 类故障

10） Service 访问间歇性超时

常见原因：

• kube-proxy 规则异常：iptables/IPVS 规则未正确同步。
• Pod 就绪状态抖动：Endpoint 列表因 Pod Readiness 变化而频繁更新。
• Conntrack 表满：节点连接跟踪表耗尽，影响新建连接。

排查思路：这类网络/系统层面问题，必须结合具体节点的网络状态和内核参数进行分析。

11） Pod 之间网络不通

可能原因：

• CNI 插件异常：网络插件（如 Calico, Flannel）的 DaemonSet 或配置有问题。
• NetworkPolicy 拦截：存在网络策略（NetworkPolicy）禁止了 Pod 间的流量。
• 底层网络问题：MTU 不匹配、VXLAN/IPIP 隧道故障等。

优先检查项：确认是否被预期的网络策略（NetworkPolicy）所阻挡。

12） NodePort 可访问，但 ClusterIP 无法访问

多见于：

• kube-proxy 进程故障：负责 Service 虚拟IP转发的组件异常。
• iptables/IPVS 规则损坏：规则被意外清理或与其他软件冲突。

临时解决：有时重启节点上的 kube-proxy Pod 即可恢复。

13） Ingress 访问异常

常见问题：

• 后端 Service 配置错误：Service 端口号、名称写错。
• Ingress Controller 异常：Nginx Ingress、Traefik 等控制器 Pod 有问题。
• 证书问题：TLS 证书过期或格式错误。

排查步骤：首先检查 Ingress Controller 的日志输出。

04 发布、升级与控制器类故障

14） Deployment 滚动更新卡住

原因：

• 新 Pod 就绪失败：新版本 Pod 的 Readiness 探针始终无法通过。
• 更新策略过保守：maxUnavailable 设置为 0，且新 Pod 无法就绪，导致旧 Pod 无法被替换。

机制理解：Deployment 会确保在旧 Pod 完全停止前，新 Pod 必须就绪，否则会暂停滚动。

15） 升级后业务异常，但 Pod 状态正常

典型原因：

• 配置变更引发问题：新版本镜像依赖的 ConfigMap/Secret 内容有误。
• 依赖服务不兼容：新版本应用与下游的数据库、API 接口等存在版本不匹配。

重要提醒：Kubernetes 只保证 Pod “存活”，不保证业务逻辑 “正确”。

16） 实际 Pod 副本数与预期不符

可能原因：

• HPA 正在工作：Horizontal Pod Autoscaler 根据指标动态调整了副本数。
• 手动干预遗留：有人直接修改了底层的 ReplicaSet 对象。
• 多控制器冲突：多个控制器（如 Deployment 和 StatefulSet）管理了同一组 Pod 标签。

黄金法则：永远以 Deployment（或 StatefulSet）声明的 replicas 数为最终期望状态。

05 权限、安全与配置类故障

17） Pod 内应用无法访问 Kubernetes API

原因：

• ServiceAccount 权限不足：关联的 RBAC Role 或 ClusterRole 未授予相应权限。
• Token 未挂载：Pod 未使用默认或指定的 ServiceAccount。
• RBAC 拒绝访问：显式配置的规则拒绝了该请求。

关键线索：查看错误信息中是否包含 Forbidden。

18） 更新了 ConfigMap/Secret，但 Pod 内未生效

常见于：

• 未重启 Pod：以环境变量（env）方式注入的配置，更新后需重启 Pod。
• 使用方式限制：通过 volume 挂载的配置，虽然会更新，但部分应用可能需要发送信号或热重载才能读取新配置。

核心概念：配置更新 ≠ 应用热更新，需根据注入方式决定后续操作。

19） Job / CronJob 未按预期执行

原因：

• 并发策略限制：.spec.concurrencyPolicy 设置为 Forbid 或 Replace，且已有 Job 在运行。
• 历史 Job 未清理：.spec.failedJobsHistoryLimit / .spec.successfulJobsHistoryLimit 设置过小，导致资源被占满。
• 节点时间不同步：CronJob 的调度基于控制平面节点时间。

排查对象：关注 Job 对象本身的状态，而非其创建出的 Pod。

20） 集群“一切正常”，但业务不可用

最危险的一类问题：

• 监控指标缺失：缺乏针对业务逻辑（如订单成功率、接口响应时间）的有效监控。
• 没有定义 SLO/SLI：未建立清晰的服务水平目标与指标。
• 过度关注基础设施：只检查了 Pod、Node 状态，未验证核心业务链路。

根本认知：Kubernetes 集群健康不等同于业务应用健康。完善的运维/DevOps体系需要建立从基础设施到业务层的全栈可观测性。

总结

Kubernetes 生产环境中的事故，绝大多数源于资源规划、配置管理、网络策略以及对系统机制的认知偏差。熟练掌握以上 20 类常见故障的排查思路，能帮助你有效应对大部分线上挑战，提升系统稳定性。