Registry /
workflow / apache-airflow-providers-cncf-kubernetes
Install & Compatibility
Where this runs
tested against v10.21.1 · pip install
no network on importno background threads
Install × environment matrix
Each cell = how many times install + import succeeded across repeated harness runs. Partial = flaky.
glibc = Debian/Ubuntu slim · musl = Alpine Linux
muslpy 3.10–3.95 runs
installs and imports cleanly · install 0.0s · import 7.982s · 388.8MB
glibcpy 3.10–3.95 runs
installs and imports cleanly · install 31.6s · import 7.346s · 389MB
386MB installed
● package 386MB
Code
Verified usage
Verified import paths — ran on the pinned version, not inferred.
KubernetesPodOperator
✓ from airflow.providers.cncf.kubernetes.operators.pod import KubernetesPodOperator
✗ from airflow.providers.cncf.kubernetes.operators.kubernetes_pod import KubernetesPodOperator
This quickstart demonstrates a basic Airflow DAG using the `KubernetesPodOperator` to launch a simple Ubuntu pod that executes a 'hello world' command. The pod runs in the 'default' Kubernetes namespace and is configured to be deleted upon task completion. Ensure your Airflow environment has access to a Kubernetes cluster and the necessary permissions to create pods in the specified namespace.
from __future__ import annotations
import pendulum
from airflow.models.dag import DAG
from airflow.providers.cncf.kubernetes.operators.kubernetes_pod import KubernetesPodOperator
with DAG(
dag_id='kubernetes_pod_example',
schedule=None,
start_date=pendulum.datetime(2023, 1, 1, tz='UTC'),
catchup=False,
tags=['kubernetes', 'example'],
) as dag:
start_pod_task = KubernetesPodOperator(
task_id='start_pod_task',
namespace='default',
name='my-custom-pod',
image='ubuntu:latest',
cmds=['bash', '-cx'],
arguments=['echo', 'Hello from KubernetesPodOperator!'],
do_xcom_push=False, # Set to True to enable XCom pushing from the pod
is_delete_operator_pod=True, # Pod is deleted upon completion or failure
# Optional: Specify a Kubernetes connection ID for custom client config
# kubernetes_conn_id='my_kubernetes_connection',
# To access Airflow variables or connections inside the Pod,
# ensure your Airflow service account has necessary permissions.
# E.g., for in-cluster auth, configure service account token mount.
)
airflow --version
Debug
Known issues
breakingThe `KubernetesPodOperator` no longer supports configuring the Kubernetes client via settings in `airflow.cfg`'s `kubernetes` section. Instead, all client-related configurations must be defined explicitly in an Airflow connection and then referenced using the `kubernetes_conn_id` parameter in the operator. This change was deprecated in provider version 4.1.0 and fully removed in later versions.fixMigrate Kubernetes client configurations from `airflow.cfg` to an Airflow connection of type 'Kubernetes' and specify `kubernetes_conn_id` in your `KubernetesPodOperator` tasks.
affects: >=4.1.0
breakingDirect dictionary-based resource definitions in `KubernetesPodOperator` are deprecated and no longer supported. The `resource` parameter should be replaced with `container_resources` using `kubernetes.client.V1ResourceRequirements` objects for specifying CPU/memory requests and limits.fixRefactor your `KubernetesPodOperator` tasks to use `container_resources` with proper `kubernetes.client.V1ResourceRequirements` objects instead of dicts for resource specification.
affects: >=4.0.0
breakingProvider versions are tied to specific minimum Airflow core versions and `kubernetes` client library versions. For example, provider `10.14.0` requires `apache-airflow>=2.11.0` and `kubernetes>=35.0.0,<36.0.0`. Installing a newer provider with an older Airflow or conflicting `kubernetes` client versions can lead to `ImportError` or `TypeError` due to API changes.fixAlways check the provider's `Requirements` section in its documentation or PyPI page (e.g., `pip install apache-airflow-providers-cncf-kubernetes==X.Y.Z` and verify dependency resolution). Ensure your Airflow installation meets the minimum version, and address any `kubernetes` client version conflicts by adjusting your `pip` dependencies or using virtual environments.
affects: All versions
deprecatedThe import path `airflow.providers.cncf.kubernetes.operators.kubernetes_pod` was deprecated. Using this path will cause `ImportError` in recent provider versions.fixUpdate import statements from `from airflow.providers.cncf.kubernetes.operators.kubernetes_pod import KubernetesPodOperator` to `from airflow.providers.cncf.kubernetes.operators.kubernetes_pod import KubernetesPodOperator`. Note the subtle difference in the last part of the path (the original was `operators.kubernetes_pod` directly, now it's still `operators.kubernetes_pod`). This seems like a common user mistake where they might have used an older, perhaps internal, or `contrib` module structure that was then removed, and the correct path is the one listed in 'correct' import section. A more precise warning refers to the *removal* of old backcompat objects/paths.
affects: Recent major versions (e.g., after 10.0.0, based on reported issues)
gotchaThe default value for the `is_delete_operator_pod` parameter in `KubernetesPodOperator` changed in provider version 3.0.0. If not explicitly set, this can alter the lifecycle of the Kubernetes Pods launched by your tasks, potentially leaving completed pods running or deleting them unexpectedly.fixAlways explicitly set `is_delete_operator_pod` to `True` or `False` based on your desired pod cleanup behavior, rather than relying on its default value.
affects: >=3.0.0
Upgrade
Version history
10.21.1latest on PyPI · released Aug 23, 2026
Audit
Dependencies
apache-airflowrequiredCore Airflow installation required to use the provider. Specific minimum version depends on provider version (e.g., >=2.11.0 for provider 10.14.0).
kubernetesrequiredPython client for Kubernetes API interaction. Version is tightly coupled with the provider.
kubernetes_asynciorequiredAsynchronous Python client for Kubernetes API interaction.