Terraform Google Cloud 8.0 发布：默认负载均衡行为变更引发破坏性升级

一句话结论

Terraform Google Cloud Provider 8.0 修改默认负载均衡方案并移除旧资源，导致依赖旧行为的配置需强制显式声明，实施破坏性升级。

关键要点

`google_compute_backend_service` 与 `google_compute_global_forwarding_rule` 的默认 `load-balancing-_scheme` 由 `EXTERNAL` 改为 `EXTERNAL_MANAGED`。
移除 `google_iap_brand`、`google_notebooks_*`、`google_ml_engine_model` 等依赖已退役服务的资源及数据源。
将 Compute Service Attachments、GKE 日志监控配置等无顺序语义属性的列表类型改为集合，以消除永久性 Diff。
`google_workflows_workflow` 强制要求提供 `source_contents`；SCIM 租户创建强制要求 `claim_mapping`，API 验证规则收紧。
新增 Terraform 列表资源支持、Resource Identity 扩展及敏感值只写属性（Write-Only Attributes）功能。

背景与事实

HashiCorp 宣布 Terraform Google Cloud Provider 8.0 正式发布，该版本在 Terraform Registry 中提供，由 Google Cloud 工程团队、HashiCorp 及社区共同开发。此次重大版本更新核心旨在解决长期存在的“永久性 Diff”问题，通过改变资源默认行为、数据类型及移除废弃组件，重构了 Google Cloud 基础设施管理的底层逻辑。

最显著的行为变更集中在计算资源负载均衡上。`google_compute_backend_service` 和 `google_compute_global_forwarding_rule` 的默认负载均衡方案已从经典的 `EXTERNAL` 切换为 `EXTERNAL_MANAGED`。这意味着，任何未显式配置 `load_balancing_scheme` 字段的 Terraform 资源，现在将默认使用新的外部应用负载均衡器，而非旧版经典负载均衡器。对于依赖默认值继承经典行为的团队，若不修改代码，Terraform 计划将提示修改现有资源，导致潜在的流量中断或配置漂移。

资源清理方面，Provider 8.0 移除了多个关联 Google Cloud 已退役或替代服务的对象。具体包括：IAP OAuth Admin API 关闭后移除的 `google_iap_brand` 和 `google_iap_client`；三个 `google_notebooks_*` 资源，用户需迁移至 `google_workbench_instance`；`google_ml_engine_model`；以及被 Security Gateway 资源替代的 BeyondCorp 应用连接、连接器和网关资源。此外，`google_vertex_ai_schedule` 也被 `google_colab_schedule` 替代。升级前必须清除代码中所有对这些已移除资源的引用，否则将导致编译或应用失败。

在 Schema 数据结构上，不具备顺序语义的属性已从列表（List）改为集合（Set）。涉及范围包括 Compute Service Attachments、GKE 日志和监控配置、Cloud Security Compliance Frameworks 中的字段。此举旨在防止 API 返回顺序与配置顺序不一致导致的持续计划差异。同时，API 验证规则更加严格：`google_workflows_workflow` 现在必须提供 `source_contents`；创建 Workforce Identity Pool Provider SCIM 租户时，必须提供 `claim_mapping`。部分状态变化如整数转字符串会自动迁移，但其他类型变化需手动修改配置。

影响分析

对于中文开发者与云从业者而言，此次升级并非简单的版本迭代，而是一次强制性的基础设施代码重构。直接的影响是“隐性依赖”的失效：过去依靠默认值运行的负载均衡配置，现在必须显式声明 `EXTERNAL` 才能保持原有行为。这要求团队在执行升级前，必须对所有 Google Cloud 相关模块进行全量扫描，重点排查未设置负载均衡方案的资源。若忽略此步骤，生产环境的 `terraform apply` 可能会触发非预期的资源替换或规格变更，带来运维风险。

其次，资源移除对使用旧版 Google Cloud 服务（如 Notebooks、IAP Brand）的团队构成阻断性障碍。使用者必须在升级到 8.0 之前，完成向 `google_workbench_instance`、Security Gateway 等新服务的业务迁移。若仍依赖已移除资源，升级将直接失败。此外，列表转集合的类型变更可能影响依赖顺序的逻辑代码（尽管 Provider 设计意图是消除顺序语义，但若有代码依赖列表索引特性，需仔细审查）。对于使用 OpenTofu 的团队，虽然大部分功能可用，但 Terraform 查询工作流和 Resource Identity 的兼容性存在缺失或待确认状态，需根据 OpenTofu 版本（只写属性需 1.11+）单独验证，不能直接复用 Terraform 的升级路径。

适用边界

该结论主要适用于使用 Terraform 管理 Google Cloud 基础设施的团队。若团队完全未使用 Terraform，或使用其他 IAC 工具（如 Pulumi、CDKTF 但不基于该 Provider 包），则不受此特定 Provider 版本更新影响。对于仍锁定在 7.x 版本且计划长期不升级的团队，可暂时维持现状，但需注意 Google Cloud 底层服务的退役时间表，最终仍需面对迁移。若代码中已完全显式声明所有负载均衡属性，且未使用已移除资源，升级 8.0 的破坏性影响将显著降低，但仍需验证列表转集合对边缘逻辑的影响。OpenTofu 用户若不使用只写属性、Resource Identity 或 Terraform 查询功能，且版本满足 OpenTofu 1.11+，大部分功能可平滑过渡，但需注意 Provider 内部逻辑变更对非 Terraform CLI 的全局生效性。