优先级决定谁先被满足
优先级类给工作负载一个数值：数值越大越优先。调度时队列按优先级排序，高优先级副本先获得资源；集群资源紧张时，高优先级工作负载可以抢占低优先级工作负载的配额，被抢占的副本进入等待状态等待重新调度。这是一把双刃剑，用错会造成在线服务被离线任务挤掉。
基本信息
| 所属接口组 | scheduling.k8s.io/v1 |
|---|---|
| 数值含义 | 数值越大优先级越高 |
| 全局默认 | 全集群只应有一个默认优先级类 |
| 系统内置 | 控制面与节点关键组件使用更高数值 |
| 抢占后果 | 被抢占的副本被终止并重新排队 |
典型使用场景
- 为在线核心服务设置高优先级，保证资源紧张时优先获得配额
- 为离线批处理设置低优先级，使用集群空闲容量
- 为监控与日志组件设置中间优先级，避免被完全挤掉
- 多团队共用集群时用优先级表达业务重要性
- 排查副本被突然终止：确认是否发生了抢占
声明与使用
声明与使用
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: business-critical
value: 1000000 # 数值越大越优先
globalDefault: false # 不要随意设为全局默认
description: core online services
---
spec:
template:
spec:
priorityClassName: business-critical查看
查看
kubectl get priorityclass # 现有优先级类与数值
kubectl get pod web-x -o jsonpath='{.spec.priorityClassName} {.spec.priority}'
kubectl get events -A --field-selector reason=Preempted | tail -10 # 抢占记录
kubectl describe pod batch-xxx | grep -i -A3 'Preempt'分层建议
| 层级 | 典型对象 | 取值思路 |
|---|---|---|
| 系统关键 | 控制面与节点组件 | 使用内置最高层，不随意改动 |
| 在线核心 | 对外业务服务 | 高于批处理，低于系统组件 |
| 常规业务 | 内部服务与中间件 | 中间层，与在线核心拉开差距 |
| 离线任务 | 批处理与数据任务 | 最低层，利用空闲容量 |
优先级越高越容易被满足，但抢占会终止正在运行的副本。为在线服务配置高优先级时，应同时确认副本数与中断预算能承受被抢占带来的波动。
把批处理任务的优先级设得高于在线服务，资源紧张时被挤掉的会是在线副本，故障表现与业务高峰重合，排查时很容易误判成流量问题。