Pod 卡在 Pending 主因是 master 节点默认带污点且 Pod 未容忍，或 resources.requests 超出节点 Allocatable。优先查看 kubectl describe pod 的 Events 末尾错误，再检查节点污点、unschedulable 状态及 Allocatable 资源。
刚装完 Kubernetes 集群，Pod 一直卡在 Pending 状态？不是配置漏了，就是默认行为挡住了——单机环境尤其常见，90% 的情况是 master 节点带污点、没开调度，或者资源请求写太高压根没地方塞。
为什么新集群的 Pod 总是 Pending？看 describe 输出里的 Events 就够了
kubectl describe pod <pod-name> 输出末尾的 Events 是唯一可信线索。别猜，直接看最后一行错误。常见组合有三类：
-
0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate→ master 节点默认加了node-role.kubernetes.io/control-plane:NoSchedule污点，Pod 不容忍就进不去 -
0/1 nodes are available: 1 Insufficient cpu→ 即使只有一台节点，requests.cpu写成"2"（2 核），而节点 Allocatable 只有"1150m"，也直接拒掉 -
0/1 nodes are available: 1 node(s) had untolerated taint {kubernetes.io/os:linux}→ 某些精简版安装（如 k3s）会加 OS 污点，但 Pod 没配对应tolerations
快速验证节点是否真能调度：检查 taint 和 unschedulable 状态
新集群最容易被忽略的是节点“逻辑不可用”——它 Ready，但被人为锁死。两个命令必须连着跑：
-
kubectl get node -o jsonpath='{.items[*].spec.taints}'→ 看有没有control-plane或master类污点 -
kubectl get node -o jsonpath='{.items[*].spec.unschedulable}'→ 返回true表示该节点被kubectl cordon过，手动关掉了调度入口
如果两者都干净，再查 kubectl describe node 里的 Allocatable，注意不是 Capacity —— swap 关闭、kube-reserved 资源都会吃掉一部分。
单机环境最省事的修复方式：给 master 加容忍或清污点
开发/测试集群没必要分 master/work 节点。直接让 Pod 能上 control-plane 节点，比改 YAML 更快：
- 清污点（临时调试用）：
kubectl taint nodes --all node-role.kubernetes.io/control-plane:NoSchedule-（注意结尾的-是删除操作） - 或加容忍（推荐，更可控）：在 Pod spec 里加这段，不改集群全局策略：
tolerations:<br>- key: "node-role.kubernetes.io/control-plane"<br> operator: "Exists"<br> effect: "NoSchedule"
- 别碰
--max-pods配置：那是 kubelet 启动参数，改了要重启服务，且对调度失败无直接帮助
资源请求写太高？先用最小可行值跑通再调优
新手常把 resources.requests 设成生产值，结果本地单节点根本扛不住。真实可用资源远低于预期：
-
kubectl top node显示的是当前使用量，不是上限；kubectl describe node里的Allocatable才是调度器认的硬门槛 - 起步建议设成
cpu: "100m"、memory: "128Mi"，确认 Pod 能起来后再逐步加 - 如果 Pod 仍 Pending 且
describe提示Insufficient memory，检查是否启用了systemdcgroup v2 + kubelet 未适配，这会导致 Allocatable 计算异常
真正卡住的点往往不在 YAML 多复杂，而在你没意识到 control-plane 节点默认拒绝调度，也没去看 Allocatable 而不是 Capacity。这两处扫一遍，80% 的新集群 Pending 问题当场解决。
