Terraform 通过声明式 HCL 代码定义集群架构，涵盖网络、控制平面、工作节点及附加服务等模块，采用模块化组织、参数化配置和远程状态管理实现可复用、可版本控制的生产级集群部署。
用 Terraform 定义集群架构，核心是把整个集群的结构、依赖和配置写成可读、可复用、可版本控制的 HCL 代码。不是写脚本去“执行安装”，而是描述“最终该长什么样”——Terraform 自动推导怎么建、按什么顺序建、哪些要先于哪些。
明确集群组件边界与职责
一个生产级集群（如 EKS 或 GKE）不只是一组节点，它包含网络、身份、控制平面、工作节点、存储、监控等模块。定义前先拆解清楚：
- 网络层：VPC、子网（公有/私有）、路由表、NAT 网关、安全组
- 控制平面：EKS 集群本身（含 endpoint、证书、RBAC 配置），或 GKE 的 master 参数
- 工作节点：节点组（Node Group / Node Pool），包括实例类型、ASG 策略、IAM 角色、启动模板
- 附加服务：CoreDNS、Cluster Autoscaler、OIDC 提供器、Metrics Server 等——部分通过 Helm 或 Kubernetes resource 定义，部分由模块原生支持
用模块化方式组织配置
避免把所有资源堆在 main.tf 里。推荐分层引用官方或社区成熟模块：
- 用
terraform-aws-modules/vpc/aws建 VPC，而不是手写 10+ 个 aws_vpc、aws_subnet 资源 - 用
terraform-aws-modules/eks/aws创建 EKS 集群和节点组，它已封装 IAM、SSM、标签、日志集成等细节 - 每个模块通过
source和version锁定，保障可重现性，例如：source = "terraform-aws-modules/eks/aws"<br>version = "20.1.0"
参数化关键配置项
让同一套代码适配不同环境（dev/staging/prod），靠变量驱动：
- 定义
variables.tf：区域、K8s 版本、节点数量、实例类型、标签前缀、是否启用日志保留等 - 敏感值（如密钥）不硬编码，用
var.xxx引用，并配合terraform.tfvars或环境变量注入 - 对多可用区部署，用
list(string)类型变量传入 AZ 列表，而非写死"us-east-1a"
状态管理与协作前提
单人本地跑通只是起点，团队协作必须解决状态一致性问题：
- 禁用本地
terraform.tfstate，改用远程后端（如 S3 + DynamoDB 锁表） - 在
terraform {}块中声明 backend，确保所有人操作同一份真实状态 - 搭配 CI/CD（如 GitHub Actions 或 GitLab CI）自动执行
terraform plan和apply，人工审批变更
