# Pod Priority Classes in Kubernetes

Pod Priority Classes in Kubernetes are a scheduling mechanism that lets you assign importance levels to different pods. When the cluster faces resource constraints, Kubernetes uses these priorities to decide which pods should be scheduled or evicted first.

## 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:

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

Assign it to a pod:

```none
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

- [Kubernetes Official Docs – Pod Priority and Preemption](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/)
- [Kubernetes Scheduling Overview](https://kubernetes.io/docs/concepts/scheduling-eviction/)

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.