Terraform vs Helm

这一课你将能做到

1. 说清楚 Terraform 和 Helm 各自管理的对象、抽象层级和变更模型
2. 在 Terraform 中通过 helm_release 引导安装 chart，并划清后续升级归谁
3. 面对一套真实架构，能给出「哪些东西给 Terraform、哪些给 Helm/GitOps」的分工方案

为什么要学

这是云原生岗位面试和实际项目设计中反复出现的问题。两个工具都能往 Kubernetes 集群里「创建东西」，初学者很容易困惑：既然 Terraform 有 Helm Provider，是不是所有 chart 都 Terraform 一把梭？或者既然 Helm 能装一切，还要 Terraform 干什么？答错边界，轻则发布流程别扭、升级靠人肉，重则两套系统同时操作同一批对象，状态互相打架。这一课把职责边界讲死，并给出混合架构的标准接线。

人话：Terraform 是管「地基和大楼结构」的，一次改动要稳、要审批、频率低；Helm 是管「楼里的家具和租户配置」的，应用每周发版都用它。让地基施工队每天帮你挪沙发，双方都难受。

先建立图像

对比表：

维度	Terraform	Helm
管理对象	云资源、集群、集群级对象	K8s 应用的一组 YAML（chart 包）
抽象	资源 + 依赖图 + state	模板 + values 参数 + release 版本
变更频率	低（基础设施周/月级）	高（应用日/周级发版）
回滚	反向 plan（destroy/recreate）	helm rollback 秒级切版本
状态存放	state（本地/S3）	Secret/ConfigMap（集群内 release 记录）
最擅长	「存在性」与生命周期	「安装、升级、回滚」应用包

推荐的三层分工：

Terraform      云网络 + EKS 集群 + 节点组 + 集群插件底座
Helm（经 Terraform 引导或独立）  平台组件：ingress-nginx、cert-manager、metrics-server
Helm / GitOps  业务应用：Spring Boot 各服务（高频升级走这里）

跟着做

步骤 1：声明两个 provider

versions.tf：

terraform {
  required_version = ">= 1.7.0"

  required_providers {
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 2.25"
    }
    helm = {
      source  = "hashicorp/helm"
      version = "~> 2.12"
    }
  }
}

providers.tf：

provider "kubernetes" {
  config_path = "${pathexpand("~/.kube/config")}"
}

provider "helm" {
  kubernetes {
    config_path = "${pathexpand("~/.kube/config")}"
  }
}

执行 terraform init。

步骤 2：用 helm_release 安装平台组件

main.tf：

resource "kubernetes_namespace" "ingress" {
  metadata {
    name = "ingress-nginx"
  }
}

resource "helm_release" "ingress_nginx" {
  name       = "ingress-nginx"
  repository = "https://kubernetes.github.io/ingress-nginx"
  chart      = "ingress-nginx"
  version    = "4.10.0"
  namespace  = kubernetes_namespace.ingress.metadata[0].name

  values = [
    <<-EOT
    controller:
      service:
        type: ClusterIP
      replicaCount: 2
    EOT
  ]
}