Skip to main content
In this lesson we cover PriorityClasses in Kubernetes — how they influence scheduling order, how to create them, and how preemption works. Kubernetes runs many pods with different importance. Some workloads must always run (for example, control plane components). Others — such as high-priority databases or critical user-facing services — should be scheduled ahead of less important workloads like batch jobs or background tasks. PriorityClasses let you express those priorities. The scheduler uses priority values to decide which pods to schedule first. When the cluster is under resource pressure, higher-priority pods can cause lower-priority pods to be evicted so the former can run. PriorityClasses are cluster-scoped (non-namespaced): once created, they can be referenced by pods from any namespace via the pod’s priorityClassName.
Priority values are 32-bit signed integers (range -2,147,483,648 to 2,147,483,647). By convention, user-defined priorities use values well below 1,000,000,000. Kubernetes reserves very large values (near 2,000,000,000) for system-critical components such as control plane pods.
A dark-themed slide titled "Priorities" showing four rows (Kubernetes Components, Databases, Critical Apps, Jobs) mapped across three phone-shaped columns with colored dot markers. To the right are labeled boxes for "System" and "Apps" with numeric values (2,000,000,000; 1,000,000,000; -2,147,483,648) and arrows indicating relationships.

​
List PriorityClasses in a cluster

To see the PriorityClasses currently defined in your cluster:

​
Create a PriorityClass

A PriorityClass object uses API group scheduling.k8s.io/v1 and kind PriorityClass. You provide a numeric value and can also set description, globalDefault, and preemptionPolicy. Example PriorityClass manifest:
Pod manifest referencing the priority class:
Notes:
  • If a pod does not set priorityClassName, its effective priority is 0 by default.
  • Only one PriorityClass in the cluster may set globalDefault: true. That single class defines the default priority for pods that omit priorityClassName.
Only one PriorityClass may be marked globalDefault: true. Attempting to create multiple global defaults will cause ambiguous default behavior — choose carefully.

​
PriorityClass fields (quick reference)

​
Effect of pod priority on scheduling

When multiple pods compete for scarce resources, the scheduler orders them by priority. Higher-priority pods get scheduled before lower-priority pods. For example, given a critical app with priority 7 and a jobs app with priority 5, the scheduler will place the priority-7 pod first; remaining capacity, if any, is then used for lower-priority pods.
A dark-themed diagram titled "Effect of Pod Priority" showing a "Jobs" row with green "5" tokens and a "Critical Apps" row with orange "7" tokens allocated into three phone-shaped pods on the right. It illustrates how higher-priority (7) apps occupy pod slots while lower-priority (5) jobs remain on the left.

​
Preemption behavior

If a higher-priority pod cannot be scheduled because there are no free resources, the scheduler checks the pod’s PriorityClass preemptionPolicy. If preemptionPolicy is omitted, the default behavior is PreemptLowerPriority: the scheduler may evict lower-priority pods to make space. Example explicit default preemption policy:
If you do not want pods of this class to evict others, set preemptionPolicy: Never. Such pods will remain in the scheduling queue until resources become available. They still rank above other waiting pods but will not trigger eviction. Example non-preempting PriorityClass:
preemptionPolicy is case-sensitive. Use exactly PreemptLowerPriority or Never. Choosing Never prevents eviction but can leave higher-priority pods unscheduled until resources free up.

​
Additional resources

That’s it for this lesson.

Watch Video

Practice Lab