别再手搓集群了：用 Terraform + Helm 把数据平台“养成宠物”变“放养牛群”

别再手搓集群了：用 Terraform + Helm 把数据平台“养成宠物”变“放养牛群”

大家有没有这种经历：
一开始搞大数据平台，三台机器起步，手动装个 Hadoop、Spark，美滋滋。
半年后，业务一上来，环境变成：dev / test / staging / prod 四套，配置还不一样。
再过半年——你已经不敢动生产环境了。

说白了，这就是典型的“手工运维 -> 配置失控 -> 无法复现 -> 不敢改动”四连击。

今天咱聊点实在的：怎么用 Terraform + Helm，把数据平台基础设施变成“可复制、可回滚、可版本化”的工程化系统。

一、核心认知：基础设施不是“环境”，而是“代码”

很多人用 Terraform，只停留在“创建云资源”；用 Helm，只是“部署个 chart”。
但真正的关键是一个理念：

基础设施 = 可审计、可回滚、可复现的代码资产

换句话说，你的数据平台应该满足：

• 一键重建（灾备能力）
• 多环境一致（避免“测试能跑，生产爆炸”）
• 变更可追踪（Git 就是审计系统）

二、一个典型架构（你大概率就是这么玩的）

先看个标准组合：

Terraform: - VPC / 子网 / 安全组 - Kubernetes 集群（EKS / ACK / GKE） - 存储（S3 / OSS / HDFS） Helm: - Spark / Flink - Kafka / Pulsar - Airflow / DolphinScheduler - Prometheus + Grafana

简单说：

👉 Terraform 负责“地基”
👉 Helm 负责“装修”

三、技巧一：Terraform 不要写死配置，用变量“抽象环境”

很多人 Terraform 写成这样（典型错误）：

resource "aws_instance" "spark_node" { instance_type = "m5.large" count = 3 }

问题：
👉 dev 和 prod 用一样配置？你老板不会同意

正确姿势👇

variable "instance_type" {} variable "node_count" {} resource "aws_instance" "spark_node" { instance_type = var.instance_type count = var.node_count }

然后不同环境用不同 tfvars：

# dev.tfvars instance_type = "t3.medium" node_count = 1 # prod.tfvars instance_type = "m5.2xlarge" node_count = 6

执行：

terraform apply -var-file=dev.tfvars

💡 我的经验一句话总结：

环境差异不要写在代码里，要写在参数里

否则你会收获一堆：

main.tf main-prod.tf main-final.tf main-final-v2.tf（真实存在…）

四、技巧二：Helm 不只是安装，是“配置管理系统”

很多人 Helm 用法：

helminstallspark bitnami/spark

然后就没然后了。

这就相当于你装了个软件，但没配置。

正确玩法：values.yaml 才是核心资产

worker:replicas:3memory:4Gidriver:cores:2

然后：

helm upgrade--installspark bitnami/spark-fvalues.yaml

进阶：多环境 values 拆分

values.yaml values-dev.yaml values-prod.yaml

执行：

helm upgrade spark bitnami/spark-fvalues.yaml-fvalues-prod.yaml

💡 重点来了：

Helm = Kubernetes 世界的“配置版本控制系统”

你不管理 values，就等于没用 Helm。

五、技巧三：Terraform + Helm 联动（真正的自动化关键）

很多人这两套是“割裂”的：

• Terraform 起 K8s
• 手动 Helm 部署组件

这其实只完成了 60%

真正的工程化，是👇

👉 Terraform 直接调用 Helm Provider

provider "helm" { kubernetes { config_path = "~/.kube/config" } } resource "helm_release" "spark" { name = "spark" repository = "https://charts.bitnami.com/bitnami" chart = "spark" values = [ file("values-prod.yaml") ] }

一条命令：

terraform apply

直接完成：

✔ 集群创建
✔ Spark 部署
✔ 配置注入

💡 这一步的意义非常大：

你不是在“部署服务”，你是在“声明整个数据平台状态”

六、技巧四：状态管理是命门（别踩坑）

Terraform 最大坑：state 文件。

如果你还在本地存：

terraform.tfstate

那基本等于：

👉 单点故障
👉 无协作能力
👉 极易冲突

正确做法：

terraform { backend "s3" { bucket = "tf-state-prod" key = "data-platform/terraform.tfstate" region = "ap-southeast-1" } }

甚至加锁：

dynamodb_table = "terraform-lock"

💡 一句话点醒：

state = 你的“真实世界映射”，丢了等于失忆

七、技巧五：模块化（Module）是规模化的关键

如果你每个环境都 copy 一份代码，那迟早炸。

正确方式：

module "spark_cluster" { source = "./modules/spark" instance_type = var.instance_type node_count = var.node_count }

模块结构：

modules/ spark/ kafka/ airflow/

💡 本质：

模块化 = 平台能力产品化

你写的不是脚本，是“数据平台组件”。

八、一些我踩过的坑（血泪经验）

1. Helm 升级失败卡死

👉 解决：加--atomic

helm upgrade--atomic...

2. Terraform destroy 不干净

👉 特别是 Helm release

解决：

force_update = true recreate_pods = true

3. 配置漂移（drift）

👉 人工改了 Kubernetes

解决：

terraform plan

每天跑一遍，像体检一样。

九、最后说点“有温度”的话

做数据平台这些年，我越来越有个感受：

技术难的不是“搭起来”，而是“稳定地重复搭起来”

Terraform + Helm 本质解决的不是部署问题，而是：

• 可复制性
• 可维护性
• 可演进性

它让你从：

👉 “运维工程师”
进化成
👉 “平台工程师”

十、结尾一句话

如果你现在的数据平台还靠：

• 手动 SSH
• 手动改配置
• 手动部署组件

那你不是在做平台，你是在“养宠物”。

而 Terraform + Helm，做的是另一件事：

把你的数据平台，变成一群可以随时替换的“牛群”。