This module creates a set of priority classes and assigns them to components installed by Deckhouse and applications in the cluster.

Priority classes are utilized by the scheduler to determine a Pod’s priority based on the class it belongs to during scheduling.

For example, when deploying Pods with priorityClassName: production-low, if the cluster lacks sufficient resources, Kubernetes will start evicting Pods with the lowest priority to accommodate the production-low Pods. That is, Kubernetes will first evict all Pods with priorityClassName: develop Pods, then proceed to cluster-low Pods, and so on.

When setting the priority class, it is crucial to understand the type of application and the environment it operates in. Assigning any priority class does not lower a Pod’s priority because Pods without a specified priority class are considered to have the lowest priority.

You cannot use the following priority classes: system-node-critical, system-cluster-critical, cluster-medium, cluster-low.

Below is the list of priority classes set by the module (sorted by the priority from highest to lowest):

Priority class Description Value
system-node-critical Cluster components that must be present on the node. This priority class fully protects components against eviction by kubelet.
Examples: node-exporter, csi, and others.		 2000001000
system-cluster-critical Cluster components that are critical to its correct operation. This PriorityClass is mandatory for MutatingWebhooks and Extension API servers. It also fully protects components against eviction by kubelet.
Examples: kube-dns, kube-proxy, cni-flannel, cni-cilium, and others.		 2000000000
production-high Stateful applications in the production environment. Their unavailability leads to service downtime or data loss.
Examples: PostgreSQL, Memcached, Redis, MongoDB, and others.		 9000
cluster-medium Cluster components responsible for monitoring (alerts, diagnostic tools) and autoscaling. Without monitoring, assessing the scale of incidents is impossible; without autoscaling, applications cannot receive necessary resources.
Examples: deckhouse, node-local-dns, grafana, upmeter, and others.		 7000
production-medium Main stateless applications in the production environment that are responsible for operating the service for end-users. 6000
deployment-machinery Cluster components that are responsible for deploying/building. 5000
production-low Non-critical, secondary applications in the production environment (crons, admin dashboards, batch processing). For important batch or cron jobs, consider assigning them the production-medium priority. 4000
staging Staging environments for applications. 3000
cluster-low Cluster components that are desirable but not essential for proper cluster operation.
Examples: dashboard, cert-manager, prometheus, and others.		 2000
develop (default) Develop environments for applications. The default class for a component (if other priority classes aren’t set). 1000
standby This class is not intended for applications. It is used for system purposes (reserving nodes). -1