Kubernetes环境下Airflow scheduler如何配置使用自定义ServiceAccount

以下分三种常见场景给出对应配置方法：

1. 原生Kubernetes YAML部署场景 #

直接修改运行webserver和scheduler的Pod的spec字段，新增/修改serviceAccountName配置，值为你提前创建的有权限的自定义ServiceAccount名称：

apiVersion: v1
kind: Pod
metadata:
  name: airflow-core
  namespace: <你的部署命名空间>
spec:
  # 核心配置：指定自定义ServiceAccount
  serviceAccountName: <你创建的自定义SA名称>
  containers:
  - name: webserver
    image: apache/airflow:<你的Airflow镜像版本>
    # 其余webserver原有配置保持不变
  - name: scheduler
    image: apache/airflow:<你的Airflow镜像版本>
    # 其余scheduler原有配置保持不变
# 其余原有配置保持不变

注意：由于你的webserver和scheduler运行在同一个Pod内，Pod级别的ServiceAccount配置会对两个容器同时生效，无需单独为scheduler容器指定。请确保你创建的自定义ServiceAccount和Airflow部署在同一个Kubernetes命名空间下，否则需要额外配置跨命名空间权限。

2. 官方Airflow Helm Chart部署场景 #

修改你使用的values.yaml配置文件，调整scheduler对应的ServiceAccount配置：

scheduler:
  serviceAccount:
    # 关闭自动创建SA，使用你提前创建的自定义SA
    create: false
    # 填写你已创建的自定义SA名称
    name: <你的自定义SA名称>

如果需要全局统一ServiceAccount配置，可同步修改全局配置段：

serviceAccount:
  create: false
  name: <你的自定义SA名称>

3. KubernetesExecutor专属补充配置 #

因为你使用了KubernetesExecutor，还可以根据业务需求配置任务运行时Worker Pod使用的ServiceAccount，配置方式如下：

配置文件airflow.cfg方式 #

[kubernetes]
worker_service_account_name = <Worker使用的SA名称，可与调度器SA一致>

环境变量注入方式 #

AIRFLOW__KUBERNETES__WORKER_SERVICE_ACCOUNT_NAME=<你的SA名称>

配置生效验证 #

更新配置重启Airflow核心Pod后，执行以下命令确认Pod使用的SA是否符合预期：
kubectl get pod <airflow核心Pod名称> -n <部署命名空间> -o jsonpath='{.spec.serviceAccountName}'
输出为你指定的自定义SA名称即为配置生效。

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