pod pending 且事件显示“0/1 nodes available”表明调度失败，主因包括：1. 节点资源不足（requests 超出 allocatable）；2. 污点与容忍不匹配；3. nodeselector 或亲和性配置错误；4. 节点 notready 或被 cordon。
Pod 一直处于 Pending 状态，且事件中显示 0/1 nodes are available，说明 Kubernetes 调度器无法为该 Pod 找到符合条件的节点来运行它。这不是网络或镜像问题，而是调度阶段失败 —— Pod 还没开始拉镜像、也没尝试启动容器。
节点资源不足（最常见）
Kubernetes 调度器会检查节点是否有足够 CPU、内存等资源满足 Pod 的 requests。哪怕节点看起来“空闲”，只要未预留资源低于 Pod 请求值，就会被跳过。
- 运行
kubectl describe node <node-name></node-name>，查看 Allocatable 和 Allocated resources 部分，对比 Pod 的resources.requests - 特别注意：系统组件（kubelet、containerd）、操作系统、kube-reserved / system-reserved 设置都会占用 Allocatable 之外的资源，真正可调度的资源往往比
kubectl get nodes -o wide显示的要少 - 临时验证：把 Pod 的
resources.requests调低（例如 CPU 改成10m，内存64Mi），看是否能调度成功
节点污点（Taint）与容忍（Toleration）不匹配
节点可能带有 NoSchedule 或 NoExecute 污点，而 Pod 没有对应容忍，导致被直接排除。
- 查节点污点：
kubectl describe node | grep Taints - 查 Pod 是否定义了 tolerations：
kubectl get pod <pod-name> -o yaml | yq '.spec.tolerations'</pod-name>（或用kubectl describe pod查 Events 和 Toleration 字段） - 常见场景：master 节点默认带
node-role.kubernetes.io/control-plane:NoSchedule污点；部分集群给 worker 节点加了自定义污点（如dedicated=ai:NoSchedule）
节点选择器（nodeSelector）或亲和性（affinity）配置错误
Pod 显式要求运行在具备某些标签的节点上，但集群中没有节点满足条件。
- 检查 Pod 的
spec.nodeSelector：kubectl get pod <pod-name> -o jsonpath='{.spec.nodeSelector}'</pod-name> - 检查
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 <name> -o jsonpath='{.spec.unschedulable}'</name>，返回true表示被kubectl cordon过 - 确认 kube-scheduler 日志中是否有报错（如连接 apiserver 超时、RBAC 权限不足），尤其在自建集群或网络受限环境
