升级Google Cloud Composer 2时环境被重建，如何保留原有资源？

我在GCP上使用Google Cloud Composer 2，当前环境版本为composer-2.1.11-airflow-2.4.3，计划升级至最新版本composer-2.3.0-airflow-2.5.1。根据官方文档说明：

当您更改环境使用的Airflow或Cloud Composer版本时，环境会进行升级。升级不会改变您连接环境资源的方式，例如环境存储桶的URL或Airflow网页服务器地址。

但数月前首次尝试升级时，现有环境被删除并重建，Airflow网页地址、GCS存储桶等资源均发生变更。我已分别通过Terraform和GCP控制台UI两种方式操作，均出现此问题。已知该升级功能目前处于Preview阶段，但如果升级必然导致环境重建，该功能将失去实用价值，想了解问题根源。

1. 环境配置存在不可就地升级的限制 #

部分环境配置项会导致Composer无法执行就地升级，只能通过重建环境完成版本更新：

• 网络配置：使用了已废弃的VPC网络模式、共享VPC的旧权限配置，或子网IP地址范围不足导致无法扩容节点；
• 节点池配置：使用了自定义镜像、非官方支持的机器类型，或节点池最小/最大实例数设置不符合升级要求；
• 已废弃功能依赖：环境启用了Composer 2.3版本不再支持的废弃功能（如旧版Airflow插件部署方式）。

2. 版本跨度过大触发强制重建 #

部分大版本升级存在路径限制，直接从composer-2.1.11跳至composer-2.3.0可能超出就地升级的支持范围，需要先升级至中间过渡版本（如composer-2.2.x-airflow-2.4.x系列），再升级至目标版本。

3. Terraform配置或状态异常 #

如果使用Terraform操作，以下情况可能导致环境被重建而非升级：

• Terraform代码中google_composer_environment资源的核心配置项（如config.dag_gcs_prefix、config.node_config）同时发生变更，触发Terraform的资源替换逻辑；
• Terraform状态文件与实际GCP环境状态不一致，导致Terraform误判需要重建资源；
• 未正确使用Composer版本升级的Terraform配置方式，例如直接替换版本号但未保留原有资源依赖配置。

4. Preview阶段功能bug #

由于Composer 2的版本升级功能仍处于Preview阶段，部分特定版本组合或环境场景下可能存在未修复的bug，导致就地升级逻辑失效，触发环境重建。

1. 查看升级操作日志：在GCP控制台的Composer环境详情页，进入“操作”标签，查看升级过程的详细日志，日志中通常会明确说明是否因配置限制触发环境重建。
2. 核对官方升级矩阵：确认composer-2.1.11到composer-2.3.0是否支持直接就地升级，若存在版本跳跃限制，先升级至中间过渡版本。
3. 检查环境配置合规性：移除自定义镜像、废弃功能依赖，调整网络/节点池配置至官方推荐的支持升级的参数范围。
4. 验证Terraform配置：确保仅修改config.version字段，未变更其他核心配置；执行terraform plan查看输出，确认是否存在资源替换的提示，排查状态文件异常。
5. 提交GCP支持工单：若以上排查均无结果，向GCP技术支持提交工单，提供环境ID、升级操作记录及日志，请求官方排查Preview功能的潜在问题。

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