抢占是怎么发生的
当高优先级 Pod 调度失败时，调度器会尝试在同一节点上驱逐优先级更低的 Pod 腾出位置，这就是抢占。被抢占的 Pod 会收到事件，随后重新进入调度流程。如果高优先级任务体量大、运行时间长，低优先级业务就可能被反复打断，表现为难以定位的偶发失败。需要特别注意的是：抢占不参考可用性预算，被抢占方的可用性要由自身机制负责。
基本信息
| 适用平台 | 配置了优先级类（PriorityClass）的集群 |
|---|---|
| 关键对象 | PriorityClass 与 Pod 的 priorityClassName 字段 |
| 触发条件 | 高优先级 Pod 找不到可容纳它的节点 |
| 事件原因 | Preempted，可在事件中直接检索 |
| 相关机制 | 与可用性预算是两套独立机制，抢占不受预算约束 |
典型使用场景
- 保障核心服务：给关键业务较高优先级，资源紧张时优先保住
- 离线任务让路：批处理使用低优先级，空闲时才跑满资源
- 紧急运维任务：临时高优先级执行排障或恢复操作
- 多租户集群：用优先级区分业务等级，约束资源竞争行为
- 成本优化：把可中断任务集中到低优先级层级，提高资源利用率
优先级配置与观察
优先级配置与观察
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: high-priority
value: 1000000 # 数值越大优先级越高
preemptionPolicy: PreemptLowerPriority # 也可设为 Never 只排序不抢占
globalDefault: false定位抢占事件
定位抢占事件
kubectl get events -A --field-selector reason=Preempted | tail
kubectl describe pod low-priority-x | grep -i preempt
kubectl get pods -A -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,PRIORITY:.spec.priority' | sort -k3 -n | tail
kubectl get priorityclass现象与处理方向
| 现象 | 含义 | 处理方向 |
|---|---|---|
| 出现 Preempted 事件 | 低优先级 Pod 被挤走 | 评估优先级划分是否合理 |
| 某业务反复重启 | 被高优先级任务持续抢占 | 拆分节点池或调整优先级 |
| 高优先级 Pod 长期 Pending | 集群确实没有容量 | 扩容或错峰执行 |
| 抢占后未回填 | 等待重新调度中 | 观察是否再次被抢，判断是否形成饥饿 |
抢占不参考可用性预算：大用量、长时间运行的高优先级任务可以反复打断低优先级在线服务，重要程度高的业务应放在独立节点池里隔离这类影响。
把抢占策略设为不抢占（只排序）可以让高优先级任务排队等待，而不是挤走别人；是否启用抢占，取决于业务对「排队等」与「打断别人」的取舍。