更新killed_task_cleanup_time后Google Composer Airflow配置覆盖引发故障

以下是导致该异常的常见原因：

• 配置覆盖格式错误引发的组件启动失败
  killed_task_cleanup_time属于Airflow的scheduler配置段，若在Composer控制台填写配置时出现段名拼写错误、参数值类型非法（如填写非整数、错误时间单位），会直接导致scheduler、worker组件启动失败。即使后续回退配置，若Composer的配置同步进程出现卡顿，错误配置无法完全清理，会一直阻塞组件正常启动。
• Airflow元数据库异常
  配置变更触发所有Airflow组件滚动重启时，若存在运行中的调度任务，可能导致Composer托管的Airflow元数据库出现锁表、配置数据写入不一致的问题。scheduler无法从元数据库拉取DAG列表，worker无法连接元数据库完成节点注册，最终表现为DAG列表为空、无运行中worker。
• 底层GKE集群资源耗尽
  Composer底层运行在GKE集群上，配置变更触发的组件滚动更新需要额外的临时资源完成pod的销毁重建。若GKE节点池未开启自动扩容、或者集群CPU/内存/IP配额耗尽，新的scheduler、worker pod无法完成调度，旧pod已经被销毁，就会出现长时间无可用worker的情况，普通的Composer重启操作无法解决该类底层资源问题。
• Celery Broker状态异常
  若使用的是Celery Executor模式的Composer环境，错误配置导致worker异常退出后，可能在托管的Redis Broker中残留无效的worker注册信息、异常队列数据，回退配置后新启动的worker无法正常注册到Broker，也会出现无可用worker、scheduler不扫描DAG的问题。

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