在 Kubernetes 集群的调度流程中，除了依据计算资源和存储需求进行匹配外，还需要考量不同业务负载之间的关键性差异。为了量化这种差异，系统引入了一个整型参数来标识 Pod 的重要等级，这被称为 Pod 优先级。

优先级数值范围与含义

该参数的取值区间设定为 0 至 10 亿。通常情况下，数值越大代表负载越关键。默认情况下，未显式配置的 Pod 其优先级值为 0。此外，超过 10 亿的高位数值通常保留给系统内部的核心组件使用，以确保底层服务的稳定性不受用户业务影响。当集群节点资源趋于饱和时，调度器会依据此数值决定资源的归属权。

优先级类资源对象

为了避免在每个 Pod 中都硬编码具体的数值，Kubernetes 提供了名为 PriorityClass 的资源类型。这是一个命名空间无关的全局对象，允许管理员预先定义一组优先级配置。用户在编写 Pod 清单时，只需引用对应的类名称（通过 priorityClassName 字段），即可自动应用预设的数值。

抢占行为控制

当高优先级的任务等待调度但当前没有足够空闲节点时，系统需要决定是否牺牲低优先级任务。这一行为由 preemptionPolicy 字段控制：

• PreemptLowerPriority：允许调度器终止并释放当前运行中、优先级低于新任务的 Pod，从而腾出资源满足高优请求。
• Never：禁止驱逐任何现有 Pod。即便资源不足，该 Pod 也只能保持待调度状态（Pending），直到有节点释放出足够的容量。

值得注意的是，只有当目标 Pods 之间存在明显的优先级差值时，上述抢占逻辑才会触发。同级优先级的任务之间互不抢占。

资源定义示例

以下代码片段展示了如何创建一个名为 critical-systems 的优先级类，并在 Pod 规范中应用它。请注意 YAML 缩进的规范性。

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: critical-systems
value: 500000
globalDefault: false
description: "核心系统组件专用调度等级"

随后，在部署具体应用容器时，可以关联上述定义的类名，并开启低优抢占模式：

apiVersion: v1
kind: Pod
metadata:
  name: core-api-gateway
spec:
  containers:
    - name: http-proxy
      image: haproxy:latest
      ports:
        - containerPort: 80
  priorityClassName: critical-systems
  preemptionPolicy: PreemptLowerPriority

在这个配置中，core-api-gateway 被赋予了 500,000 的权重值。如果集群发生资源争用，它具备驱逐所有优先级小于 500,000 的容器的权限。

关于功能启用情况，自 Kubernetes 1.11 版本起，该特性已成为标准配置且默认开启。对于维护旧版本集群的场景（如 1.10 及更早版本），运维人员需要在启动 kube-scheduler 时添加特定的特征门控参数 --feature-gates=PodPriority=true 才能激活相关能力。