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 ，查看 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 没有对应容忍，导致被直接排除。

jm-jsjkxyjs02-zlm-405

使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。

下载

• 查节点污点：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.nodeSelector：kubectl 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 权限不足），尤其在自建集群或网络受限环境