> For the complete documentation index, see [llms.txt](https://docs.cybus.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cybus.io/2-4-1/cybus-helm-charts/working-with-cybus-helm-charts/pod-priority-classes.md).

# Pod Priority Classes

Pod priority classes control how Kubernetes schedules and evicts pods when cluster resources are under pressure. Assigning a priority to Connectware components ensures they are scheduled first and are less likely to be evicted in favor of lower-priority workloads.

## When to Use Pod Priority Classes

Use pod priority classes when you need to control how Kubernetes handles resource contention in your cluster. This ensures important pods are not evicted when node resources become scarce.

## Configuration Values

The following Helm value assigns a pod priority class to Connectware components:

| Value                  | Description                                                                                                                       |
| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| `podPriorityClassName` | Name of the Kubernetes PriorityClass to assign to the component's pods. Must reference an existing PriorityClass in your cluster. |

## Checking Available Priority Classes

Before configuring Connectware components to use a priority class, verify which priority classes are already defined in your cluster:

{% code lineNumbers="true" %}

```bash
kubectl get priorityclasses
```

{% endcode %}

**Example output**

{% code lineNumbers="true" %}

```
NAME                      VALUE        GLOBAL-DEFAULT   AGE    PREEMPTIONPOLICY
default                   100000       true             102d   PreemptLowerPriority
high-priority             1000000      false            102d   PreemptLowerPriority
low-priority              1000         false            102d   Never
system-cluster-critical   2000000000   false            396d   PreemptLowerPriority
system-node-critical      2000001000   false            396d   PreemptLowerPriority
```

{% endcode %}

If the priority class you need does not exist, you must create it before referencing it in the Helm chart.

## Creating a Pod Priority Class

If your cluster does not already have an appropriate priority class, create one using `kubectl`. The following example creates a priority class named `high-priority` with a value of `1000000` and a preemption policy of `PreemptLowerPriority`:

{% code lineNumbers="true" %}

```bash
kubectl apply -f - <<EOF
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
preemptionPolicy: PreemptLowerPriority
description: "High priority class for critical workloads"
EOF
```

{% endcode %}

{% hint style="info" %}

## Preemption policies

With `preemptionPolicy: PreemptLowerPriority`, pods using this class are scheduled ahead of lower-priority pods. If the cluster is under resource pressure and no node has enough free capacity, Kubernetes may evict lower-priority pods to make room. Setting `preemptionPolicy: Never` still gives the pod scheduling preference without triggering any evictions.
{% endhint %}

For full details on priority values, preemption policies, and global defaults, see the [Kubernetes documentation on Pod Priority and Preemption](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/).

## Examples: Configuring Pod Priority Classes

The following tabs show how to configure pod priority classes for the `connectware` Helm chart and the `connectware-agent` Helm chart.

{% tabs %}
{% tab title="connectware Helm Chart" %}

## Configuring a Global Pod Priority Class

To apply a single priority class to **all** Connectware components at once, set the `global.podPriorityClassName` value.

**Example: Applying a priority class to all components as a global value**

{% code title="values.yaml" lineNumbers="true" %}

```yaml
global:
  licenseKey: ${LICENSE_KEY}
  podPriorityClassName: standard-priority
```

{% endcode %}

Replace `${LICENSE_KEY}` with your Connectware license key.

## Configuring a Pod Priority Class Per Component

Individual components can override the global setting or be given a priority class independently by setting `podPriorityClassName` under their own configuration section. A component-level value always takes precedence over `global.podPriorityClassName`.

All Connectware components and subcharts support this value.

{% hint style="warning" %}

## Cannot unset a global priority class with an empty string

While an individual component can override a global priority class with a different class, it cannot completely unset it. If `global.podPriorityClassName` is set, you cannot configure a component to have no priority class by passing an empty string.
{% endhint %}

**Example: Assigning a higher priority to the broker only**

{% code title="values.yaml" lineNumbers="true" %}

```yaml
global:
  licenseKey: ${LICENSE_KEY}
# Note: 'broker' is used as an example, but this configuration
# is applicable to any Connectware component.
broker:
  podPriorityClassName: high-priority
```

{% endcode %}

{% hint style="info" %}

## Global vs. component-level priority classes

Because no `global.podPriorityClassName` is set in this example, the priority class is applied only to the broker. All other Connectware components run without a priority class, or use the cluster's default priority class if one is configured.
{% endhint %}

**Example: Global priority class with a component-level override**

{% code title="values.yaml" lineNumbers="true" %}

```yaml
global:
  licenseKey: ${LICENSE_KEY}
  podPriorityClassName: standard-priority

# Override: give the NATS pods a higher scheduling priority
# than the rest of the Connectware components.
nats:
  podPriorityClassName: high-priority
```

{% endcode %}
{% endtab %}

{% tab title="connectware-agent Helm Chart" %}
The `connectware-agent` Helm chart can be deployed standalone or as a subchart within the `connectware` Helm chart. Both deployment modes use the same values structure, but when used as a subchart you need to configure it in the `connectwareAgent` Helm value section.

## Configuring a Default Pod Priority Class for All Agents When Deploying Standalone

To apply a single priority class to all agent pods at once, set the `protocolMapperAgentDefaults.podPriorityClassName` value.

{% code title="values.yaml" lineNumbers="true" %}

```yaml
protocolMapperAgentDefaults:
  podPriorityClassName: standard-priority

protocolMapperAgents:
  - name: my-agent-1
  - name: my-agent-2
```

{% endcode %}

## Configuring a Pod Priority Class Per Agent When Deploying Standalone

Individual agents can override the default setting or be assigned a priority class independently of it by setting `podPriorityClassName` under their own configuration section. An agent-level value always takes precedence over `protocolMapperAgentDefaults`.

**Example: Applying a priority class to a specific agent**

{% code title="values.yaml" lineNumbers="true" %}

```yaml
protocolMapperAgentDefaults:
  # ... shared defaults

protocolMapperAgents:
  - name: my-agent-1
    podPriorityClassName: standard-priority
  - name: my-agent-2
```

{% endcode %}

{% hint style="info" %}
Because no `protocolMapperAgentDefaults.podPriorityClassName` is set in this example, the `standard-priority` class is applied only to `my-agent-1`. All other agents run without a priority class, or use the cluster's default priority class if one is configured.
{% endhint %}

## Deploying Agents as Part of the connectware Helm Chart with a Global Priority Class

When using the `connectware-agent` subchart within the `connectware` Helm chart, you can configure a global priority class that applies to all Connectware components and agents. Configure this by setting `global.podPriorityClassName` in the values.

**Example: Deploying agents as part of the connectware Helm chart with a global priority class**

{% code title="values.yaml" lineNumbers="true" %}

```yaml
global:
  licenseKey: ${LICENSE_KEY}
  podPriorityClassName: standard-priority

connectwareAgent:
  protocolMapperAgentDefaults:
    # ... shared defaults

  protocolMapperAgents:
    - name: my-agent-1
    - name: my-agent-2
```

{% endcode %}

## Deploying Agents as Part of the connectware Helm Chart with a Global Priority Class and Per-Agent Override

Agents inherit the global values, which you can override by setting `podPriorityClassName` explicitly in `protocolMapperAgentDefaults` or `protocolMapperAgents[]`. This allows you to apply a priority class to all agents by default, then override individual agents with a different priority class.

{% code title="values.yaml" lineNumbers="true" %}

```yaml
global:
  licenseKey: ${LICENSE_KEY}
  podPriorityClassName: standard-priority

connectwareAgent:
  protocolMapperAgentDefaults:
    # ... shared defaults

  protocolMapperAgents:
    - name: my-agent-1
      podPriorityClassName: high-priority
    - name: my-agent-2
```

{% endcode %}

## Priority Evaluation Order

When deployed as a subchart, priority classes are evaluated in the following order:

1. Per-agent override (`protocolMapperAgents[].podPriorityClassName`)
2. Agent defaults (`protocolMapperAgentDefaults.podPriorityClassName`)
3. Global setting (`global.podPriorityClassName`)

{% hint style="warning" %}

## Cannot unset a priority class

If a default or global priority class is set, you cannot configure an individual component or agent to have no priority class by passing an empty string. Instead, it falls back to the next available value in the evaluation order.
{% endhint %}
{% endtab %}
{% endtabs %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.cybus.io/2-4-1/cybus-helm-charts/working-with-cybus-helm-charts/pod-priority-classes.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.