6.2. 基础设施即代码：Terraform、Cluster API 与 Crossplane

IaC 不是「把命令写成脚本」，而是把基础设施变成可评审、可版本化、可重复应用的状态。Kubernetes 时代要管三层：云资源、集群生命周期、集群内资源；三层要用不同的工具与状态模型。

层级:: L4 · 实战
难度:: 进阶
预计:: 50 分钟
前置:: 云网络、Kubernetes、Git

6.2.1. 三层 IaC

层	典型工具	管理对象
云基础设施	Terraform/OpenTofu、Pulumi	VPC、子网、IAM、节点池、数据库
集群生命周期	Cluster API、kubeadm、托管服务	控制面、节点、升级、扩缩
集群内资源	Crossplane、Helm、Kustomize、Argo CD	CRD、Operator、应用与策略

不要用 Terraform 管 Kubernetes 里的 Deployment；也不要用 kubectl apply 管云 VPC。边界清晰，状态才可控。

6.2.2. Terraform/OpenTofu 的核心

main.tf

terraform {
  required_version = ">= 1.6"
  backend "s3" {
    bucket = "demo-tfstate"
    key    = "prod/network/terraform.tfstate"
    region = "us-east-1"
  }
}

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  name = "demo-prod"
  cidr = "10.0.0.0/16"
  azs  = ["us-east-1a", "us-east-1b", "us-east-1c"]
}

远程状态：S3/GCS + 锁，禁止本地 state。
模块化：网络、集群、数据库分别模块化，版本固定。
Plan 评审：PR 中展示 plan，合并后才 apply。
漂移检测：定期 plan，发现手工改动。
密钥：用 Vault/SSM，不写进 tfvars。

terraform init
terraform plan -out=tfplan
terraform apply tfplan
terraform state list

6.2.3. Cluster API

Cluster API 用 Kubernetes 对象管理 Kubernetes 集群：Cluster、MachineDeployment、MachineSet。它的价值是「用同一套 GitOps/控制器模式管理多集群生命周期」，适合平台团队。

管理集群（management cluster）运行 CAPI 控制器；
工作负载集群（workload cluster）由 CR 声明；
节点升级、扩缩、故障替换由 Machine 控制器处理；
与云厂商 Provider 结合创建 VM/网络。

6.2.4. Crossplane

Crossplane 把云资源变成 Kubernetes CRD，例如 RDSInstance、Bucket、VPC。平台团队用 Composition 定义「一个数据库 = RDS + 子网组 + 安全组 + Secret」，应用团队只提交一个简化的 Claim。

claim-database.yaml

apiVersion: platform.example.com/v1alpha1
kind: Database
metadata:
  name: orders-db
  namespace: team-orders
spec:
  size: small
  engine: postgres
  storageGB: 50

适用场景：平台团队要给应用团队提供「自助的云资源」，又不想暴露 Terraform。代价是 Crossplane 本身要运维，Provider 版本与云 API 要跟进。

6.2.5. GitOps 管理 IaC

基础设施变更走 Git PR，CI 执行 terraform plan，人工审批后 apply。
集群内资源走 Argo CD/Flux，自动同步。
不要在同一流水线里既 apply 云资源又 apply 应用；拆成独立仓库/环境。

6.2.6. 漂移与回滚

terraform plan 发现漂移时，先判断是「手工热修」还是「配置错误」。
热修要回写代码，否则下次 apply 会被覆盖。
数据库/存储的回滚比应用复杂，变更前要有快照与恢复演练。
基础设施删除要防误操作：prevent_destroy、审批、保护资源。

6.2.7. 实验：Terraform + Argo CD

用 Terraform 创建一个命名空间与 PVC（或本地 kind 集群）。
把 kubeconfig 交给 Argo CD，注册集群。
在 Git 中放一个 Kustomize overlay，Argo CD 同步。
修改 Terraform 的 PVC 大小，观察 plan 与实际差异。
手工改一个资源，观察 Argo CD 的 OutOfSync。

6.2.8. 验证清单

所有基础设施代码在 Git 中，state 在远程后端。
PR 会生成 plan，合并后才 apply。
云资源、集群、应用三层边界清晰。
有漂移检测与手工改动回写流程。
删除/缩容有保护与审批。
密钥不在 tfvars/仓库中。

6.2.9. 排错表

现象	原因	处理
state 锁住	上次 apply 异常退出	确认无进程后 `force-unlock`
plan 显示大量变更	provider 版本/漂移	固定版本，逐项核对
apply 覆盖手工改动	未回写代码	把热修写回 IaC，再 apply
Crossplane 资源不 Ready	Provider 凭证/权限	查 `ProviderConfig` 与事件
CAPI 机器不加入	网络/证书/cloud-init	查 Machine 与 bootstrap 日志