我公司的任务是为 Terraform 中的 (EKS) Kubernetes 集群创建标准配置和模板，可以使用 GitLab CI/CD 进行部署。部署和配置已经完成了一段时间，但我一直在模板方面苦苦挣扎。
这是我的任务：创建一个模板项目/存储库，其配置可供其他人复制和编辑。
但是，我需要能够更新我的配置以匹配将来的版本或新功能，然后他们需要将我的模板克隆/复制/合并回他们的配置中，而不覆盖他们的特定配置。
我曾向一位资深开发人员寻求建议，他建议我创建一种配置文件（如 Terraform 的 .tfvars 文件），将特定配置放入其中，然后我可以抽象我的模板并对其进行更新，而不会影响将来的配置。这在表面上目前是可行的，但随着功能的增加和对我的更多具体请求的出现，这似乎只会在未来变得越来越难以维护。
另一种选择是使用 Terraform 模块，但这也有可能产生同样的副作用，即以后会变成一个无法维护的混乱局面。
所以，我在这里不知所措。这似乎对我或他们将来都不太容易维护。最重要的是，当我的模板发生重大版本更新时，他们的配置肯定会中断，而我却没有办法在不进行大量手动工作的情况下修复它。我现在想多做一点工作，这样将来就可以用尽可能少的工作进行维护，但我似乎找不到一个好的解决方案。
所以我要问大家的问题是：如何正确创建一个可维护的 Terraform Kubernetes 集群模板，以便我将来能够以尽可能少的努力进行更新？
答案1
Terraform 模块是一种将一组声明封装成可重用形式的预期机制。
您提到，您主要担心的是，稍后添加的功能可能会导致模块变成“无法维护的混乱”。这是任何可重用代码的维护者都必须处理的典型设计问题：对于有人请求的每个新功能，您要么需要找到一种方法将其集成到现有设计中，要么声明该功能超出范围并为该问题提供单独的解决方案，例如，打算与第一个模块一起使用的另一个模块。
对于共享代码的持续维护问题，无论是在 Terraform 中还是其他方式中，都没有通用的答案，但 Terraform 文档部分模块组成描述了将问题分解为可以以不同方式组合在一起的较小部分的一些模式。
这是模块作者避免您所担心的问题的一种常用方法，即单个模块变得越来越大，包含的内容远远超出其最初设计的范围：相反，您可以为用户提供多个模块，他们可以以不同的方式组合在一起以处理不同的情况，这样不需要某些特定功能的用户可以跳过包含其相应模块的步骤，同时仍然使用其他模块。