Kubernetes PriorityClass异常：低优先级Pod在高优先级PodPending时启动

这是预期行为，核心原因在于非抢占模式下调度器的工作机制：

问题本质 #

• 当PriorityClass设置preemptionPolicy: Never时，调度器仅能利用节点的空闲资源（如Pod结束释放的资源）调度Pod，不会主动抢占低优Pod资源。
• Kubernetes调度器对已处于Pending状态的Pod，会按固定周期（默认约5秒）重新尝试调度；而新提交的Pod会立即触发一次调度请求。
• 当节点出现空闲资源时，若此时恰好有新的低优Pod提交，调度器会优先处理这个即时触发的新Pod请求——只要资源足够，就会调度该低优Pod启动；而处于Pending的高优Pod要等到下一次周期调度时才会被重新评估，因此暂时仍处于Pending状态。

调整方案（按需选择） #

1. 开启抢占机制（优先推荐，若业务允许） #

将高优PriorityClass的preemptionPolicy改为PreemptLowerPriority：

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
preemptionPolicy: PreemptLowerPriority
globalDefault: false
description: "High priority class with preemption enabled"

此时高优Pending Pod会主动抢占低优Pod的资源，确保高优Pod优先调度，但会终止正在运行的低优Pod，需根据业务场景评估是否接受。

2. 优化调度器调度周期 #

修改kube-scheduler的配置，缩短Pending Pod的重新调度周期，同时确保优先级排序的权重最高。示例配置片段：

apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
  plugins:
    queueSort:
      enabled:
      - name: PrioritySort
  pluginConfig:
  - name: PrioritySort
    args:
      sortPriority: HighestPriority
  leaderElection:
    leaderElect: true
clientConnection:
  kubeconfig: /etc/kubernetes/scheduler.conf

此方案不会终止现有Pod，但会增加调度器的负载，需根据集群规模评估。

内容的提问来源于stack exchange，提问作者Dryade