In Kubernetes, what does a PriorityClass object do, how does a pod end up with a priority value, and what is the globalDefault field for?

## What "priority" means here Every pod carries an integer field `spec.priority`. Higher means more important. Kubernetes uses that integer for exactly two purposes: 1. **Queue order in the scheduler.** kube-scheduler keeps pending pods in a priority queue; its default `QueueSort` plugin orders by priority descending, then by the time the pod became unschedulable. A high-priority pod therefore gets a scheduling *attempt* before lower-priority pods that have been waiting longer. 2. **Eligibility to preempt.** If a pending pod cannot fit on any node, the scheduler may evict running pods whose priority is *strictly lower* to make room. Priority is **not** a CPU share, **not** the QoS class (`Guaranteed`/`Burstable`/`BestEffort`, which comes from requests vs limits), and it does not make a running pod faster or protect it from anything other than being outranked. A running pod's priority becomes relevant again only in two places: it can be chosen as a preemption victim, and kubelet's node-pressure eviction uses priority as a tiebreaker when ranking pods that exceed their requests. ## The PriorityClass object ```yaml apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: business-critical value: 1000000 globalDefault: false preemptionPolicy: PreemptLowerPriority description: "Customer-facing request path" ``` Key properties: - **Cluster-scoped.** There is no namespace on a PriorityClass; the same names are visible to every namespace. Access is controlled with RBAC on the `scheduling.k8s.io` group, and *consumption* is limited per namespace with a `ResourceQuota` carrying a `scopeSelector` on `PriorityClass`. - **`value` is an int32**, and values for user-created classes must be **≤ 1,000,000,000** (one billion). The range above that is reserved so that system components always outrank anything a tenant can create. - **`description`** is free text shown to humans; use it, because a bare integer tells the next engineer nothing. - **`preemptionPolicy`** (`PreemptLowerPriority`, the default, or `Never`) decides whether pods in this class are allowed to evict others. It does not change their queue position. ## How a pod acquires the value You write a *name*, not a number: ```yaml spec: priorityClassName: business-critical ``` The **Priority admission controller** (enabled by default) looks the class up and sets `spec.priority: 1000000` on the pod object. Consequences worth remembering: - Referencing a class that does not exist makes pod **creation fail** — which matters when a Deployment's template names a class you forgot to install: the ReplicaSet controller keeps retrying and no pods appear. - Because resolution happens at admission, the priority is **frozen into the pod**. Changing the PriorityClass `value` afterwards, or deleting the class, does not change pods that already exist. Deleting a class only prevents *new* pods from using it. - You cannot hand-set `spec.priority` to an arbitrary number to outrank your neighbours; the API rejects a value that disagrees with the named class (only the system may set priority directly). ## globalDefault At most one PriorityClass in the cluster may set `globalDefault: true`. Pods admitted **without** a `priorityClassName` then receive that class's value. If no such class exists, priority defaults to **0**. Two details bite people: - The default is applied **at admission only**. Creating a `globalDefault` class today does not raise yesterday's pods; they stay at whatever they were admitted with. - Setting a high `globalDefault` is a trap: it lifts the floor for everything unlabeled, so your "important" tier stops being distinguishable and *every* new pod becomes able to preempt older ones. Most clusters either leave the default at 0 or point `globalDefault` at a deliberately **low** class (e.g. value 0 or negative — negative values are legal) so that opportunistic work sinks below labeled workloads. If two classes claim `globalDefault: true` (possible if they race), the behaviour is undefined-ish: the smallest value wins in practice, but treat it as a misconfiguration and fix it. ## Built-in classes Every cluster ships `system-cluster-critical` (value 2000000000) and `system-node-critical` (value 2000001000) for control-plane and node-level add-ons. They sit above the user ceiling by design. Do not attach them to application workloads: they can preempt essentially anything, and `system-node-critical` also changes kubelet eviction behaviour. ## Practical shape of a scheme A workable ladder is small and spaced out — for example `platform-critical: 1000000`, `production: 100000`, `staging: 10000`, `batch: 0`, `preemptible: -10`. Wide gaps leave room to insert a tier later without renumbering, and few tiers keep the eviction story explainable during an incident.