> ## Documentation Index
> Fetch the complete documentation index at: https://astronomer.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Run the KubernetesPodOperator on Astro

The [`KubernetesPodOperator`](https://airflow.apache.org/docs/apache-airflow-providers-cncf-kubernetes/stable/operators.html) is one of the most customizable Apache Airflow operators. A task using the `KubernetesPodOperator` runs in a dedicated, isolated Kubernetes Pod that terminates after the task completes. To learn more about the benefits and usage of the `KubernetesPodOperator`, see the [`KubernetesPodOperator` Learn guide](/docs/learn/kubepod-operator).

On Astro, the infrastructure required to run the `KubernetesPodOperator` is built into every Deployment and is managed by Astronomer. Astro supports setting a default Pod configuration so that any task Pods without specific resource requests and limits cannot exceed your expected resource usage for the Deployment.

Some task-level configurations will differ on Astro compared to other Airflow environments. Use this document to learn how to configure individual task Pods for different use cases on Astro. To configure the default Pod resources for all `KubernetesPodOperator` Pods, see [Configure Kubernetes Pod resources](/docs/astro/deployment-resources#configure-kubernetes-pod-resources).

## Known limitations

<Tip>By default, Astro supports a maximum `KubernetesPodOperator` Pod size of 43 vCPU and 86 GiB of memory. Astro can support Pod sizes up to 86 vCPU and 172 GiB of memory on request. Contact [Astro support](/docs/astro/astro-support) if you need to run larger jobs on `KubernetesPodOperator`.</Tip>

* Cross-account service accounts are not supported on Pods launched in an Astro cluster. To allow access to external data sources, you can provide credentials and secrets to tasks.
* Astro uses the following default Airflow labels on KPO Pods for internal health management:

  * `kubernetes_pod_operator`
  * `dag_id`
  * `task_id`
  * `run_id`
  * `map_index`
  * `try_number`

  Do not remove or modify these labels. Changing them prevents Astro from reconciling Pods with running task instances, which can cause the KPO healer to incorrectly handle your Pods. You can add your own custom labels to KPO Pods without affecting this behavior. See [Configure task-level Pod resources](/docs/astro/kpo-task-level-resources) for an example.
* PersistentVolumes (PVs) are not supported on Pods launched in an Astro cluster.
* You can't use an image built for an ARM architecture in the `KubernetesPodOperator`. To build images using the x86 architecture on a Mac with an Apple chip, include the `--platform` flag in the `FROM` command of the `Dockerfile` that constructs your custom image. For example:

  ```dockerfile wrap theme={null}
  FROM --platform=linux/amd64 postgres:latest
  ```

  If you use an ARM image, your KPO task will fail with the error: `base] exec /usr/bin/psql: exec format error`.

## Prerequisites

* An [Astro project](/docs/cli/v1.43/develop-project#create-an-astro-project).
* An Astro [Deployment](/docs/astro/create-deployment).

## Set up the `KubernetesPodOperator` on Astro

The following snippet is the minimum configuration you'll need to create a `KubernetesPodOperator` task on Astro:

```python wrap theme={null}
from airflow.configuration import conf
from airflow.providers.cncf.kubernetes.operators.pod import KubernetesPodOperator

namespace = conf.get("kubernetes", "NAMESPACE")

KubernetesPodOperator(
    namespace=namespace,
    image="<your-docker-image>",
    cmds=["<commands-for-image>"],
    arguments=["<arguments-for-image>"],
    labels={"<pod-label>": "<label-name>"},
    name="<pod-name>",
    task_id="<task-name>",
    get_logs=True,
    in_cluster=True,
)
```

For each instantiation of the `KubernetesPodOperator`, you must specify the following values:

* `namespace = conf.get("kubernetes", "NAMESPACE")`: Every Deployment runs on its own Kubernetes namespace within a cluster. Information about this namespace can be programmatically imported as long as you set this variable.
* `image`: This is the Docker image that the operator will use to run its defined task, commands, and arguments. Astro assumes that this value is an image tag that's publicly available on [Docker Hub](https://hub.docker.com/). To pull an image from a private registry, see [Pull images from a Private Registry](/docs/astro/kpo-private-registry).
* `in_cluster`: If a Connection object is not passed to the `KubernetesPodOperator`'s `kubernetes_conn_id` parameter, specify `in_cluster=True` to run the task in the Deployment's Astro cluster.

## Related documentation

* [How to use cluster ConfigMaps, Secrets, and Volumes with Pods](https://airflow.apache.org/docs/apache-airflow-providers-cncf-kubernetes/stable/operators.html#how-to-use-cluster-configmaps-secrets-and-volumes-with-pod)
* [`KubernetesPodOperator` Airflow Guide](/docs/learn/kubepod-operator)