Run the Kubernetes executor on Astronomer Software
The Kubernetes Executor creates individual Pods that dynamically delegate work and resources to individual tasks. For each task that needs to run, the executor works with the Kubernetes API and dynamically launches Pods which terminate when the task is completed.
You can customize your Kubernetes Pods to scale depending on how many Airflow tasks you’re running at a given time. It also means you can configure the following for each individual Airflow task:
- Memory allocation
- Service accounts
- Airflow image
To configure these resources for a given task’s Pod, you specify a pod_override
in your DAG code. To specify a Pod template for many or all of your tasks, you can write a helper function to construct a pod_override
in your DAGs or configure a global setting. For more information on configuring Pod template values, reference the Kubernetes documentation.
Prerequisites
You must have an Airflow Deployment on Astronomer running with the Kubernetes executor. For more information on configuring an executor, see Configure a Deployment. To learn more about different executor types, see Airflow executors explained.
Configure the default worker Pod for all Deployments
By default, the Kubernetes executor launches workers based on a podTemplate
configuration in the Astronomer Airflow Helm chart.
You can modify the default podTemplate
to configure the default worker Pods for all Deployments using the Kubernetes executor on your Astronomer Software installation. You can then override this default at the task level using a pod_override
file. See Configure the worker Pod for a specific task.
-
In your
values.yaml
file, copy the completepodTemplate
configuration from your version of the Astronomer Airflow Helm chart. Your file should look like the following: -
Customize the pod template configuration based on your use case, such as by requesting default limits on CPU and memory usage. To configure these resources for each Pod, you configure a Pod template. For more information on configuring Pod template values, see the Kubernetes documentation.
-
Push the configuration change to your platform. See Apply a config change.
Configure the worker Pod for a specific task
For each task with the Kubernetes executor, you can customize its individual worker Pod and override the defaults used in Astronomer Software by configuring a pod_override
file.
-
Add the following import to your DAG file:
-
Add a
pod_override
configuration to the DAG file containing the task. See thekubernetes-client
GitHub for a list of all possible settings you can include in the configuration. -
Specify the
pod_override
in the task’s parameters.
Example: Set CPU or memory limits and requests
One of the most common use cases for customizing a Kubernetes worker Pod is to request a specific amount of resources for a task.
The following example shows how you can use a pod_override
configuration in your DAG code to request custom resources for a task:
When this DAG runs, it launches a Kubernetes Pod with exactly 0.5m of CPU and 1024Mi of memory, as long as that infrastructure is available in your cluster. Once the task finishes, the Pod terminates gracefully.
Mount secret environment variables to worker Pods
Deployment environment variables marked as secrets are stored in a Kubernetes secret called <release-name>-env
on your Deployment namespace. To use a secret value in a task running on the KubernetesExecutor, mount the secret to the Pod running the task.
-
Run the following command to find the namespace (release name) of your Airflow Deployment:
-
Add the following import to your DAG file:
-
Define a Kubernetes
Secret
in your DAG instantiation using the following format: -
Specify the
Secret
in thesecret_key_ref
section of yourpod_override
configuration. -
In the task where you want to use the secret value, add the following task-level argument:
-
In the executable for the task, call the secret value using
os.environ[env_name]
.
In the following example, a secret named MY_SECRET
is pulled from infrared-photon-7780-env
and printed to logs.