Pod 创建后 status 一直是 Pending – 0/1 nodes are available

13次阅读

Pod Pending 且事件显示“0/1 nodes available”表明调度失败,主因包括:1. 节点资源不足(requests 超出 Allocatable);2. 污点与容忍不匹配;3. nodeSelector 或亲和性配置错误;4. 节点 NotReady 或被 cordon。

Pod 创建后 status 一直是 Pending – 0/1 nodes are available

Pod 一直处于 Pending 状态,且事件中显示 0/1 nodes are available,说明 kubernetes 调度器无法为该 Pod 找到符合条件的节点来运行它。这不是网络或镜像问题,而是调度阶段失败 —— Pod 还没开始拉镜像、也没尝试启动容器。

节点资源不足(最常见)

Kubernetes 调度器会检查节点是否有足够 CPU、内存等资源满足 Pod 的 requests。哪怕节点看起来“空闲”,只要未预留资源低于 Pod 请求值,就会被跳过。

  • 运行 kubectl describe node ,查看 AllocatableAllocated resources 部分,对比 Pod 的 resources.requests
  • 特别注意:系统组件(kubelet、containerd)、操作系统、kube-reserved / system-reserved 设置都会占用 Allocatable 之外的资源,真正可调度的资源往往比 kubectl get nodes -o wide 显示的要少
  • 临时验证:把 Pod 的 resources.requests 调低(例如 CPU 改成 10m,内存 64Mi),看是否能调度成功

节点污点(Taint)与容忍(Toleration)不匹配

节点可能带有 NoScheduleNoExecute 污点,而 Pod 没有对应容忍,导致被直接排除。

  • 查节点污点:kubectl describe node | grep Taints
  • 查 Pod 是否定义了 tolerations:kubectl get pod -o yaml | yq '.spec.tolerations'(或用 kubectl describe pod 查 Events 和 Toleration 字段)
  • 常见场景:master 节点默认带 node-role.kubernetes.io/control-plane:NoSchedule 污点;部分集群给 worker 节点加了自定义污点(如 dedicated=ai:NoSchedule

节点选择器(nodeSelector)或亲和性(affinity)配置错误

Pod 显式要求运行在具备某些标签的节点上,但集群中没有节点满足条件。

  • 检查 Pod 的 spec.nodeSelectorkubectl get pod -o jsonpath='{.spec.nodeSelector}'
  • 检查 spec.affinity.nodeAffinity 是否设置了硬性约束(requiredDuringSchedulingIgnoredDuringExecution)且无节点匹配
  • 确认节点实际标签:kubectl get node --show-labels,比对是否漏标、拼写错误(如 role=worker 写成 role=workeer

节点处于 NotReady 状态或不可调度(unschedulable)

虽然 kubectl get nodes 显示 Ready,但可能因其他原因被标记为不可调度,或 kube-scheduler 无法访问该节点。

  • 运行 kubectl get nodes -o wide,确认 STATUS 是 Ready,且 AGE 不异常(如刚加入但未完成初始化)
  • 检查节点是否被手动设置为不可调度:kubectl get node -o jsonpath='{.spec.unschedulable}',返回 true 表示被 kubectl cordon
  • 确认 kube-scheduler 日志中是否有报错(如连接 apiserver 超时、RBAC 权限不足),尤其在自建集群或网络受限环境
text=ZqhQzanResources