我不会起名字322· 后端 / 算法 / 数据库 技术栈 力扣 Hot100 Go 项目 Redis MySQL文章目录Pod 一直 Pending调度器 5 类失败原因与 kubectl describe 的正确读法一、第一个要改掉的习惯二、5 类失败原因原因 1资源不足但要看的是 request不是实际用量原因 2亲和性 / nodeSelector 不匹配原因 3污点没有容忍原因 4PVC 没绑定原因 5节点自身状态异常三、kubectl describe 的正确读法四、批量 Pending 时怎么判断范围五、带走物Pod 一直 Pending调度器 5 类失败原因与 kubectl describe 的正确读法一、第一个要改掉的习惯看到 Pod Pending最常见的第一反应是资源不够了扩容。这个判断经常是错的。Pending 的原因至少有六类资源不足只是其中一类。而且更麻烦的是如果只是调度约束不匹配加多少节点都不会让 Pod 起来你会白白扩容一轮、浪费时间和成本。正确的第一步永远是kubectl describe podpod-name-nns看最底下的Events。调度器已经把原因写在里面了绝大多数 Pending 靠这一段就能定性。二、5 类失败原因原因 1资源不足但要看的是 request不是实际用量这是最容易被误读的一类。看这段输出Events: Warning FailedScheduling 0/12 nodes are available: 3 Insufficient cpu, 5 Insufficient memory, 4 node(s) had untolerated taint.关键点调度器看的是request不是actual usage。kubectl describenodenode-1|grep-A20Allocated resources你会看到类似Allocated resources: Resource Requests Limits cpu 3600m (90%) 8000m (200%) memory 6Gi (85%) 12Gi (170%)一个节点 CPU 实际只用了 20%但 request 已经被预留到 90%那么新 Pod 依然调不上去。这是节点看起来很闲但 Pod 就是 Pending的根本原因。另外别忘了 namespace 级的配额kubectl get resourcequota-Akubectl describe resourcequota-nnsResourceQuota 打满时加节点完全没用——配额是 namespace 维度的硬上限。原因 2亲和性 / nodeSelector 不匹配Events: Warning FailedScheduling 0/12 nodes are available: 12 node(s) didnt match Pods node affinity/selector.Pod 里写了nodeSelector:disk:ssd但集群里没有任何节点带diskssd这个标签。或者用了 nodeAffinity / podAntiAffinity规则相互冲突。排查# 看节点有什么标签kubectl get nodes --show-labels|tr,\n|grep-idisk# 看 Pod 的约束kubectl get podpod-oyaml|grep-A10-EnodeSelector|affinity生产集群里这类隐式规则往往很多SSD 节点池、GPU 节点池、可用区约束是最容易被忽略的一类。尤其是podAntiAffinity配了requiredDuringScheduling时副本数超过节点数就永远调不上。原因 3污点没有容忍Events: Warning FailedScheduling 0/12 nodes are available: 12 node(s) had untolerated taint {dedicated: gpu}.节点被打了污点taintPod 没有对应的 tolerationtolerations:-key:dedicatedoperator:Equalvalue:gpueffect:NoSchedule排查kubectl describenodenode-1|grep-itaint常见场景专用节点池GPU、高内存、控制平面节点默认有node-role.kubernetes.io/control-plane:NoSchedule。原因 4PVC 没绑定Stateful 服务 Pending很多时候不是计算资源问题是存储卷没绑上kubectl get pvc-nnskubectl describe pvc>-nns如果 PVC 也是 Pending看它的 EventsEvents: Normal WaitForFirstConsumer waiting for first consumer to be created before binding # 或者是 Warning ProvisioningFailed storageclass.storage.k8s.io fast not found常见原因StorageClass 名字写错、没有默认 StorageClass、CSI 驱动没装、或者用了WaitForFirstConsumer而 Pod 又因为别的原因起不来形成死锁。这类问题千万不要用加计算节点的方式去解决方向完全错了。原因 5节点自身状态异常节点可能处于不健康状态调度器直接跳过它kubectl get nodes kubectl describenodenode-1|grep-A10Conditions要找的关键字MemoryPressure/DiskPressure/PIDPressure节点资源压力kubelet 会自动打上对应污点ReadyFalse节点失联SchedulingDisabled节点被cordon了维护中。# 被 cordon 的节点kubectl get nodes|grepSchedulingDisabled三、kubectl describe的正确读法很多人describe只看最后一行这是不够的。完整的读法是从上到下三段kubectl describe podpod-nns第 1 段顶部状态区Status: Pending Node: none ← 空 还没被调度调度问题 ← 有节点名 已调度卡在镜像拉取/容器创建另一类问题这一行就能把问题分成两大类Node: none是调度器的问题Node:有值是 kubelet 的问题镜像拉取失败、CNI 没准备好等。第 2 段Conditions容器没起来时看这里Conditions: Type Status PodScheduled False ← 明确告诉你没被调度上第 3 段Events最关键调度器每次尝试失败都会在这里写一条带时间戳。如果同一个原因在反复出现说明调度器一直在重试同一件注定失败的事。如果 Events 是空的比如 Pod 创建很久了Events 被驱逐用集群事件补kubectl get events-A--sort-by.lastTimestamp|tail-50四、批量 Pending 时怎么判断范围单个 Pod Pending 是局部问题大量 Pod 因同一个原因 Pending 是平台问题。# 找出所有未调度的 Pod 并聚合原因kubectl get pods-A--field-selectorstatus.phasePending-owide# 按原因聚合看 Events 里的关键句fornsin$(kubectl get ns-oname|cut-d/-f2);dokubectl get events-n$ns--field-selectorreasonFailedScheduling-ojson|jq-r.items[].message|seds/[0-9]\//g|sort|uniq-c|sort-rndone按原因分类统计之后就能判断是某个应用配错了还是某类节点不够了或是存储供应异常。建议平台侧直接做成指标pending_pods_by_reason{reasonunschedulable_by_resource} pending_pods_by_reason{reasonunschedulable_by_affinity} pending_pods_by_reason{reasonpvc_pending} pending_pods_by_reason{reasonquota_exceeded}有了这个视图调度约束过严、节点池不足、存储异常都能在业务报障之前发现。五、带走物一个能直接用的排查顺序1. kubectl describe pod → 看 Node 字段 ├─ Node: none → 调度问题继续第 2 步 └─ Node: 有值 → kubelet 问题镜像/CNI/运行时换排查路线 2. 看 Events 里的 FailedScheduling 原因 ├─ Insufficient cpu/memory → 看 node 的 Allocated requests namespace ResourceQuota ├─ didnt match node selector → 看 Pod 的 nodeSelector/affinity vs 节点 labels ├─ untolerated taint → 看节点 taints vs Pod tolerations └─ (无 Events / PVC 相关) → kubectl get pvc看 StorageClass 3. kubectl describe node → 看 ConditionsPressure / cordon / NotReady 4. 大量 Pod Pending → 按原因聚合判断是应用问题还是平台问题结论一句话Pending 的答案已经写在 Events 里了先 describe 再决定要不要扩容。扩容是手段不是诊断。