Summary
Explaining how to set resource requests/limits for containers in Kubernetes using Helm chart and the purpose of the airbyte-workload-launcher subchart.
Question
Using the Helm chart to deploy to Kubernetes:
• How does one set the resource requests/limits for containers launched in the orchestration controller pods?
• What does the https://github.com/airbytehq/airbyte-platform/tree/main/charts/airbyte-workload-launcher|airbyte-workload-launcher subchart do?
This topic has been created from a Slack thread to give it more visibility.
It will be on Read-Only mode here. Click here if you want to access the original thread.
Join the conversation on Slack
["kubernetes", "helm-chart", "resource-requests", "resource-limits", "airbyte-workload-launcher"]
In this example I would like to configure the resource limits/requests for the relay-* pods.
It is not clear from documentation, or forums, or code how to do that.
It is not clear how to configure resources requests for containers that are not directly provisioned by the Helm chart.
My colleague found this YAML file, but it doesn’t look like the resources settings are exposed for the source/destination-stdin/stdout
https://github.com/airbytehq/airbyte-platform/blob/main/airbyte-server/src/main/resources/application.yml#L189
## choice for the user. This also increases chances charts run on environments with little
## resources, such as Minikube. If you do want to specify resources, uncomment the following
## lines, adjust them as necessary, and remove the curly braces after 'resources:'.```
<https://github.com/airbytehq/airbyte-platform/blob/main/charts/airbyte/values.yaml#L187C1-L190C86>
can AirbyteHQ expose ALL resource settings?
The job pods are all governed by:
JOB_MAIN_CONTAINER_MEMORY_LIMIT
JOB_MAIN_CONTAINER_CPU_REQUEST
JOB_MAIN_CONTAINER_CPU_LIMIT
Values can also be set in the specific image as well, IIRC
oh, sorry, Helm. You want:
jobs:
resources:
requests:
memory: 256Mi
cpu: 250m
limits:
memory: 2Gi
cpu: 1000m```
. . . which set the same things. Basically these are used for all the “sync worker” (orchestrator, source, and destination) pods that get spun up by the main worker (which has its own config)
<@U035912NS77>, thanks! I’ll try that
I think I’ve already tried those (JOB_MAIN_*) and it doesn’t have an effect on the destination/source pods. But I’ll try setting it through the global.jobs.resources setting in the values.yaml
Rather-- the source/destination containers
EDIT
The relay-* containters
You can also override a specific connection (or specific source actor_definition) by adding JSON to the resource_requirements key in the configuration JSON. I know this is supported by the <OpenTofu and Terraform Registry provider> directly, but I was having a hard time finding a link that outlines this other than <Airbyte Databases Data Catalog | Airbyte Documentation bullet point> for actor_definition and this <Airbyte Databases Data Catalog | Airbyte Documentation point> for connections.
UPDATE: Found a better example in <https://docs.airbyte.com/operator-guides/configuring-connector-resources/|this article> for setting them on specific sources/connections.
I’ll look at the tf provider
<@U048YEKC57E> Hah, the terminology is a beast.
But for the most part, for Helm, ignore anything you read about Environment variables unless it’s setting them in env/extraEnv or translating it to the existing config keys like this from values.yaml—ultimately those config keys are just creating the env vars in all the right places
you can also just edit them in the database. just make sure it’s valid 
but the main way communicated is that jobs section of the values.yaml, largely because it’s easier. if you have a single connector that needs a ton of resources though, I would probably set it on either just that connection itself
There are some notes on this article that talk about the order of precedence of these settings as well:
https://docs.airbyte.com/operator-guides/configuring-connector-resources/
Along with the SQL queries you’d use to set them