在多租户或资源紧张的集群中，一个再正常不过的场景是：
普通业务Pod还在正常跑，核心交易服务却因为资源不足而调度失败。
这不是 Bug，也不是 Kubernetes 的错，而是你没有告诉集群：“谁更重要”。
Kubernetes 提供了 Pod Priority（优先级）与 Preemption（抢占）机制，用于确保关键服务拥有“生存优先权”。
本文将带你深入了解：
- Pod Priority 的配置与等级划分；
- 抢占机制如何工作，是否会“杀死”其他Pod；
- 实战场景中如何防止误抢、如何优雅恢复；
- 与亲和性、污点、HPA 等机制的协同使用技巧。
一、什么是 Pod Priority？
Pod Priority 是 Kubernetes 中的调度机制，用于定义 Pod 的重要级别，优先级高的 Pod 将在资源竞争中胜出。
优先级定义在一个对象上：
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: high-priority
value: 100000
globalDefault: false
description: "用于核心业务服务的高优先级"
然后在 Pod 中引用：
spec:
priorityClassName: high-priority
内置与自定义优先级值
- Kubernetes 本身没有强制内置的数值划分，但推荐值范围：
- 普通服务：value: 1000
- 管理组件：value: 10000
- 核心业务服务：value: 100000
官方文档推荐优先级值在 [-1000000000, 1000000000] 之间设置。
二、抢占机制：当资源不足时的生存战争
当资源不足时，调度器发现一个高优 Pod 无法被调度，就会触发 抢占（Preemption） 流程：
- 计算满足其需求的节点；
- 判断该节点上是否可以“驱逐”低优 Pod 以空出资源；
- 选择驱逐的目标 Pod（不会立即删除，而是先发送终止信号） ；
- 高优 Pod 调度成功。
抢占不会随意生效
Kubernetes 会尽量避免抢占，触发时也优先选择“代价最小”的方式：
- 会优先踢掉不带 PodDisruptionBudget 的 Pod；
- 会避免破坏 Deployment/StatefulSet 的最小副本数。
三、实战：如何正确使用 Pod Priority？
✅ 使用场景
| 场景 | 推荐优先级设置 |
|---|---|
| 核心业务Pod（交易、支付等） | high-priority |
| 管理面组件（如Prometheus） | medium-priority |
| 离线批处理任务 | low-priority |
⚠️ 避免陷阱
- 抢占风险：不要设置太多高优 Pod，否则可能出现“抢占风暴”；
- 不适用于DaemonSet：优先级不会对 DaemonSet 起作用；
- 配合 PodDisruptionBudget 使用：保护被抢占 Pod，限制抢占频率。
四、结合其他调度机制的使用建议
| 机制 | 说明 |
|---|---|
| 与 Taints 搭配 | 高优 Pod 配容忍，可调度到特定节点 |
| 与 HPA 搭配 | 高优 Pod 若需要扩容，优先触发抢占 |
| 与 Anti-Affinity 搭配 | 控制高优 Pod 不与其他同类型业务相邻 |
五、未来趋势与建议
- Kubernetes 社区对抢占策略在不断优化（参考：K8s v1.26 的抢占稳定性改进提案）；
- 可以结合 ResourceQuota + LimitRange，从资源限制层面强化调度策略；
- 如需更精细的抢占控制，可配合调度器插件或自定义调度器实现抢占可控性（如仅抢占某命名空间内 Pod）。
总结：保障核心Pod，“讲优先级”的时代已经到来
Pod 优先级与抢占机制，是 Kubernetes 为多租户环境设计的一种 调度博弈解决方案。
合理使用 Priority，可以让核心业务“不饿死”，让辅助业务“知进退”。
在生产中掌握这项机制，将极大提升集群的弹性、稳定性与服务等级保障能力。
