Skip to main content
If your Mage app is deployed in a Kubernetes cluster, you can configure the Kubernetes Executor (executor_type: k8s) to run each block in its own Kubernetes pod. Defaults in Mage Pro:
  • Namespace: default
  • Job name format: mage-data-prep-block-{block_run_id}
You can override these defaults at the block level, project level, or with a full Kubernetes job template.

Basic Setup

To configure a pipeline block to use Kubernetes executor, you simply just need to update the executor_type of the block to k8s in pipeline’s metadata.yaml:
By default, Mage uses default as the Kubernetes namespace. You can customize the namespace by setting the KUBE_NAMESPACE environment variable.

Configuration Methods

You can configure Kubernetes Executor in three ways:

1. Block-Level Configuration

Add executor_config to a block in pipeline’s metadata.yaml:
Use when: You only want to:
  • Run certain blocks in the Kubernetes executor
  • Override the k8s executor config for specific blocks

2. Project-Level Configuration (applies to all k8s executor blocks)

Set k8s_executor_config in the project’s metadata.yaml:
  • The Kubernetes job name is in this format: mage-{job_name_prefix}-block-{block_run_id}. The default job_name_prefix is data-prep. You can customize it in the k8s_executor_config. You can interpolate the trigger name in the job_name_prefix field with the format {trigger_name}.
  • GPU Support:
    Make sure GPU device plugins are installed.
  • Custom container & job spec:
Use when: You want consistent settings for all blocks using the Kubernetes Executor in the project.

3. Full Kubernetes Job Template (maximum control)

Set the K8S_CONFIG_FILE environment variable to the path of a YAML configuration file. Example template:

Node Scheduling Configuration

Node Selector

Use node_selector to schedule pods on specific nodes based on labels:

Tolerations

Use tolerations to allow pods to be scheduled on tainted nodes:

Affinity Rules

Use affinity for advanced scheduling rules:

Custom Scheduler

Use a custom scheduler for advanced scheduling logic:
Use when: You need full control over pod specs, annotations, volume mounts, and other Kubernetes settings.

Multi-Container Pods

If your Mage deployment runs in a multi-container pod, set the MAGE_CONTAINER_NAME environment variable to specify which container runs Mage:
If not set, Mage defaults to the first container in the pod.

Default config file

You can provide a default K8s executor config file that Mage reads from the path in K8S_DEFAULT_CONFIG_PATH environment variable. The file is loaded as a policy and merged with block-level and project-level config. Use this to enforce cluster-wide defaults (e.g. resource limits, service account) without editing every project. Helm chart: When deploying Mage Pro with the Mage Helm chart, configure the default via k8sExecutorConfig in values.yaml. The chart creates a ConfigMap from your config, mounts it into the control-plane (and workspace pods), and sets K8S_DEFAULT_CONFIG_PATH automatically. Do not set the env var manually when using the chart. See Using Helm for details. For non-Helm deployments, set the env var and ensure the file exists at that path (e.g. via your own ConfigMap or volume mount). File format:
Policy fields: The file must exist at the given path on the Mage control-plane. Use a ConfigMap or volume mount to provide it. When workspaces are created, only the K8s default config file is injected (volume + volume mount + env var) so workspace pods can read it; see Workspaces. Priority when merging default file with user config The default file is merged with the combined user config (block + project). The effective priority order (who wins for a given key) depends on enforce: So when enforce: true, the policy has the highest priority; when enforce: false, block and project are higher and the policy only supplies missing values.

Environment Variables Reference

General Configuration

Environment Variables Reference

Default Resource Configuration

These environment variables set default resource limits and requests for all K8s executor jobs. They are applied when not specified in block-level or project-level configuration. Priority order (highest to lowest):
  1. Block-level executor_config in pipeline’s metadata.yaml
  2. Project-level k8s_executor_config in project’s metadata.yaml
  3. Environment variable defaults (listed above)
  4. Hardcoded defaults