@kapa.ai Is there a way to configure priority class for the job pods of airbyte to prevent eviction by karpenter for underutilization

I’m sorry, but the provided knowledge sources do not mention any way to configure a Kubernetes

priorityClassName

(or equivalent priority setting) for Airbyte job pods (sync/check/spec/discover). What is documented for controlling how job pods are scheduled are: - Node selectors and tolerations, via: -

JOB_KUBE_NODE_SELECTORS

and

JOB_KUBE_TOLERATIONS

environment variables on the worker / workload‑launcher [[Configuring Airbyte – Jobs](https://docs.airbyte.com/platform/operator-guides/configuring-airbyte#jobs); [Scaling Airbyte – multiple node groups](https://docs.airbyte.com/platform/enterprise-setup/scaling-airbyte#multiple-node-groups)]. - The corresponding

extraEnv

in the Helm

workload-launcher

and

worker

sections, for example:

yaml     workload-launcher:       extraEnv:         - name: JOB_KUBE_TOLERATIONS           value: "key=airbyte-server,operator=Equals,value=true,effect=NoSchedule"

[[Helm values snippet](https://github.com/airbytehq/airbyte/issues/49843)]. - Node group separation so that connector/job pods run on different node groups from “static” services. [[Scaling Airbyte – multiple node groups](https://docs.airbyte.com/platform/enterprise-setup/scaling-airbyte#multiple-node-groups)] However, none of the docs or issues above show: - a

JOB_KUBE_PRIORITY_CLASS

-style environment variable, or - any Helm values / examples setting

priorityClassName

on job pods. Given this, I can’t confirm any supported, documented way to configure a pod priority class for Airbyte job pods to influence Karpenter eviction behavior based on the current sources. You would likely need to use general Kubernetes mechanisms (e.g., custom admission controller, mutating webhook, or cluster‑wide policies) to inject a priority class into these pods, but this is not covered in the Airbyte documentation we have.