Kubernetes PriorityClass is a cluster-level Kubernetes object that assigns scheduling priority to pods. In practical terms, it tells the Kubernetes scheduler which workloads matter most when the cluster does not have enough CPU, memory, or other resources to run everything at once.
A PriorityClass gives pods a numeric priority value. Pods with higher values are scheduled before pods with lower values. If the cluster is short on resources, Kubernetes can also preempt lower-priority pods so a higher-priority pod can run.
This is useful when some workloads should stay available even during resource pressure. For example, you may want CoreDNS, an ingress controller, monitoring agents, or a production API to take priority over batch jobs, preview environments, or test workloads.
A PriorityClass is created once at the cluster level. Pods use it by setting priorityClassName in their pod spec.
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: production-critical
value: 100000
globalDefault: false
description: "Priority class for production workloads that should run before lower-priority workloads."
apiVersion: apps/v1
kind: Deployment
metadata:
name: payments-api
spec:
replicas: 3
selector:
matchLabels:
app: payments-api
template:
metadata:
labels:
app: payments-api
spec:
priorityClassName: production-critical
containers:
- name: app
image: example/payments-api:1.0.0
resources:
requests:
cpu: "500m"
memory: "512Mi"
When the pod is admitted, Kubernetes converts the named PriorityClass into an integer priority on the pod. The scheduler then uses that value when deciding which pending pods to place first.
Preemption is the behavior most engineers associate with PriorityClass. If a high-priority pod cannot be scheduled because no node has enough free resources, the scheduler may choose lower-priority pods as victims. Kubernetes terminates those lower-priority pods, then schedules the higher-priority pod when enough capacity is available.
Preemption is powerful, but it can cause real disruption. A preempted pod receives normal termination handling, including its termination grace period. If the workload has a PodDisruptionBudget, the scheduler tries to respect it, but Kubernetes may still violate a budget if no better option exists.
You can also create a non-preempting PriorityClass by setting preemptionPolicy: Never. Pods using that class move ahead in the scheduling queue, but they do not evict lower-priority pods.
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: high-priority-non-preempting
value: 50000
preemptionPolicy: Never
globalDefault: false
description: "High scheduling priority without evicting lower-priority pods."
For example, if you run data workflows such as Apache Airflow on AWS EKS, you may give the Airflow scheduler a higher priority than worker pods. The scheduler keeps coordinating work, while workers can restart if the cluster needs room for more urgent services.
metadata.name: The name pods reference through priorityClassName.value: The priority number. Higher values mean higher priority. Kubernetes reserves very high values for system-critical workloads.globalDefault: If true, pods without a priorityClassName receive this class by default. Only one PriorityClass in a cluster can be the global default.description: A human-readable explanation of when to use the class.preemptionPolicy: Controls whether pods using the class can preempt lower-priority pods. The common values are PreemptLowerPriority and Never.PriorityClass and Kubernetes QoS classes solve different problems.
A pod can be high priority and still have poor resource settings. For critical workloads, set both a sensible PriorityClass and accurate resource requests.
PriorityClass does not create capacity. If every node is full and all lower-priority pods have already been removed, a high-priority pod can still remain pending. You still need proper node sizing, autoscaling, and resource requests.
For example, a pod with priority 100000 and a memory request of 64Gi will not schedule on nodes that cannot provide that memory. Priority helps decide order. It does not bypass physical or configured capacity limits.
system-critical, production-critical, standard, and batch-low.Assume a startup runs one shared Kubernetes cluster for production APIs, internal tools, and nightly batch jobs. During a traffic spike, the cluster runs out of available CPU.
With PriorityClass configured:
production-critical with value 100000.standard with value 1000.batch-low with value 100.If new payments API pods need to start and no node has room, Kubernetes can terminate lower-priority report pods first. The reports may restart later, while the customer-facing API gets capacity sooner.
Platform teams often define a small set of approved PriorityClasses and expose them through workload templates, Helm charts, GitOps repositories, or internal developer platforms. Application teams choose from approved options instead of creating arbitrary priority values.
If your platform provisions cloud infrastructure through Kubernetes controllers, such as Crossplane, you may assign higher priority to the controllers that reconcile infrastructure state. For related infrastructure-as-code patterns, see this guide on deploying AWS resources using Crossplane on Kubernetes.
Kubernetes PriorityClass helps you control which pods get scheduled first and which workloads can preempt others when resources are scarce. Use it for clear workload tiers, protect truly critical services, and combine it with accurate resource requests, autoscaling, PodDisruptionBudgets, and capacity planning.