Add KubernetesPodExecOperator for existing Kubernetes Pods

[AlejandroMorgante]

Add KubernetesPodExecOperator to execute commands in a running container of an existing Kubernetes Pod without creating, restarting, or deleting it. This supports pre-warmed and API-visible static Pods where avoiding startup latency is important.

The operator validates the target Pod and container, streams stdout and stderr, supports optional stdout XCom, reports non-zero exit codes, and closes the exec connection when the task is killed. Provider metadata, RBAC guidance, and operator documentation are included.

Tests:

• pytest providers/cncf/kubernetes/tests/unit/cncf/kubernetes/operators/test_pod_exec.py -q (32 passed)
• Provider mypy check
• Provider metadata and documentation validation
• Pre-commit and manual checks

---

Was generative AI tooling used to co-author this PR?

• Yes — Codex (GPT-5)

Generated-by: Codex (GPT-5) following the guidelines

[kaxil]

Add KubernetesPodExecOperator to execute commands in a running container of an existing Kubernetes Pod without creating, restarting, or deleting it. This supports pre-warmed and API-visible static Pods where avoiding startup latency is important.

The operator validates the target Pod and container, streams stdout and stderr, supports optional stdout XCom, reports non-zero exit codes, and closes the exec connection when the task is killed. Provider metadata, RBAC guidance, and operator documentation are included.

Tests:

• pytest providers/cncf/kubernetes/tests/unit/cncf/kubernetes/operators/test_pod_exec.py -q (32 passed)
• Provider mypy check
• Provider metadata and documentation validation
• Pre-commit and manual checks

Was generative AI tooling used to co-author this PR?

• Yes — Codex (GPT-5)

Generated-by: Codex (GPT-5) following the guidelines

What's the User story and real-world use cases for this?

[AlejandroMorgante]

@kaxil

What's the User story and real-world use cases for this?

Thanks for asking. The user story is:

As an Airflow user who already manages a long-running Kubernetes Pod, I want to execute commands in one
of its containers as Airflow tasks, without Airflow creating, restarting, or deleting that Pod.

Our concrete use case is running dbt on EKS. Today, our workflow starts a new Pod, initializes the dbt project and its dependencies, and then executes a command such as dbt run. A significant part of the execution time is spent scheduling the Pod and initializing the environment.

We want to manage that Pod separately and keep it warm, then use Airflow to execute ad hoc commands such as dbt run, dbt test, or dbt build. This avoids the repeated cold-start and initialization cost.

More generally, this is useful whenever a Pod’s lifecycle is managed outside the task and its environment is already initialized. The operator exposes the equivalent of kubectl exec as an Airflow task, including Airflow logging and optional XCom output, without assuming ownership of the Pod lifecycle.