@kapa.ai I am trying to set up Airbyte using helm chart version 2.0.19. When I run a sync, the pods created (source-check, destination-check, replication-job, etc) do not have the labels I added via config (

global.jobs.kube.labels

) even though

JOB_KUBE_LABELS

has the correct value in the

helm template

output. The kube tolerations I set are applied to pods created for a sync, but not the labels. Any idea why?

The knowledge sources don’t explicitly describe this exact behavior for

global.jobs.kube.labels

on Helm chart v2.0.19, so I can’t give a definitive root cause. However, there are a few relevant data points: 1. Jobs-related labels setting In the values reference,

jobs.kube.labels

is documented as the Helm-side equivalent of

JOB_KUBE_LABELS

, which should be “pod labels of the sync job and the default pod labels fallback for others jobs.” [[Values ref](https://docs.airbyte.com/platform/2.0/deploying-airbyte/values)] You’re already seeing

JOB_KUBE_LABELS

correctly rendered in the env, so the chart is at least wiring the config into the environment. 2. Known pattern: tolerations work, selectors/labels don’t There is a prior report where

JOB_KUBE_TOLERATIONS

worked, but

JOB_KUBE_NODE_SELECTORS

did not get applied to the job pods, even though the env var was present and correct. [[Workload SA issue](https://github.com/airbytehq/airbyte/issues/50979)] Another user also reported that the fallback behavior for job-specific node selectors didn’t work for non‑sync jobs; they had to explicitly set

SPEC_JOB_KUBE_NODE_SELECTORS

,

CHECK_JOB_KUBE_NODE_SELECTORS

, and

DISCOVER_JOB_KUBE_NODE_SELECTORS

to get the behavior they wanted. [[Node selector forum](https://discuss.airbyte.io/t/4533)] These two together strongly suggest that, in some chart/platform versions, the job launcher code is **not consistently applying the generic “fallback” env vars (like

JOB_KUBE_*

) to all job types**, even though tolerations do work. 3. Implication for your case By analogy with the node selector issues above, it’s likely that: -

JOB_KUBE_TOLERATIONS

is correctly consumed by the job launcher for all job types. -

JOB_KUBE_LABELS

is either not wired through for all job types, or the fallback logic is buggy for some jobs (e.g., check/discover/replication), in your chart/platform version. Because the sources don’t show the v2.0.19 templates or code paths, I can’t confirm exactly which jobs are affected, only that this pattern has occurred before for similar settings. ### What you can try Based on the documented behavior and prior reports: 1. Set job‑specific env vars explicitly Instead of relying only on

JOB_KUBE_LABELS

, try setting the job‑specific variants via

extraEnv

(or the appropriate Helm fields if they exist in v2 for labels), for example: -

SPEC_JOB_KUBE_ANNOTATIONS

/

CHECK_JOB_KUBE_ANNOTATIONS

/

DISCOVER_JOB_KUBE_ANNOTATIONS

are documented for annotations; there is no explicit job‑specific labels list in the docs, but the node‑selector issue shows that job‑specific overrides can be required when fallback doesn’t work. [[Jobs‑specific](https://docs.airbyte.com/platform/2.0/operator-guides/configuring-airbyte#jobs-specific)] If your chart exposes job‑specific label fields analogous to node selectors, use those instead of relying on

global.jobs.kube.labels

. 2. Treat this as a likely bug/regression Given the prior bug reports where: - env vars were present but not applied to pods, and - fallback behavior didn’t work for non‑sync jobs, your situation with labels is very likely another instance of the same class of issue in the v2 chart/platform. [[Workload SA issue](https://github.com/airbytehq/airbyte/issues/50979); [Node selector forum](https://discuss.airbyte.io/t/4533)] If you need a definitive fix, the next step would be to open a GitHub issue against the Airbyte Helm chart, including: - Your

values.yaml

snippet (showing

global.jobs.kube.labels

and any

extraEnv

), - The rendered

JOB_KUBE_LABELS

env from

helm template

, - A sample job pod manifest showing missing labels. That will let the maintainers confirm whether this is a known bug in 2.0.19 and provide a patch or workaround.