nodes-unavailable

调度失败（0/N nodes are available）的定位与修复

现象

Pod 一直 Pending，kubectl describe pod 的 Events 出现类似 0/5 nodes are available: 1 node(s) had untolerated taint, 3 Insufficient cpu, 1 node(s) didn't match Pod's node affinity/selector 的信息。这表示调度器逐个节点执行过滤插件后，没有任何节点通过全部条件。

事件里的数字不是“节点总数减可用数”，而是一个节点可能同时不满足多个条件，所以各项计数之和可以大于 N。后面的 preemption: 0/5 nodes are available 是抢占尝试的独立结果，表示即使驱逐低优先级 Pod 也找不到可行节点。若事件出现 pod has unbound immediate PersistentVolumeClaims，说明存储绑定也参与了过滤，不能只按资源不足处理。

快速定位

先读完整事件，不要只看第一行：

kubectl describe pod <pod> -n <ns> | sed -n '/Events/,$p'
kubectl get events -n <ns> --sort-by=.lastTimestamp | tail -30
kubectl get pod <pod> -n <ns> -o yaml

查看节点状态、污点和可分配资源：

kubectl get nodes -o wide
kubectl describe node <node> | sed -n '/Taints/,/Events/p'
kubectl describe node <node> | sed -n '/Allocated resources/,/Events/p'
kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

检查存储和调度器：

kubectl get pvc -n <ns>
kubectl get pv
kubectl -n kube-system logs <scheduler-pod> --tail=100

再对照 Pod 的调度约束：

kubectl get pod <pod> -n <ns> \
  -o jsonpath='{.spec.nodeSelector}{"\n"}{.spec.affinity}{"\n"}{.spec.tolerations}{"\n"}{.spec.topologySpreadConstraints}{"\n"}'
kubectl get pod <pod> -n <ns> \
  -o jsonpath='{range .status.conditions[*]}{.type}{"="}{.status}{" "}{.reason}{"\n"}{end}'

PodScheduled=False 的 reason 和 message 会直接给出调度失败摘要，适合快速确认是否只有存储或亲和性一个原因。

Insufficient cpu 看的是 requests 与节点 allocatable 的差值，不是节点当前的实际使用率；Allocated resources 展示的也是已分配 requests。排查时不要被监控里的低 CPU 使用率误导。事件中的 reason 通常来自调度过滤插件，但同一插件可能产生多个 reason（如 Insufficient cpu 与 Insufficient memory），逐项核对比凭经验猜测更快。

常见根因

1. CPU、内存或临时存储 requests 太高，节点 allocatable 扣掉系统保留和已有 Pod 后放不下。
2. 节点带有 NoSchedule 污点，例如控制面专用、GPU 专用或维护中的节点，Pod 没有对应 toleration。
3. nodeSelector、nodeAffinity 或 requiredDuringScheduling 规则与节点标签不匹配。
4. Pod 反亲和、Pod 亲和或 topology spread 约束无法满足，例如要求每个可用区都有副本但节点标签不完整。
5. PVC 未绑定、PV 的 nodeAffinity 与候选节点冲突，或卷挂载数量达到上限。
6. hostPort 已被占用，或节点 Pod 数量达到 maxPods 上限。
7. 节点被 cordon、处于 NotReady，或调度器本身未正常运行。
8. 集群总空闲资源足够，但碎片化严重，没有任何单节点能容纳整个 Pod。
9. 低优先级 Pod 无法抢占：没有可驱逐的受害者，或驱逐后仍不满足资源与约束。
10. LimitRange 为容器注入了默认 requests，实际值比清单里写的大。
11. 自定义调度器、调度器 profile 或扩展插件配置错误，过滤结果异常。
12. Pod 请求 GPU 等扩展资源，但节点没有对应资源、device plugin 未上报或资源名写错。

修复

• 按事件里出现次数最多的过滤原因处理，不要同时改多项配置。
• 多个约束叠加时，先临时放宽一个条件做验证，确认真正阻塞项后再恢复，避免把问题归因错。
• 资源不足时先核对 requests 与 allocatable，右调 requests、清理闲置工作负载或扩容节点；集群自动伸缩器只对“扩容后能调度”的 Pod 有效。
• 扩容后仍无法调度时，检查新节点组的标签、污点、可用区和不支持实例类型；自动伸缩器不会为本地卷、强亲和性或缺失标签凭空创建合适节点。
• 污点场景确认是否应该容忍；控制面和专用节点不要为了临时调度随意去掉污点。
• 标签和亲和性错误时修正节点标签，或把硬性约束改为软性偏好；检查 topologyKey 是否真实存在。
• 存储问题先让 PVC 绑定，检查 PV 的节点亲和性与可用区；本地卷不能跨节点漂移。
• hostPort 冲突改用 Service 暴露；maxPods 不足时评估提高上限或增加节点。
• cordon 节点在维护结束后 uncordon；NotReady 节点先按节点故障处理。
• 资源碎片化时调整 Pod 规格或增加节点，也可用 descheduler 做后续再平衡，但它不是首选修复手段。
• 需要抢占时设置合理的 PriorityClass，并确认确实存在可驱逐的低优先级 Pod；抢占不保证成功。
• 检查调度器 Pod 是否健康、是否持有 leader 租约，以及自定义 profile 的插件顺序和参数。

相关命令

• kubectl — 事件、节点和 Pod 规格
• kube-scheduler — 调度器配置与日志
• taints-tolerations — 污点与容忍
• affinity — 节点亲和与 Pod 亲和
• topology-spread — 拓扑分布约束
• pvc / pv — 存储绑定与节点亲和
• node — 节点状态与容量
• priority-class — 抢占与优先级
• cluster-autoscaler — 节点扩容
• descheduler — 后续再平衡

参考链接

• Kubernetes 调度器
• 将 Pod 分配到节点
• 污点与容忍
• 容器资源管理
• 拓扑分布约束

读完自测

合上页面，先回答，再展开对照。

1. 0/5 nodes are available 后面的各项计数应该怎么读？
2. 节点监控显示 CPU 很空闲，为什么调度器仍报 Insufficient cpu？
3. 有状态 Pod 因 PV 节点亲和性无法调度，应该怎么处理？