问题根源是缺乏拓扑分布约束，导致Pod集中调度至node-03；需补全topologySpreadConstraints，同时排查节点标签缺失、污点未容忍、亲和/反亲和配置不当及资源请求未设置等问题。
线上服务的3个副本全被调度到node-03，该节点CPU使用率达80%，其余节点空闲超60%，请求延迟飙升——这不是偶发故障，而是调度策略缺失的必然结果。
确认Pod是否真被集中调度
执行kubectl get pods -o wide --all-namespaces | awk '{print $1, $7}' | sort，输出中若出现同一节点名高频重复（如node-03连续出现5次以上），即确认分布异常。
用kubectl top nodes交叉验证：空闲节点内存/CPU使用率低于30%但无Pod运行，而热点节点负载超75%且Pod密集，说明不是资源耗尽导致的被动堆积，而是主动调度倾斜。
检查节点标签与污点配置
方法一：查节点是否有隐性排斥
运行kubectl get nodes -o wide --show-labels，重点核对所有节点是否都具备Pod期望的label（如zone:cn-beijing-a）。若node-01/node-02缺少该标签，而Pod配置了nodeSelector: {zone: cn-beijing-a}，则它们天然不可选。
方法二：揪出未被容忍的污点
执行kubectl describe nodes | grep -A 5 "Taints:"，若发现空闲节点存在key=value:NoSchedule，而Pod YAML中未声明对应tolerations，调度器会直接过滤这些节点——【这是最常被忽略的硬性拦截条件】。
诊断Pod自身调度约束
第一步：提取Pod的完整调度配置
执行kubectl get pod ，重点关注是否存在podAffinity规则。若有类似topologyKey: topology.kubernetes.io/zone且weight: 100的强亲和配置，会强制新Pod向已有Pod所在区域聚集。
第二步：验证反亲和是否失效
检查podAntiAffinity是否设置了requiredDuringSchedulingIgnoredDuringExecution——这种硬性要求一旦不满足（例如所有节点都已存在同label Pod），调度器将彻底放弃调度，而非降级为软性打分。此时应改用preferredDuringSchedulingIgnoredDuringExecution并配合理想权重。
第三步：确认资源请求是否缺失
若Pod YAML中resources.requests完全空白，kube-scheduler无法评估节点真实水位，会退化为随机选择或仅依赖节点上报的Allocatable值——这极易导致多个Pod误判同一节点“资源充足”而扎堆。
模拟调度过程定位根因
执行kubectl get pod ，观察返回的错误信息。若出现0/5 nodes are available: 3 node(s) had untolerated taint，说明污点是主因；若显示2 Insufficient cpu，则需检查资源请求设置或节点实际碎片化情况。
这一步操作起来很简单，直接把命令粘贴进终端回车就行。注意必须用--dry-run=server，客户端模式无法触发真实调度器逻辑。
若模拟返回scheduled to node-03且无报错，证明当前所有约束条件在调度器视角下完全合法——问题根源就是缺乏分布控制，需立即补上topologySpreadConstraints。
