别再手搓集群了：用 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 用法：
helm install spark bitnami/spark
然后就没然后了。
这就相当于你装了个软件，但没配置。
正确玩法：values.yaml 才是核心资产
worker:
replicas: 3
memory: 4Gi
driver:
cores: 2
然后：
helm upgrade --install spark bitnami/spark -f values.yaml
进阶：多环境 values 拆分
values.yaml
values-dev.yaml
values-prod.yaml
执行：
helm upgrade spark bitnami/spark -f values.yaml -f values-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，做的是另一件事：
把你的数据平台，变成一群可以随时替换的“牛群”。
