Airflow 1.10.12 Kubernetes Executor出现too old resource version错误导致任务调度异常的问题求助

你遇到的这个kubernetes.client.exceptions.ApiException: (410) Reason: Gone: too old resource version错误，本质是Airflow调度器的Kubernetes客户端与API Server之间的资源版本同步失效了——当调度器长时间运行时，它依赖的资源版本号已经被API Server清理，导致无法继续watch Pod的状态变化，进而出现旧Pod删不掉、新Pod创建失败的情况。结合你提到的"仅定时任务后出现、手动触发正常"的现象，大概率是批量任务运行时调度器负载突增，加剧了资源版本同步的延迟。

下面是几个针对性的解决方案，按优先级排序：

1. 优先升级Airflow版本 #

Airflow 1.10.12是比较老旧的版本（发布于2020年），后续的1.10.x补丁版本（比如1.10.15及以上）以及2.x版本，修复了大量Kubernetes Executor相关的watch机制bug，包括资源版本过期的处理逻辑。升级到稳定的新版本是最彻底的解决办法，还能获得其他性能和安全提升。

2. 调整Kubernetes API Server的资源缓存配置 #

如果暂时无法升级Airflow，可以尝试延长Kubernetes API Server对旧资源版本的保留时长：

• 修改kube-apiserver的启动参数--resource-version-cache-duration，默认是10分钟，可以调整为30分钟甚至1小时（比如--resource-version-cache-duration=30m）
• 同时调整--event-ttl参数，默认是1小时，适当延长可以减少事件清理对资源版本的影响
  注意：这是集群层面的修改，需要和运维团队确认操作可行性，避免影响其他集群应用。

3. 优化Airflow调度器的配置 #

在airflow.cfg中调整以下配置，增强调度器的Kubernetes同步可靠性：

• 缩短调度器心跳间隔：

  scheduler_heartbeat_sec = 10
  

  默认是60秒，缩短后调度器会更频繁地同步Kubernetes资源状态，减少资源版本过期的概率。
• 启用Pod自动清理并配置重试：

  kubernetes_delete_worker_pods = True
  kube_client_request_args = {"_request_timeout": 60, "retries": 5}
  

  增加客户端请求的超时时间和重试次数，提升Pod创建/删除操作的容错性。
• 限制调度器并行度：
  如果定时任务批量运行时负载过高，可以适当降低调度器的并行处理数，避免资源竞争：

  max_threads = 2
  

4. 给调度器配置自动重启的健康检查 #

既然手动删除调度器Pod能临时恢复，不如让Kubernetes自动检测错误并重启：
在调度器的Deployment配置中添加livenessProbe，检测日志中的错误关键词：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: airflow-scheduler
spec:
  template:
    spec:
      containers:
      - name: scheduler
        image: your-airflow-image:1.10.12
        livenessProbe:
          exec:
            command:
            - sh
            - -c
            - "tail -n 100 /var/log/airflow/scheduler.log | grep -q 'too old resource version'"
          initialDelaySeconds: 300
          periodSeconds: 60
          failureThreshold: 2

当连续两次检测到日志中的错误关键词时，Kubernetes会自动重启调度器Pod，无需手动干预。

5. 排查DAG同步Pod的影响 #

你提到DAG通过单独Pod与Git同步，建议检查定时任务运行时段，DAG同步是否会和任务执行高峰重叠，导致调度器CPU/内存负载过高，进而影响Kubernetes客户端的watch连接。可以调整DAG同步的频率（比如避开任务高峰时段），或者增加调度器Pod的资源配额，提升其处理能力。

最后补充下为什么手动触发没问题：手动触发时任务量小，调度器的watch连接能及时同步资源版本，不会出现长时间闲置或负载过高的情况；而定时任务批量运行时，调度器需要处理大量Pod的创建、更新、删除操作，资源版本更新不及时，加上API Server定期清理旧版本，就会触发410错误。

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