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 podsglobalDefault
: 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.