4. 基础设施即代码基础

平台工程的核心目标之一，是让基础设施的创建、变更和回收像应用代码一样可审查、可复现、可回滚。基础设施即代码（Infrastructure as Code，IaC）正是实现这一目标的基础手段。在 Google Cloud 上，Terraform 与 Config Connector 是两条最常用的声明式路径：前者以独立的 IaC 工具身份管理跨云资源，后者以 Kubernetes 控制器的方式把 Google Cloud 资源纳入集群的声明式模型。理解两者的定位差异，并掌握 Terraform 的基本工作流，是平台团队构建可重复部署能力的第一步。

声明式管理的本质：描述目标状态，而非执行步骤

传统脚本式运维通过一串命令按顺序创建资源，一旦中途失败或重复执行，状态就容易漂移。声明式 IaC 则要求我们只描述“最终要有什么”，由工具负责计算当前状态与目标状态的差异，并生成执行计划。Terraform 通过 terraform plan 展示差异，通过 terraform apply 收敛状态；Config Connector 则通过 Kubernetes 的 reconcile 循环持续把实际资源调整到 YAML 声明的期望状态。两者都依赖一个“状态”概念：Terraform 把状态保存在 state 文件中，Config Connector 把状态保存在 Kubernetes 对象的 status 字段中。

这种模式带来的直接收益是：资源定义可以进入 Git 仓库，变更可以走代码评审，环境可以按同一份定义重复创建。对于平台团队而言，这意味着开发、测试、生产三套环境不再靠人工记忆和手工点击来保持一致。

Terraform 与 Config Connector 的定位对比

选择哪条路径，取决于团队已有的工作流和资源边界。Terraform 适合管理项目、VPC、IAM、GKE 集群等“集群之前”或“跨系统”的资源，它的 provider 生态成熟，支持多云和多种后端。Config Connector 适合把 Google Cloud 资源（如 Pub/Sub Topic、Cloud SQL 实例、Service Account）作为 Kubernetes 自定义资源来管理，让已经以 Kubernetes 为中心的团队用同一套 GitOps 流水线管理应用与云资源。

一个常见的组合策略是：用 Terraform 创建项目、启用 API、建立 VPC 与 GKE 集群，再用 Config Connector 在集群内声明式地创建数据库、消息队列和 IAM 绑定。这样既保留了 Terraform 对底层基础设施的强控制，又让上层资源享受 Kubernetes 的持续调谐能力。

Terraform 基本工作流与关键文件

一个最小可用的 Terraform 配置通常包含三个部分：provider 声明、资源定义和变量。以下示例用于在指定项目中创建一个 VPC 网络和一个子网，参数均为教学示例值，实际使用时需替换为真实项目 ID 和区域。

# main.tf
terraform {
  required_version = ">= 1.5.0"
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
  }
  backend "gcs" {
    bucket = "my-tf-state-bucket"
    prefix = "network/dev"
  }
}

provider "google" {
  project = var.project_id
  region  = "asia-east1"
}

resource "google_compute_network" "vpc" {
  name                    = "platform-vpc"
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "subnet" {
  name          = "platform-subnet"
  ip_cidr_range = "10.10.0.0/24"
  region        = "asia-east1"
  network       = google_compute_network.vpc.id
}

variable "project_id" {
  type        = string
  description = "目标 Google Cloud 项目 ID"
}

执行顺序为：terraform init 初始化 provider 和后端；terraform plan -var="project_id=my-demo-project" 预览将要创建的资源；确认无误后执行 terraform apply。plan 输出中会明确列出 + google_compute_network.vpc 等新增项，apply 完成后 state 文件中会记录资源 ID 和属性。若需要销毁，使用 terraform destroy，它会依据 state 反向删除资源。

Config Connector 的声明式资源示例

Config Connector 安装到 GKE 集群后，会注册一批以 cnrm.cloud.google.com 为 API 组的自定义资源。下面是一个 Pub/Sub Topic 的 YAML 示例，它和普通 Kubernetes 对象一样通过 kubectl apply 提交：

apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
kind: PubSubTopic
metadata:
  name: platform-events
  namespace: platform-system
spec:
  projectRef:
    external: my-demo-project

提交后，Config Connector 控制器会调用 Google Cloud API 创建对应 Topic，并把实际状态写回对象的 status 字段。如果 Topic 被外部误删，控制器会在下一次调谐中重新创建它，这正是声明式持续调谐的价值。需要注意的是，Config Connector 要求集群启用 Workload Identity，并通过 GCP service account 授予必要的 IAM 权限，否则资源会停留在 Ready=False 状态。

可重复部署的关键实践

要让同一份定义在多个环境中稳定复现，需要关注以下几点。第一，用变量和 terraform.tfvars 区分环境差异，而不是复制多份配置。第二，为每个环境使用独立的 state 前缀，例如 network/dev 与 network/prod，避免相互覆盖。第三，把 plan 结果纳入 CI 流水线，在合并前展示变更摘要，防止意外删除。第四，对 Config Connector 资源使用命名空间隔离，并按团队划分 IAM 权限。

判断部署是否达成目标，可以观察三个信号：Terraform apply 输出中 Apply complete! Resources: N added, 0 changed, 0 destroyed；Config Connector 对象 kubectl get pubsubtopic -n platform-system 显示 Ready=True；以及在 Cloud Console 中确认资源确实存在且属性与声明一致。若 plan 反复出现同一变更，通常说明配置中存在无法收敛的字段或外部手动修改，需要回到代码中修正声明，而不是在控制台上直接改资源。

掌握以上基础后，平台团队就可以把“创建一套可用的 GCP 环境”从一次性手工操作，转变为可评审、可重复、可回滚的代码流程。这是后续构建开发者自助服务门户和黄金路径的前提。