Background

Introduced in Kubernetes 1.11, Pod Priority Classes became a stable feature in version 1.14. They were designed to improve control in multi-tenant and high-traffic environments, where critical services must be protected from eviction or scheduling delays during resource shortages.

Why They Matter

In a real-world cluster, resources aren’t unlimited. When there’s pressure—say during scale-out events, bursty workloads, or maintenance—Kubernetes may need to evict pods or delay scheduling new ones. Without priorities, all pods are treated equally, and essential workloads (e.g., APIs, metrics agents) might be delayed or evicted just like batch jobs.

Pod Priority Classes allow you to:

  • Ensure critical workloads are scheduled before lower-priority ones.
  • Protect vital services from being evicted during node pressure.
  • Automatically preempt less important pods if needed.

How It Works

Each pod can be assigned a priorityClassName referring to a predefined PriorityClass object. This object includes:

  • value: An integer (higher = higher priority)
  • preemptionPolicy: Whether the pod can preempt lower-priority pods
  • globalDefault: Whether this is the default priority for pods without a specific class

When the scheduler evaluates pods, it uses the priority value to make decisions:

  • Higher-priority pods are scheduled first
  • Lower-priority pods may be preempted to make room for higher-priority ones

Example

Define a high-priority class:


  apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 100000
preemptionPolicy: PreemptLowerPriority
globalDefault: false

Assign it to a pod:


  spec:
  priorityClassName: high-priority

Use Cases

  • Critical APIs or services: Ensure uptime during scale-outs
  • Monitoring/logging agents: Prevent eviction under node pressure
  • Batch processing: Assign lower priorities to allow preemption when needed

Best Practices

  • Use wide value spacing (e.g., 1000, 10000, 100000) to allow future flexibility
  • Avoid making all workloads high-priority—reserve it for truly critical pods
  • Use globalDefault: true for your baseline class
  • Combine with resource requests/limits and graceful shutdown handlers for optimal behavior

Limitations

  • Misuse (e.g., assigning high priority to everything) negates the benefit
  • Preemption can cause churn if poorly planned
  • Doesn’t control QoS or bandwidth—only scheduling and eviction order

Related Concepts

  • Pod Disruption Budgets (PDBs): Control voluntary disruptions, not evictions under pressure
  • QoS Classes: Determined by resource requests and limits, not related to priority

Learn More

Pod Priority Classes give you an extra layer of control to ensure your most important workloads stay up and responsive—even when your cluster is under stress.