Pod Priority Classes

Assign pod priority classes to Connectware and Connectware agent components to control scheduling order and protect critical workloads from eviction.

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:

kubectl get priorityclasses

Example output

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

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:

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

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.

For full details on priority values, preemption policies, and global defaults, see the Kubernetes documentation on Pod Priority and 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.

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

values.yaml

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

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.

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.

Example: Assigning a higher priority to the broker only

values.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

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.

Example: Global priority class with a component-level override

values.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

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.

values.yaml

protocolMapperAgentDefaults:
  podPriorityClassName: standard-priority

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

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

values.yaml

protocolMapperAgentDefaults:
  # ... shared defaults

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

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.

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

values.yaml

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

connectwareAgent:
  protocolMapperAgentDefaults:
    # ... shared defaults

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

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.

values.yaml

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

connectwareAgent:
  protocolMapperAgentDefaults:
    # ... shared defaults

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

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)

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.