Kubernetes Pod优先级与抢占机制详解

1. 为什么需要Pod优先级与抢占机制

在Kubernetes集群中，资源竞争是常态。当集群资源不足时，默认的调度策略会导致所有Pod平等竞争资源，这在实际生产环境中会带来严重问题。想象一下，一个承载核心支付服务的Pod和一个后台日志收集的Pod同时申请资源，如果它们被平等对待，可能导致支付服务不可用而日志收集却正常运行——这显然不是我们想要的结果。

优先级和抢占机制的核心价值在于：

• 确保关键业务Pod能够优先获得资源
• 允许低优先级Pod在资源紧张时被优雅终止
• 提供资源分配的确定性策略
• 避免"饿死"高优先级工作负载

注意：启用优先级功能需要同时配置PriorityClass和启用PodPriority准入控制器，否则配置不会生效。这是很多初学者容易忽略的点。

2. PriorityClass详解与配置实践

PriorityClass是定义Pod优先级的核心API对象。每个PriorityClass包含：

• 全局唯一的名称
• 优先级整数值（32位整数，越大优先级越高）
• 可选的描述字段
• 可选的globalDefault标志

典型配置示例：

yaml复制apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for critical service pods only"

关键配置要点：

1. value范围：通常建议系统级保留0-999999，用户自定义从1000000开始
2. globalDefault：集群中只能有一个PriorityClass将此字段设为true
3. 命名规范：建议使用类似"<环境>-<服务等级>"的命名方式，如prod-critical、dev-background等

实际使用中，我们通过Pod的spec.priorityClassName字段关联PriorityClass：

yaml复制apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  priorityClassName: high-priority

3. 抢占式调度的工作原理与流程

当kube-scheduler发现高优先级Pod因资源不足无法调度时，会触发抢占流程：

1. 筛选阶段：

   • 找出所有优先级低于待调度Pod的正在运行Pod
   • 排除系统关键Pod（如kube-system命名空间下的Pod）
   • 排除有preemptionPolicy: Never注解的Pod

2. 候选节点评估：

   • 对每个节点，计算如果抢占部分Pod后是否满足资源需求
   • 选择抢占Pod数量最少的节点
   • 如果多个节点条件相同，选择优先级总和最低的节点

3. 优雅终止：

   • 给被抢占Pod设置优雅终止期（默认30秒）
   • 发送SIGTERM信号
   • 超过宽限期后强制终止（SIGKILL）

4. 调度执行：

   • 等待目标节点资源释放
   • 调度高优先级Pod
   • 更新调度器缓存状态

重要细节：被抢占的Pod会进入Terminating状态，但可能被控制器（如Deployment）立即重新创建，这会导致抢占-重建循环。解决方法是为低优先级工作负载配置适当的PodDisruptionBudget。

4. 实战中的典型问题与解决方案

4.1 优先级配置不当导致的系统不稳定

常见错误模式：

• 过多Pod配置为高优先级，失去区分度
• 未为系统组件保留足够资源
• 优先级数值跳跃过大（如直接从100跳到1000000）

解决方案：

bash复制# 查看当前集群优先级分布
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.spec.priorityClassName}{"\t"}{.metadata.name}{"\n"