Priority classes
Every Pod on Kestrel must set priorityClassName to one of the three allowlisted uber-user-* classes. Kestrel allows three priority classes: uber-user-significant, uber-user-preempt-medium, and uber-user-preempt-high. Any other value — including the uber-infra-* classes reserved for platform workloads and the cluster-level uber-user-important class, which is not in the tenant allowlist — is rejected at admission. See Priority class allowlist for the Capsule enforcement details.
The three classes
Section titled “The three classes”| Class | Value | Preemption policy | Can preempt others? | Can be preempted? |
|---|---|---|---|---|
uber-user-preempt-high | 2000 | PreemptLowerPriority | Yes — any lower-priority Pod | Only by uber-infra-* (platform only) |
uber-user-preempt-medium | 1000 | PreemptLowerPriority | Yes — significant-class Pods | By preempt-high and uber-infra-* |
uber-user-significant | 500 | Never | No | By any preempt-* class and uber-infra-* |
Higher value = higher scheduling priority. A Pod can only preempt Pods with a lower priority value — a lower-value Pod can never evict a higher-value one. The preempt-* classes use the PreemptLowerPriority policy, so when the cluster is short on resources they evict lower-priority Pods to make room. uber-user-significant uses the Never policy: it never evicts anyone and simply waits for capacity.
How preemption works
Section titled “How preemption works”Preemption only kicks in when the cluster is full and a Pod cannot be scheduled:
- A
uber-user-preempt-*Pod that cannot fit will evict lower-priority Pods to free capacity, lowest priority first. - A
uber-user-significantPod (policyNever) never evicts anyone — when the cluster is full it sits Pending until capacity frees up. - Preemption respects the value ordering strictly:
preempt-high(2000) can preemptpreempt-medium(1000) andsignificant(500);preempt-mediumcan preempt onlysignificant;significantpreempts nothing.
Use uber-user-preempt-high for production long-running services — it has the highest user-tier priority and will preempt lower-priority peers to stay scheduled under cluster pressure.
Which class to use
Section titled “Which class to use”uber-user-significant
Section titled “uber-user-significant”Use for: workloads you can afford to lose — dev pods, scratch experiments, opportunistic batch jobs, and nightly CronJobs with weak SLAs.
Why: lowest user-tier priority. These pods are the first to be evicted when a preempt-* pod needs space. Non-preempting — they never evict anyone else. This is the right default for anything ephemeral or retry-tolerant.
The first-deployment walkthrough uses uber-user-significant because the demo workload is intentionally expendable.
uber-user-preempt-medium
Section titled “uber-user-preempt-medium”Use for: deadline-bound batch jobs — research runs that need to complete now and are worth taking capacity from significant peers.
Why: preempts significant-class pods to make room. Does not preempt preempt-high. Use when you have a real deadline and are willing to displace opportunistic workloads.
uber-user-preempt-high
Section titled “uber-user-preempt-high”Use for: production long-running services and critical interactive workloads — Deployments backing tenant-facing Ingress routes (the /running/workloads/long-running-service recommended variant), live analysis sessions, or time-sensitive dev pods where downtime costs more than the blast radius.
Why: highest user-tier priority. Preempts everything below it in the user tier (preempt-medium and significant) to stay scheduled under cluster pressure. Use sparingly — this is the highest blast radius among the three classes. If everyone uses preempt-high, nobody benefits from preemption because peers cancel each other out.
What about uber-infra-*?
Section titled “What about uber-infra-*?”The uber-infra-* classes exist at values around 900,000,000 — effectively infinitely higher than any user class. They are reserved for RCS-operated platform workloads (monitoring agents, Capsule controllers, etc.). Tenants cannot use them; Capsule admission rejects the attempt.
User preempt-* pods cannot evict infra pods. They can only evict each other or significant-class user pods.
Quick-reference mapping
Section titled “Quick-reference mapping”| Workload shape | Recommended class | Why |
|---|---|---|
| Production Deployment (Ingress-backed) | uber-user-preempt-high | Highest user-tier priority — stays scheduled under pressure |
| Critical live analysis session | uber-user-preempt-high | Worth the blast radius — use sparingly |
| Deadline-bound research Job | uber-user-preempt-medium | Willing to preempt opportunistic peers |
| Dev pod / scratch experiment | uber-user-significant | Expendable, eviction-tolerant |
| Nightly CronJob (weak SLA) | uber-user-significant | Re-runs tomorrow if preempted |