@kapa.ai i want to limit the replication jobs pods resources on gke autopilot. i'm using this values file: global: serviceAccountName: "${k8s_service_account_name}" airbyteUrl: https://airbyte-qa.domain.com database: type: external # -- Secret name where database credentials are stored secretName: "airbyte-config-secrets" # e.g. "airbyte-config-secrets" # -- The database host host: "postgresqa.domain.com" # -- The database port port: "5432" # -- The database name name: "airbyteqa" # -- The database user userSecretKey: "user" # e.g. "database-user" # -- The key within

secretName

where password is stored passwordSecretKey: "password" # e.g."database-password" workloads: containerOrchestrator: secretName: "airbyte-config-secrets" secretMountPath: "/secrets/gcs-log-creds" auth: enabled: true instanceAdmin: firstName: "devops" lastName: "team" email: "devops@domain.com" storage: type: "gcs" secretName: "airbyte-config-secrets" bucket: # GCS bucket names that you've created. We recommend storing the following all in one bucket. log: ${bucket_name} state: ${bucket_name} workloadOutput: ${bucket_name} gcs: projectId: ${project_id} credentialsJsonPath: /secrets/gcs-log-creds/gcp.json jobs: resources: limits: cpu: 1000m memory: 1Gi requests: cpu: 500m memory: 1Gi serviceAccount: # -- Specifies whether a ServiceAccount should be created create: true # -- Annotations for service account. Evaluated as a template. Only used if

create

is

true

. annotations: "iam.gke.io/gcp-service-account": "${gcp_service_account}" # -- Name of the service account to use. If not set and create is true, a name is generated using the fullname template. name: "${k8s_service_account_name}" postgresql: enabled: false temporal: extraEnv: - name: SKIP_DB_CREATE value: "true" - name: DBNAME value: temporal_qa - name: VISIBILITY_DBNAME value: temporal_visibility_qa - name: POSTGRES_TLS_ENABLED value: "false" - name: SQL_TLS_ENABLED value: "false" still in logs i see 2025-12-25 134823 platform INFO [source] image: airbyte/source-postgres:3.7.0 resources: ResourceRequirements(claims=[], limits={memory=2Gi, cpu=2}, requests={memory=1Gi, cpu=1}, additionalProperties={}) 2025-12-25 134823 platform INFO [destination] image: airbyte/destination-bigquery:3.0.16 resources: ResourceRequirements(claims=[], limits={memory=2Gi, cpu=2}, requests={memory=1Gi, cpu=1}, additionalProperties={}) 2025-12-25 134823 platform INFO [orchestrator] image: airbyte/container-orchestrator:2.0.1 resources: ResourceRequirements(claims=[], limits={memory=2Gi, cpu=2}, requests={memory=2Gi, cpu=2}, additionalProperties={}) why?

I'm sorry, but the knowledge sources do not explicitly mention why your specific

global.jobs.resources

configuration is being ignored in version 2.0.1, but they do highlight several known behaviors and issues that explain why your replication pods are defaulting to higher values. Based on the provided documents, here are the likely reasons your configuration is not being applied: ### 1. Connector-Specific Overrides In recent versions of Airbyte, resource requirements defined at the actor (connector) level or connection level take precedence over global settings. Even if you set

global.jobs.resources

, these values may be overridden by: * Actor Definitions: Specific connectors (like

source-postgres

or

destination-bigquery

) often have hardcoded default resource requirements in the Airbyte database [[workload resource requests and limits not applied](https://github.com/airbytehq/airbyte/issues/68162)]. * Connection-level settings: Resource requirements can be set specifically for a single connection, which overrides global defaults [[Orchestrator container gets same resource limit/request values](https://discuss.airbyte.io/t/3775)]. ### 2. Known Parsing Issues with Millicore Values There is a documented issue in Airbyte (reported for version 2.0.1) where the workload-launcher fails to correctly parse millicore values (e.g.,

500m

,

1000m

) and falls back to default values (typically

cpu: 2

). * Workaround: Try setting your CPU values as integers (e.g.,

cpu: "1"

) instead of millicores (

1000m

) in your Helm values [[workload resource requests and limits not applied](https://github.com/airbytehq/airbyte/issues/68162)]. ### 3. Use of

workloads.resources

in newer versions For Airbyte versions 2.x, some documentation and issues suggest using the

workloads.resources

block rather than

global.jobs.resources

to manage replication settings. You may need to disable connector defaults explicitly:

yaml workloads:   resources:     useConnectorResourceDefaults: false     replication:       memory:         request: "1Gi"         limit: "1Gi"       cpu:         request: "1" # Use integer instead of "500m" due to parsing bugs         limit: "1"

[[workload resource requests and limits not applied](https://github.com/airbytehq/airbyte/issues/68162)] ### How to Verify To confirm which configuration is being detected, you can continue checking the job logs as you have been doing. Airbyte logs the specific

ResourceRequirements

for the source, destination, and orchestrator as they are launched [[Debugging Connection Resources](https://docs.airbyte.com/platform/2.0/operator-guides/configuring-connector-resources#debugging)]. If the logs still show

cpu=2

after changing to integer values, it highly suggests the connector-specific defaults in the database are overriding your global Helm values.

@kapa.ai it still don't work, how do i limit replication pods resources?

A message from kapa.ai