You'll see K8s API error for the wrong namespace. In my case, the KPO decorator is trying to access the airflow namespace despite the pod is running in the correct namespace
HTTP response body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"pods is forbidden: User \"system:serviceaccount:airflow:airflow\" cannot list resource \"pods\" in API group \"\" in the namespace \"airflow\"","reason":"Forbidden","details":{"kind":"pods"},"code":403}
Apache Airflow version
Other Airflow 2 version (please specify below)
If "Other Airflow 2 version" selected, which one?
2.9.2
What happened?
Given these settings for KuberneteseExecutor:
the behavior of
@task.kubernetes()
vsKubernetesOperator()
when not setting namespace differs:@task.kubernetes()
defaults tonamespace="default"
KuberntesPodOperator()
defaults tonamespace=None
which uses the cluster namespace whenin_cluster
is true.What you think should happen instead?
KubernetesPodOperator
and@task.kubernetes
should use the in-cluster namespace by default (i.e., the worker pod's namespace).How to reproduce
default
, let's call itfoobar
for this examplefoobar
namespace.Run this DAG
You'll see K8s API error for the wrong namespace. In my case, the KPO decorator is trying to access the
airflow
namespace despite the pod is running in the correct namespaceHere's the KPO decorator task's pod spec:
Operating System
Amazon Linux 2
Versions of Apache Airflow Providers
apache-airflow-providers-cncf-kubernetes==7.14.0
Deployment
Other 3rd-party Helm chart
Deployment details
No response
Anything else?
No response
Are you willing to submit PR?
Code of Conduct