GCP Composer：如何在Compute Engine中通过gcloud命令删除DAG并解决相关报错

• delete_dag命令报Invalid choice的核心原因是参数位置放错了
  之前的命令把delete_dag放在了双破折号--的前面，这部分内容会被gcloud当成自身的内置参数解析，而gcloud本身没有名为delete_dag的可选参数，才会提示无效选择，反过来问你是不是要调用内置的list_dags选项。
  实际上gcloud composer environments run的规则非常明确：双破折号是gcloud自身配置参数、和要透传给Airflow的参数的分隔符，所有需要在Composer环境里执行的Airflow命令、配套参数，必须全部放在双破折号之后，才会被正确转发到Airflow服务执行。
• kubectl安装报错的核心原因是当前实例上的Cloud SDK是通过系统级包管理器（apt/yum等）托管安装的，这类安装方式会主动禁用gcloud自带的组件安装能力，避免手动安装的组件和系统包管理器管理的版本产生冲突，所以直接执行gcloud components install会被系统拦截。

1. 先修正delete_dag的命令结构，正确的可执行命令为：
   gcloud composer environments run --location us-central1 my-composer-instance -- delete_dag my_dag_id
   调整后gcloud会正确识别双破折号之后的透传内容，不会再触发Invalid choice的参数报错。
2. 解决kubectl依赖问题，按优先级选以下方案：
   • 首选方案：通过系统包管理器安装和Composer环境匹配版本的kubectl
     gcloud composer environments run 底层是通过kubectl连接Composer关联的GKE集群，在运行Airflow的Pod里执行命令，对kubectl版本有严格匹配要求：首先通过gcloud composer environments describe my-composer-instance --location us-central1 --format="value(config.gkeCluster)"拿到关联的GKE集群标识，查询对应集群的服务端版本，再通过系统对应的包管理源安装和该版本匹配的kubectl包，完全绕开gcloud组件安装的限制，也不会和系统托管的Cloud SDK产生冲突。
   • 备选方案：单独在用户目录安装独立的Cloud SDK
     下载官方独立安装包，安装到当前用户的家目录下，调整系统PATH顺序让独立安装的SDK优先于系统托管的SDK，之后就可以正常执行gcloud components install kubectl，不受外部包管理器的限制。
   • 零本地依赖方案：直接调用Airflow REST API删除DAG
     不需要本地安装kubectl组件，先通过describe命令拿到Composer环境的Web Server地址，用具备Composer编辑权限的账号生成访问凭证，直接调用Airflow的DAG删除接口传入目标dag_id，即可完成删除操作，完全绕开本地命令行的依赖要求。

• 执行delete_dag操作前，要确认目标dag_id没有处于运行状态的Task实例，否则删除操作会被Airflow拦截失败。
• 安装kubectl时，要保证版本和关联GKE集群的版本差不超过1个小版本，否则会触发K8s API的版本不兼容报错。

内容的提问来源于stack exchange，提问作者ACHO-Chen