假设我正在开发一个基于微服务的应用程序。它们将使用 Helm 包管理器部署到 Kubernetes。一些微服务最终具有非常相似的 YAML 文件配置。其他一些可能在 YAML 配置方面有所不同。对此的最佳做法是什么？我有几个选择：
【问题讨论】：
标签： kubernetes microservices kubernetes-helm
就像@Rico 提到的，这是一个意见问题。这是我的看法：
我认为从一个适合所有人的图表开始是个好主意。但是当您必须为少数具有特殊要求的服务添加非常具体的内容时，您应该创建另一个图表。当涉及到微服务时，这个想法与 Monolith first 非常相似。
在我的公司中，我们有一张图表，用于约 30 项服务。它们的需求非常相似，因此模板文件不太复杂，_helpers 文件只有大约 50 行。我们对这个解决方案非常满意，因为您只需要几行 values.yaml 即可为您的服务准备运行。
【讨论】：
这是一个意见问题，所以我会回答一个意见。
优点：您只需根据微服务更改 values.yaml 中的几个值，维护 values.yml 会更容易。您的 Helm 图表存储库可能不会增长得那么快。
缺点：例如，创建 _helpers.tpl 文件会更加困难。该文件将迅速增长，并且可能会让创建微服务的人理解它时感到困惑。
优势：当您扩展到数百个时，您的微服务将被分离。开发人员只能处理他们的微服务部署。
缺点：文件散布，到处都有太多文件，而且您的 Helm 图表存储库可能会迅速增长。此外，还有大量代码重复的风险。
更普遍的做法是官方 Helm 图表的第 2 位，但同样每个图表都适用于非常不同的应用程序。
【讨论】：