To launch Pods in external clusters from a local Airflow environment, you must have valid authentication for the external cluster. For managed Kubernetes services from public cloud providers, authentication is federated through the native IAM service. To grant the Astro role permissions to launch Pods on your cluster, you can either include static credentials or use workload identity to authorize the Astro role to your cluster.
Prerequisites
- Network connectivity between your Airflow execution environment and the external Kubernetes cluster:
- Hosted execution mode: A network connection between your Astro Deployment and the external cluster.
- Remote execution mode: Network connectivity between the environment where your Remote Execution Agent runs and the external cluster. You are responsible for managing this connectivity. A direct network connection between Astro and the external cluster isn’t required.
Setup
1
Set up your external GKE cluster
Follow Google Cloud’s documentation to prepare a GKE cluster that your Astro Deployment can authenticate to:
- Create a GKE cluster if you don’t already have one.
- Authorize your Astro Deployment to Google Cloud by following the Deployment workload identity setup.
-
Grant the service account IAM and Kubernetes RBAC permissions in the namespace where your
KubernetesPodOperatortasks run. At a minimum, provision the following permissions for your service account in your specified namespace:container.clusters.getcontainer.events.listcontainer.pods.getcontainer.pods.getLogscontainer.pods.listcontainer.pods.createcontainer.pods.deletecontainer.pods.update
do_xcom_push=True, also grant thecontainer.pods.execpermission.
2
Install dependencies in your Astro Runtime Docker image
To connect to your external GKE cluster, the For production deployments, consider pinning the
gcloud CLI and the gke-gcloud-auth-plugin must be available inside your Astro Runtime image.Add the following to your Dockerfile:Dockerfile
google-cloud-cli-gke-gcloud-auth-plugin version for build reproducibility, or using a multi-stage build with the google/cloud-sdk:slim image to copy only the plugin binary into your final image and reduce its size.Add the following line to your requirements.txt to include the CNCF Kubernetes provider:requirements.txt
3
Configure your `kubeconfig` file
The following sample Kubernetes Fetch the
kubeconfig file allows the Kubernetes command-line tool, kubectl, or other clients to connect to a remote Kubernetes cluster using Google Cloud workload identity for authentication.kubeconfig
certificate-authority-data and cluster-endpoint fields from the GKE cluster details page or using the Google Cloud SDK.Scaling considerationsIf you run a high number of concurrently deferred tasks against this connection, consider a static bearer token instead of the exec-based plugin shown in the preceding
kubeconfig. At high triggerer concurrency, the plugin’s subprocess invocation on each credential refresh can block the triggerer’s shared event loop.4
Create an Airflow connection to use the `kubeconfig` file
To use the
kubeconfig file, create a new Kubernetes Airflow connection.There are multiple ways to pass the kubeconfig file to your Airflow connection. If your kubeconfig file contains any sensitive information, Astronomer recommends storing it as JSON inside the connection, as described in the JSON format tab.- JSON format (Recommended)
- External file in the default location
- External file with a custom path
Convert the
kubeconfig file to JSON format and paste it into the Kube config (JSON format) field in the connection configuration.5
Configure your task
In your
KubernetesPodOperator task, set kubernetes_conn_id to the connection you created, namespace to the namespace in your GKE cluster where the Pod should run, and in_cluster=False so that the operator uses the connection’s kubeconfig instead of looking for an in-cluster service account.