EKS环境下EKSPodOperator in_cluster=True与ServiceAccount认证报错求助

问题根源 #

你遇到的核心问题是手动创建的kubernetes_default连接与Airflow集群内默认认证逻辑冲突，同时不必要的aws_default连接也会干扰权限验证流程。Airflow在EKS集群内运行时，默认会通过Pod的ServiceAccount自动完成Kubernetes认证，手动配置连接会触发参数互斥校验。

正确配置步骤 #

1. 清理手动创建的连接 #

删除你之前创建的kubernetes_default和aws_default连接，这些手动配置会覆盖Airflow的默认集群内认证逻辑，导致参数冲突。

2. 确认调度器ServiceAccount的IAM角色配置 #

确保Airflow调度器的ServiceAccount已正确注解IAM角色，并且该角色具备以下权限：

• EKS集群访问权限：允许eks:DescribeCluster动作
• 目标命名空间的Pod管理权限：允许pods/create、pods/delete等Kubernetes API操作
• 若任务需要AWS服务访问权限，添加对应的IAM策略（如S3、ECR等）

注解示例：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: airflow-scheduler
  namespace: airflow
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/airflow-eks-access-role

3. 调整Airflow Helm配置 #

在Helm的values.yaml中确保以下配置，让Airflow自动使用集群内认证：

airflow:
  config:
    core:
      # 禁用示例DAG避免干扰
      load_examples: false
    kubernetes:
      # 无需手动指定kube_config，Airflow会自动用in_cluster模式
      in_cluster: true

4. 编写正确的EKSPodOperator代码 #

在DAG中使用EKSPodOperator时，明确指定in_cluster=True，无需手动指定kubernetes_conn_id（默认即可）：

from airflow import DAG
from airflow.providers.amazon.aws.operators.eks import EKSPodOperator
from datetime import datetime

with DAG(
    dag_id="eks_pod_example",
    start_date=datetime(2024, 1, 1),
    schedule_interval="@daily",
    catchup=False
) as dag:
    run_pod = EKSPodOperator(
        task_id="run_eks_pod",
        cluster_name="your-eks-cluster",
        namespace="airflow",  # 或你指定的目标命名空间
        image="public.ecr.aws/amazonlinux/amazonlinux:2",
        cmds=["echo", "Successfully ran pod via EKSPodOperator"],
        in_cluster=True,
        # 若Pod需要独立IAM角色，指定对应的ServiceAccount
        # service_account_name="eks-pod-sa"
    )

关键说明 #

• 当in_cluster=True时，Airflow会自动使用Pod所在的ServiceAccount的token访问Kubernetes API，无需手动配置kube_config或连接字符串。
• 若需要AWS服务访问，调度器的IAM角色权限会传递给EKSPodOperator创建的Pod（或通过Pod的独立ServiceAccount注解角色实现细粒度权限控制）。
• 避免手动创建kubernetes_default连接，Airflow会自动维护集群内的默认连接配置。

内容的提问来源于stack exchange，提问作者Fidel