Kubernetes Priority Scheduling

Kubernetes Priority Scheduling is the mechanism by which Pods are assigned a relative importance value through PriorityClass objects, influencing both the order in which the scheduler attempts to place pending Pods and whether a pending Pod is allowed to trigger the eviction of lower-priority Pods to make room for itself. Priority does not change how an individual Pod is evaluated for fit against a single node — that logic remains governed by resource requests, affinity, and taints — but it changes the order of consideration across multiple competing Pods and unlocks the possibility of preemption when cluster capacity is insufficient for everyone.

A PriorityClass assigns a numeric value; higher numbers indicate higher priority, and every Pod referencing that class inherits it, giving cluster operators a way to express "this workload matters more than that one" in a form the scheduler actually acts on.

Defining Priority Classes

The PriorityClass Object

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: codartium-critical
value: 1000000
globalDefault: false
description: "Critical infrastructure workloads"

value is the numeric priority (higher wins); globalDefault: true marks a class as the implicit priority assigned to any Pod that does not explicitly reference a PriorityClass at all — a cluster should have at most one class marked as the global default.

Referencing It from a Pod

spec:
  priorityClassName: codartium-critical
  containers:
    - name: app
      image: codartium/critical-app:latest

How Priority Affects Scheduling Order

Queue Ordering

Pods in the scheduler's ActiveQ are ordered primarily by priority, meaning a newly created high-priority Pod is considered for placement ahead of lower-priority Pods that have already been waiting, even if those lower-priority Pods were created earlier — a deliberate design choice ensuring critical workloads are not starved during periods of sustained scheduling pressure.

No Effect on Per-Node Fit Logic

Priority itself does not make a Pod "fit" any better on a specific node — a high-priority Pod still needs sufficient allocatable resources, matching affinity, and tolerated taints on some node to be placed there directly, without preemption, exactly like any lower-priority Pod.

Preemption: Priority's Second Effect

Triggering Eviction to Make Room

When a pending Pod cannot be placed on any node without preemption, but could be placed if one or more lower-priority Pods on some node were evicted, the scheduler may trigger preemption: evicting just enough lower-priority Pods on a chosen node to free the resources the pending Pod needs, then scheduling the pending Pod there.

Preemption Is Not Automatic Escalation

Preemption is evaluated only as a fallback when normal, non-disruptive scheduling fails entirely for the pending Pod — it is not a routine part of every scheduling decision, and lower-priority Pods running happily on nodes with available capacity elsewhere are never touched simply because a higher-priority Pod exists somewhere in the cluster.

PodDisruptionBudget Interaction

Preemption respects PodDisruptionBudget where possible, but is not strictly bound by it — Kubernetes attempts to avoid violating a PDB during preemption, choosing eviction targets that would not, but if no such non-PDB-violating option exists, preemption may still proceed and violate a PDB rather than leave the higher-priority Pod unschedulable indefinitely.

System-Reserved Priority Classes

system-cluster-critical and system-node-critical

Kubernetes ships two built-in, extremely high-priority classes reserved for critical system components (system-cluster-critical for cluster-wide add-ons, system-node-critical for node-local components like the kubelet's own static Pods) — these are intended to ensure core cluster functionality is never preempted by ordinary application workloads, and application Pods should not reference these reserved classes directly.

Practical Priority Design

Establishing a Priority Tier Scheme

Clusters commonly define a small, deliberate set of PriorityClass tiers (critical infrastructure, production applications, batch/best-effort workloads) rather than a large number of finely graded values, since a simpler scheme is easier to reason about and audit than dozens of subtly different priority levels.

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: codartium-batch
value: 100
description: "Best-effort batch workloads, safe to preempt"

Avoiding Priority Inflation

Because priority is purely relative, unchecked proliferation of ever-higher-value classes (each team wanting their workload to outrank the last one they heard about) erodes the scheme's usefulness — governance over who can create new PriorityClass objects, often via RBAC restricting the scheduling.k8s.io API group, keeps the tiering meaningful over time.

Example

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: codartium-production
value: 10000
description: "Standard production workloads"
---
apiVersion: v1
kind: Pod
metadata:
  name: codartium-priority-example
spec:
  priorityClassName: codartium-production
  containers:
    - name: app
      image: codartium/app:latest
      resources:
        requests:
          cpu: "500m"
          memory: "512Mi"