Kubernetes Pod 一直 Pending？一次 CCE 集群排障的完整思路

在使用华为云 CCE（Cloud Container Engine）或自建 Kubernetes 集群时，Pod 卡在 Pending 状态是最常见的故障之一。本文结合一次实际排障经历，梳理一套系统化的排查思路。

一、第一步永远是 describe

遇到 Pending，先执行：

kubectl describe pod <pod-name> -n <namespace>

重点看底部 Events。90% 的 Pending 原因都会在这里直接给出，常见信息包括：

• Insufficient cpu/memory：节点资源不足

• node(s) had untolerated taint：节点污点导致无法调度

• 0/N nodes are available：节点选择器（nodeSelector/affinity）匹配不到节点

• pod exceeds max pids limit：PID 超限

二、资源不足：不是“加节点”这么简单

如果是资源不足，先看是不是 requests 设置过大。很多同事习惯把 requests 写成 limit，导致调度器按最大用量预留资源，实际利用率却很低。建议：

• requests 按真实日常用量设置，limit 才是峰值

• 用 kubectl top nodes 和 kubectl describe node 观察 Allocatable 与 Allocated 的差值

• 集群层面可开启节点自动扩缩容（CCE 的弹性伸缩能力），但要把扩容冷却时间配置合理，避免抖动

三、污点与亲和性：调度约束要成对出现

给节点打污点做隔离后，忘记给对应工作负载加 toleration，是新手高发问题。排查口诀：污点（taint）与容忍（toleration）一一对应，nodeSelector 的 label 必须真实存在于目标节点上（用 kubectl get node<name> --show-labels 核对）。

四、PVC 未绑定也会导致 Pending

使用 StatefulSet 或挂载云硬盘（EVS）的 Pod，如果 PVC 处于 Pending，Pod 同样无法调度。检查：

kubectl get pvc -n <namespace>

常见原因：StorageClass 名称写错、区域可用区与节点不一致（云硬盘不能跨 AZ 挂载）。