Cloud Composer 2长时DAG任务Kubernetes API 401授权错误求助

针对你遇到的长运行DAG（4-6小时）在删除Pod时触发K8s API 401错误的问题，这里有几个可行的解决办法：

1. 拆分Pod启动与删除操作，改用独立任务清理 #

把is_delete_operator_pod设为False，不让启动Pod的任务自己处理删除逻辑，而是新增一个独立的清理任务，在主任务完成后（无论成功失败）执行Pod删除。这样清理任务会使用全新的、有效的K8s令牌，不会复用主任务中已经过期的令牌。

示例代码：

from airflow.providers.google.cloud.operators.kubernetes_engine import GKEStartPodOperator
from airflow.providers.cncf.kubernetes.operators.delete_pod import KubernetesDeletePodOperator
from airflow.utils.trigger_rule import TriggerRule

# 主任务：启动Pod，不自动删除
start_pod_task = GKEStartPodOperator(
    task_id="start_long_running_pod",
    cluster_name="your-gke-cluster",
    namespace="your-namespace",
    name="long-running-pod",
    is_delete_operator_pod=False,
    # 其他必要参数...
)

# 清理任务：删除Pod，无论主任务成功或失败都执行
delete_pod_task = KubernetesDeletePodOperator(
    task_id="delete_long_running_pod",
    name="long-running-pod",
    namespace="your-namespace",
    trigger_rule=TriggerRule.ALL_DONE,
    # 其他必要参数...
)

start_pod_task >> delete_pod_task

2. 配置Airflow强制K8s客户端刷新令牌 #

在Composer 2的环境配置中添加Airflow参数，让Kubernetes客户端在每次API请求前检查令牌状态，过期则自动刷新：

• 进入Composer环境的Airflow配置页面
• 添加自定义配置项：kubernetes.refresh_token_before_request，值设为True

这个配置会强制客户端在执行删除Pod这类操作前，重新获取有效的服务账号令牌，避免使用过期的令牌导致401错误。

3. 临时延长令牌有效期（应急方案） #

如果以上方法暂时无法生效，可以临时延长服务账号令牌的有效期到任务运行时长以上（比如设置为7小时），但不推荐长期使用，因为会降低安全性。操作方式：

• 针对Composer使用的服务账号，创建自定义的ServiceAccount令牌，指定更长的expires_in参数
• 或者AD低She "*ros"视觉略 externcom ，._*通过GCP IAM配置调整对应服务账号的令牌有效期上限

为什么Composer 1没这个问题？ #

Composer 1的工作节点采用传统架构，令牌刷新逻辑由底层平台自动处理；而Composer 2采用更轻量化的工作节点设计，令牌管理依赖Airflow的Kubernetes客户端自行处理，长运行任务中客户端会复用初始获取的令牌，过期后就会触发401错误。

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