Skip to main content
Kubernetes schedules Pods according to their priority. Critical system components, important databases, or other business-critical services should run ahead of lower-priority workloads such as background jobs. PriorityClasses let you assign integer priority values to workloads so the scheduler prefers higher-priority Pods and, when necessary, evicts lower-priority Pods to make room. PriorityClass objects are cluster-scoped (non-namespaced) and can be referenced by Pods in any namespace. Priorities use a signed 32-bit integer range: from -2,147,483,648 to 2,147,483,647. Larger numbers indicate higher priority. Kubernetes system and control-plane classes typically use very large values (for example, around 2,000,000,000) so they outrank application-level priorities.
A presentation slide titled "Priorities" showing four rows — Kubernetes Components, Databases, Critical Apps, and Jobs — mapped across three phone-like columns with colored dots. To the right a diagram groups "System" and "Apps" and displays priority numbers (2,000,000,000; 1,000,000,000; -2,147,483,648).
Why use PriorityClasses
  • Ensure mission-critical Pods are scheduled ahead of less-important workloads.
  • Control eviction behavior during resource contention via preemptionPolicy.
  • Provide a cluster-wide, reusable priority model by defining PriorityClass objects once and referencing them from any namespace.
Quick: list existing PriorityClasses
PriorityClass: key fields Creating and using a PriorityClass
  • PriorityClasses are created with apiVersion: scheduling.k8s.io/v1 and kind: PriorityClass.
  • The value field is the integer priority used by the scheduler.
  • description is optional and helps document intent.
  • globalDefault (optional boolean) makes a single PriorityClass the default for Pods that do not specify priorityClassName. Only one PriorityClass may have globalDefault: true.
Example: define a PriorityClass and a Pod that uses it
Note: If a Pod omits priorityClassName and no PriorityClass is marked globalDefault: true, the Pod receives a default numeric priority of 0.
Only one PriorityClass may have globalDefault: true. If multiple classes set globalDefault: true, the creation/update will be rejected.
How pod priority and preemption work
  • The scheduler orders pending Pods by priority and tries to schedule higher-priority Pods first.
  • If a pending higher-priority Pod cannot be scheduled because of insufficient resources, the scheduler consults the pending Pod’s preemptionPolicy.
    • PreemptLowerPriority (default): the scheduler may evict lower-priority Pods to free resources.
    • Never: Pods of this PriorityClass will not evict running Pods; they stay in the scheduling queue until resources become available.
  • Preemption only occurs if evicting one or more lower-priority Pods would make scheduling the pending Pod feasible. The scheduler attempts to minimize eviction cost.
Visualizing scheduling order:
  • Given limited resources, a Pod with priority 7 will be scheduled before a Pod with priority 5. If necessary and allowed, lower-priority Pods may be evicted to accommodate the higher-priority Pod.
A presentation slide titled "Effect of Pod Priority" showing three phone-shaped nodes on the right running "Critical Apps" with orange priority badges labeled 7. A long "Jobs" lane on the left shows lower-priority green pods labeled 5.
Examples: preemption policy behavior Default (explicit) — allows preemption:
Non-preempting PriorityClass — never evicts others:
Important considerations
  • Use high numeric priorities sparingly and document their intent — overly aggressive priorities can lead to frequent evictions and cluster instability.
  • Reserve extremely large values for Kubernetes system components to avoid conflicts with application priorities.
  • Monitor eviction events (kubectl get events, metrics, and logs) to understand how priority and preemption affect your workloads.
Further reading and references That’s it for this lesson.

Watch Video

Practice Lab