Terraform把K8s集群拆成3个文件，运维看完直呼过瘾

一套生产级EKS集群的配置代码，被压缩到不足200行。不是炫技，是去年某金融团队踩坑后的被迫精简——他们曾用单文件管理3000行配置，一次变量改错导致整个测试环境重建，耗时4小时。

这篇是系列第四部分，前情提要：控制平面（Control Plane）已就绪，但集群里还没有能跑容器的机器。本文解决的就是这个空壳问题——用Node Groups把EC2实例挂上去，同时埋一个多数团队会忽略的隐患。

变量设计：把"开发机"和"生产机"塞进同一套代码

打开variables.tf，9个变量覆盖从命名到扩缩容的全流程。没有一个是硬编码的，连实例类型都留了后门：

默认给的是t3.large（2核8G），但注释里明牌提示：开发环境可以压到t3.medium，生产环境建议上m5.large。同一套模块，两种成本结构。

这种设计在Terraform社区叫"环境感知配置"，但说白了就是把判断权交给调用方。团队内部不需要维护两套代码仓库，CI/CD管道里改几个参数就能切环境。

扩缩容三件套——desired_size、min_size、max_size——被单独拎出来做成必填项的反面。默认值是1-1-2，意味着单节点起步，最高撑到2节点。对于验证阶段够用，但上生产前必须显式覆盖，否则高峰期直接触顶。

一个容易漏看的参数是max_unavailable，默认1。滚动更新时允许最多1台节点同时不可用。如果你的应用是单副本部署，这个值设成1等于直接断服。部分团队在这里栽过跟头，发现更新时服务503，排查半天才定位到这个隐藏开关。

资源声明：EKS如何"接管"你的EC2

核心资源aws_eks_node_group的声明异常简洁。四个必填字段：集群名、节点组名、IAM角色ARN、子网ID。没有用户数据脚本，没有启动模板，EKS替你把容器运行时、kubelet、CNI插件全装好了。

这种托管模式省掉80%的初始化代码，但也带来一个副作用——你对节点OS的控制权被大幅收缩。2023年AWS推出EKS Optimized AMI的定制版时，大量团队才发现自己连内核参数都改不了，被迫迁移到自定义启动模板。

实例类型的传递是直接透传变量，没有本地校验。这意味着如果你拼错t3.larg，计划阶段不会报错，应用阶段才会炸。Terraform的validation块可以堵这个洞，但原文模块里没做，算是留个作业。

标签（labels）字段支持给节点打Kubernetes标签，默认空map。实际使用中，这里常用来区分工作负载类型——比如workload=gpu配合节点选择器，把推理任务绑到P系列实例。

扩缩容逻辑：1-2-5的数字游戏

原文给的示例数值很有代表性：min=1, desired=2, max=5。这个区间设计暴露了一个常见误区——很多人把desired_size当成"当前状态"，实际上它是"目标状态"。

集群Autoscaler读的是这个值。当Pod pending积压时，Autoscaler会算需要多少新节点，然后改desired_size。如果max设得太低，扩容请求会被直接拒绝，Pod永远挂起。部分团队在这里设了10，结果账单爆炸；设成3，高峰期又卡死。

update_config块单独控制滚动更新的并发度。max_unavailable=1在3节点集群里意味着33%的容量风险，10节点集群里只有10%。这个参数应该和副本数、PDB（Pod Disruption Budget）联动配置，但多数模块不会帮你做这层关联。

原文没提的是，这个模块缺了污点（Taints）和容忍（Tolerations）的配置入口。想跑专用节点组？得自己fork模块加字段。这也是社区模块的通病——覆盖80%场景，剩下20%让你自己补。

输出设计：为什么这里留了空白

注意到outputs.tf存在但原文没展开内容。这种"占位式"设计在模块化架构里很常见——先占坑，等下游需求明确再填。

实际该输出什么？节点组ARN用于IAM策略绑定，节点角色名用于CloudWatch日志授权，实例ID列表用于自定义监控。但过早输出会增加维护负担，所以作者选择留白。

这种克制和前文控制平面模块形成对比——那边输出了端点、证书、OIDC issuer等一堆字段。节点层相对" dumb "，主要消费方是集群Autoscaler和外部监控，暂时不需要复杂契约。

系列到此，基础设施的骨架已经搭完：VPC、控制平面、节点组。下一部分进入服务网格层——Istio的注入和流量管理。但有个问题：节点组就绪后，你的第一个Pod该跑在哪？默认调度器会随机分配，而Istio的Sidecar注入需要特定标签配合。这个衔接点，是很多团队从"能跑"到"能管"的分水岭。