Priority Classes

Purpose

Lumie defines three custom Kubernetes PriorityClass resources so critical platform services can preempt lower-priority work when the cluster is under pressure. The platform slice only defines the classes; individual workloads opt into them in their own Helm values or manifests.

This page is a reference document for developers changing workload scheduling priority or adding new cluster-wide priority tiers.

Source Paths

Path	Role
lumie-infra/platform/priority-classes/argocd.yaml	Argo CD application for the cluster-scoped PriorityClass manifests
lumie-infra/platform/priority-classes/manifests/priority-classes.yaml	Defines high-priority, medium-priority, and low-priority
lumie-infra/applications/argocd/helm-values.yaml	Uses high-priority for Argo CD
lumie-infra/bootstrap/vault/helm-values.yaml	Uses high-priority for Vault
lumie-infra/bootstrap/minio/helm-values.yaml	Uses high-priority for MinIO
lumie-infra/storage/cnpg/helm-values.yaml	Uses high-priority for CloudNativePG
lumie-infra/observability/{prometheus,loki,tempo,thanos}/helm-values.yaml	Use medium-priority for observability services

Defined Classes

Name	Value	Global default	Intended workload class
high-priority	1000	No	Critical infrastructure such as Argo CD, Vault, MinIO, and CNPG
medium-priority	500	No	Observability services such as Prometheus, Loki, Tempo, and Thanos
low-priority	100	Yes	Everything else that does not set a specific class

low-priority is the only globalDefault: true class, so omission is itself a scheduling decision.

Ownership Boundaries

Responsibility	Owner
Defining class names and numeric values	platform/priority-classes/manifests/priority-classes.yaml
Opting workloads into a class	Each workload's Helm values or manifest
Built-in Kubernetes critical classes	Kubernetes itself, not lumie-infra

One important exception is platform/coredns-config/daemonset.yaml, which uses Kubernetes' built-in system-cluster-critical rather than any Lumie-defined class.

Operational Notes

• PriorityClass is cluster-scoped, so the Argo CD Application for this slice has no destination namespace in platform/priority-classes/argocd.yaml.
• Changing a numeric value affects every workload already referencing that class name.
• Because low-priority is the global default, adding a new workload without a priorityClassName is equivalent to opting into the lowest custom Lumie tier.

Failure Modes

Failure point	Behavior
Workload omits priorityClassName	It receives low-priority by default
Workload references a non-existent class	Pod scheduling fails until the class exists
Numeric value change	Existing workloads keep the same class name but gain new preemption behavior immediately

Verification

cd lumie-infra
rg -n "priorityClassName|high-priority|medium-priority|low-priority" \
  platform bootstrap storage observability applications

kubectl get priorityclass
kubectl get application priority-classes -n argocd -o yaml