K8s调度抢占容易被误解为“优先级高就一定能调度成功”。实际调度中，高优先级 Pod 仍要满足资源请求、节点选择、亲和 / 反亲和、污点容忍和拓扑分布等约束；抢占只能尝试腾出资源，不能绕过这些硬性条件。
如果一个 Pod 长时间 Pending，排查时不要只看 PriorityClass，要把它放回调度链路里判断：先过滤不可用节点，再评分排序，必要时尝试抢占低优先级 Pod。
图1：K8s调度从过滤、评分到抢占候选节点选择的排查决策树
K8s调度抢占发生在调度失败之后
Kubernetes 官方文档说明，Pod priority 与 preemption 用于让更重要的 Pod 在资源紧张时获得调度机会；当一个 Pod 无法被调度时，调度器可能尝试抢占较低优先级 Pod 来为它腾出空间<sup>[1]</sup>。
这个顺序很关键：抢占不是调度前的默认动作，而是在常规调度无法找到合适节点后触发的补救路径。因此，如果所有节点都因为亲和性不满足、污点无法容忍或拓扑约束冲突而被过滤，抢占也可能无济于事。
排查时先看三类信号：
- 事件原因：`FailedScheduling` 里是否提示资源不足、亲和不匹配、污点不可容忍或拓扑分布冲突。
- 优先级对象：Pod 是否绑定了正确的 `priorityClassName`，PriorityClass 值是否符合预期。
- 约束组合：node affinity、pod anti-affinity、taints/tolerations、topologySpreadConstraints 是否同时收紧了候选节点。
优先级只决定谁更重要，不保证一定成功
PriorityClass 通过数值表达 Pod 优先级，数值越高，优先级越高<sup>[1]</sup>。但这只影响排序和抢占候选判断，不表示调度器可以忽略其他约束。
| 配置对象 | 作用 | 对抢占的影响 | 常见误区 |
|---|---|---|---|
| PriorityClass | 定义 Pod 优先级值 | 决定是否可抢占低优先级 Pod | 以为优先级高就能绕过亲和约束 |
| resource requests | 声明调度所需 CPU / 内存等资源 | 决定腾出多少资源才够调度 | requests 写得过大导致无节点满足 |
| node affinity | 约束可调度节点集合 | 缩小抢占候选节点 | 标签写错后所有节点被过滤 |
| pod anti-affinity | 避免与指定 Pod 同域放置 | 可能阻止抢占后的放置 | 反亲和范围过大导致无位置 |
| tolerations | 允许调度到带污点节点 | 不容忍则节点不可选 | 只看资源，不看节点污点 |
| topologySpreadConstraints | 控制跨拓扑域分布 | 影响最终分布与可调度性 | `maxSkew` 设置过紧 |
抢占不会修复配置矛盾
如果 Pod 同时要求只调度到 `zone-a`，又要求与已有副本跨三个 zone 均匀分布，配置本身就可能矛盾。抢占低优先级 Pod 只能释放资源，不能改变标签、拓扑域或亲和规则。
站内已有“Kubernetes调度器工作原理是什么”和“Kubernetes常见故障排查指南”等基础内容，发布前可校验正式 URL 后补充为延伸阅读，避免本文重复基础调度流程。
亲和、污点和拓扑约束会共同改变候选节点
Kubernetes 的 node affinity、pod affinity / anti-affinity 用于表达 Pod 与节点、Pod 与 Pod 之间的放置关系；污点和容忍用于让节点排斥不匹配的 Pod<sup>[2]</sup>。这些机制与优先级叠加后，会显著影响抢占结果。
图2：PriorityClass、亲和性、污点容忍和拓扑分布对
可以按过滤顺序理解：
- 节点是否 Ready，是否有足够资源请求空间。
- Pod 是否匹配节点标签、节点选择器和 node affinity。
- Pod 是否容忍节点上的 taints。
- Pod 与已有 Pod 的亲和 / 反亲和是否满足。
- 拓扑分布约束是否允许放到该拓扑域。
- 若无可用节点，再判断是否存在可抢占的低优先级 Pod。
拓扑约束要结合实际副本数
`topologySpreadConstraints` 可以控制 Pod 跨节点、可用区或其他拓扑域分布，减少集中放置风险<sup>[3]</sup>。但当副本数、可用拓扑域、标签选择器和 `maxSkew` 设置不匹配时，它也会让 Pod 继续 Pending。
例如只有两个可用区，却要求三个副本在三个 zone 中均匀分布，或者 selector 没有匹配到预期工作负载，都可能让调度结果与预期不一致。
排查 Pending Pod 要从事件回到配置
排查 K8s调度问题时，最直接的入口是查看 Pod 事件和调度提示。事件通常会指出过滤节点的原因，例如资源不足、污点不容忍或亲和不匹配；下面的命令用于把事件、PriorityClass 和 Pod 规格放在同一轮检查中<sup>[1]</sup><sup>[2]</sup>。
kubectl describe pod <pod-name> -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestamp
kubectl get priorityclass
kubectl get pod <pod-name> -n <namespace> -o yaml重点核对字段包括：
- `spec.priorityClassName` 是否引用了正确 PriorityClass。
- `spec.affinity` 是否存在过窄的 node / pod affinity。
- `spec.tolerations` 是否覆盖目标节点 taints。
- `spec.topologySpreadConstraints` 的 `topologyKey`、`labelSelector`、`maxSkew` 是否合理。
- `resources.requests` 是否明显高于节点可用容量。
这些字段均属于 Kubernetes Pod 规格和调度相关 API 行为，排查时应以 Kubernetes API reference 与官方调度文档为准<sup>[2]</sup>。
生产配置要避免三类误配
调度抢占在生产中常见的误配，不是单个字段写错，而是多个约束叠加后互相抵消。
图3：K8s调度抢占上线前需要核对的决策路径、优先级约束和事件
| 误配类型 | 表现 | 修正思路 |
|---|---|---|
| 优先级滥用 | 大量业务 Pod 都使用高优先级 | 只给关键系统或核心链路设置高优先级 |
| 约束过窄 | 有资源但仍 Pending | 放宽 affinity、反亲和或 topology spread |
| 资源请求失真 | 抢占后仍放不下 | 重新评估 requests，与实际容量和配额对齐 |
高优先级也需要准入规则
高优先级 Pod 可能抢占低优先级工作负载，因此需要配合命名空间、配额、准入策略和变更审批使用。否则一旦普通业务都能声明高 PriorityClass，抢占机制就会失去保护关键业务的意义。
上线前至少检查：
- PriorityClass 是否分层清晰，命名是否能表达业务重要性。
- 哪些团队可以使用高优先级类，是否有准入控制。
- 抢占低优先级 Pod 后，低优先级业务是否有恢复或重调度策略。
- 拓扑域标签是否稳定，节点池扩缩容时是否同步维护。
- 调度失败告警是否能展示事件原因，而不是只提示 Pending。
小结
K8s调度抢占是调度失败后的补救机制，不是绕过资源、亲和、污点和拓扑约束的特权通道。排查时应从 Pod 事件开始，逐项核对 PriorityClass、requests、affinity、tolerations 和 topologySpreadConstraints。生产环境中，抢占机制更适合保护关键工作负载，而不是作为普遍提高调度成功率的捷径。
参考资料
- [1] Kubernetes Pod Priority and Preemption – 官方文档
- [2] Kubernetes Assigning Pods to Nodes – 官方文档
- [3] Kubernetes Pod Topology Spread Constraints – 官方文档
常见问题
K8s调度抢占一定会删除低优先级 Pod 吗？
不一定。只有当调度器判断抢占低优先级 Pod 能让高优先级 Pod 满足调度条件时，才可能选择抢占。若问题来自亲和、污点、拓扑约束或节点标签不匹配，抢占也无法解决。
PriorityClass 数值应该怎么设置？
建议按业务重要性分层，而不是给所有核心业务都设置极高值。系统组件、关键入口、普通业务、批处理任务可以使用不同层级，并配合准入规则限制谁能使用高优先级类。
Pod 一直 Pending，应该先查优先级还是资源？
先看 `kubectl describe pod` 的事件原因。事件通常能指出资源不足、亲和不匹配、污点不可容忍或拓扑约束冲突。优先级只是其中一个维度，单独查看 PriorityClass 很容易漏掉真正的过滤原因。
