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