Pod Priority and Preemption

Welcome — this lesson explains Pod Priority and Preemption in Kubernetes: how the scheduler decides which workloads get cluster resources when capacity is limited, and how you can control that behavior using PriorityClass and preemptionPolicy. Pod Priority and Preemption are scheduler features that help guarantee critical system components and high-value applications get scheduled and remain running when the cluster is under resource pressure. We’ll use a concert-hall analogy to make the ideas easier to visualize. Imagine a large concert hall where seats are limited. VIPs, regular guests, and staff all arrive over time. Without a clear priority system, staff and VIPs might not get seats, and the event could fail. In Kubernetes, seats are cluster resources (CPU, memory, etc.), and people are Pods; Priority and Preemption ensure important Pods get the resources they need.

A slide titled "Pod Priority – Introduction" showing a large screen above rows of stylized pod-shaped seats with small colored head icons. A legend at right labels the colors: green for VIPs, orange for regular guests, and blue for staff members.

In Kubernetes terms:

Seats = available cluster capacity (CPU, memory, ephemeral storage)
People = Pods (workloads)
Priority = how important a Pod is relative to others
Preemption = evicting lower-priority Pods so higher-priority Pods can be scheduled

A slide titled "Kubernetes – Pod Priority" uses a concert-hall analogy: seats (resources like CPU/storage) on the left map to resources in a K8s cluster on the right, and people map to pods.

Many clusters run low-priority workloads (batch jobs, dev/test workloads, CI runners). If the cluster fills up, these low-priority Pods can block scheduling of more important Pods. Preemption lets the scheduler evict those lower-priority Pods to free resources for higher-priority Pods.

A presentation slide titled "Kubernetes – Pod Priority" showing three numbered categories: K8s System-Critical Pods (Kube-API, DNS, CNI, CSI), Application-Critical Pods (payment processing system), and Low-Priority Pods (batch jobs, background worker).

Preemption is like asking a regular guest to vacate their seat so a VIP or staff member can sit. Kubernetes may evict lower-priority Pods to create space for higher-priority Pods when scheduling fails due to resource constraints.

A slide titled "Kubernetes – Preemption" showing a K8s cluster with rows of high‑priority and low‑priority pod icons, and several low‑priority pods marked as preempted and moved into a separate area to make room for higher‑priority pods.

preemptionPolicy options

Pods can control whether they may preempt lower-priority Pods via the preemptionPolicy field in the Pod spec.
Two allowed values:

preemptionPolicy	Behavior	Use case
`PreemptLowerPriority`	(Default) This Pod may cause eviction of lower-priority Pods to be scheduled.	Use for workloads that must be scheduled even under pressure.
`Never`	This Pod will not preempt lower-priority Pods; it will not evict others to make room.	Use for pods that must not evict others (but note: they can still be evicted by higher-priority Pods).

A presentation slide titled "Preemption Type" showing two rounded boxes explaining preemptionPolicy: "PreemptLowerPriority" (default, lets pods of that PriorityClass preempt lower-priority pods) and "Never" (explicitly set so pods cannot be evicted). The slide includes brief bullet points under each heading.

Preemption is enabled by default in Kubernetes. Use preemptionPolicy: Never only when you must ensure this Pod does not preempt other pods; it does not protect the Pod from being evicted by higher-priority pods.

How priorities are defined

Kubernetes uses the PriorityClass resource to assign numeric priorities to pods.
Higher numeric value = higher priority.
Assign a PriorityClass by setting priorityClassName on the Pod (or Pod template inside a Deployment/StatefulSet/DaemonSet).

Example PriorityClass manifests:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000
globalDefault: false
description: "This priority class is for critical pods."

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: low-priority
value: 500
globalDefault: false
description: "This priority class is for less critical pods."

Assigning priority to Pods and Deployments Pod example:

apiVersion: v1
kind: Pod
metadata:
  name: high-priority-pod
spec:
  priorityClassName: high-priority
  containers:
  - name: nginx
    image: nginx:stable

Deployment example (priority applied to Pods created by the Deployment):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: high-priority-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      priorityClassName: high-priority
      containers:
      - name: nginx
        image: nginx:stable

Kubernetes also includes several built-in PriorityClasses for system-critical components. These built-ins use very large numeric values so system pods outrank user pods.

A slide titled "Default Priority Class" showing a table of Kubernetes priority classes (system-node-critical, system-cluster-critical, default) with their priority values, descriptions, and purposes. It also lists the numeric values 2000001000, 2000000000, and 0.

Quick reference table — typical priority classes

PriorityClass name	Typical value	Purpose
`system-node-critical`	`2000001000`	Node/system-critical components (reserved)
`system-cluster-critical`	`2000000000`	Cluster-critical system components
`default`	`0`	Default for user pods when no PriorityClass is set

Control preemption per-Pod

To prevent a Pod from preempting lower-priority Pods, set preemptionPolicy: Never in the Pod spec.
That does not prevent the Pod itself from being evicted by a higher-priority Pod.

Example: a low-priority Pod that will not preempt others:

apiVersion: v1
kind: Pod
metadata:
  name: non-preemptible-pod
spec:
  priorityClassName: low-priority    # Using a low-priority class
  preemptionPolicy: Never            # This pod will not preempt lower-priority pods
  containers:
  - name: non-preemptible-container
    image: nginx:stable

Best practices and operational guidance

Use PriorityClasses deliberately. Over-assigning high priority reduces scheduler flexibility.
Reserve the highest numeric values for critical system components.
Use preemptionPolicy: Never sparingly and only when necessary.
Test preemption behavior in staging before applying critical PriorityClasses in production.
Combine Priority/Preemption with resource requests/limits and PodDisruptionBudgets (PDBs) for predictable scheduling and resilience.

Summary

Pod Priority ensures critical workloads are preferred by the scheduler when resources are scarce.
Preemption frees resources for higher-priority Pods by evicting lower-priority Pods when necessary.
Priority is defined with PriorityClass resources and assigned via priorityClassName in Pod specs.
Use preemptionPolicy to control whether a Pod may evict lower-priority Pods.

Manual Scaling

Horizontal Pod Autoscaler (HPA)

Vertical Pod Autoscaler (VPA)

Cluster Proportional Autoscaler (CPA)

Kubernetes Event-Driven Autoscaling (KEDA)

Introduction

Pod Priority and Preemption

Watch Video

Practice Lab