想象一下，我正在开发一个基于应用程序的微服务 . 他们将使用Helm Package Manager部署到kubernetes . 一些微服务结束了具有非常相似的YAML文件配置 . 其他一些可能在YAML配置方面有所不同 . 这是什么最好的做法？我有几个选择：
使用通用图表并使用values.env.yaml为每个微服务传递不同的配置，然后使用不同的版本名称进行部署 .
为每个微服务创建一个图表，无论它们在配置方面是否相似？
这是一个意见问题，所以我会回答一个意见 .
缺点：例如，创建 _helpers.tpl 文件会更难 . 该文件将迅速增长，对于创建微服务的人来说，它可能会让人感到困惑 .
_helpers.tpl
缺点：文件传播，到处都有太多文件，你的Helm图表回购可以快速增长 . 此外，存在大量代码重复的风险 .
更普遍的做法是官方头盔图表的第2个，但是每个图表再次用于非常不同的应用程序 .
就像@Rico提到的那样，这是一个意见问题 . 这是我的意见：
我认为从一张适合所有人的图表开始是一个好主意 . 但是当你必须为有特殊要求的少数服务添加非常具体的东西时，你应该创建另一个图表 . 当谈到微服务时，这个想法与Monolith first非常相似 .
在我的公司，我们有一张约30项服务的图表 . 它们有非常相似的需求，因此模板文件不是太复杂，_helpers文件只有大约50行 . 我们对此解决方案非常满意，因为您只需要几行值.yaml即可为操作做好准备 .
2 回答
这是一个意见问题，所以我会回答一个意见 .
缺点：例如，创建
_helpers.tpl文件会更难 . 该文件将迅速增长，对于创建微服务的人来说，它可能会让人感到困惑 .缺点：文件传播，到处都有太多文件，你的Helm图表回购可以快速增长 . 此外，存在大量代码重复的风险 .
更普遍的做法是官方头盔图表的第2个，但是每个图表再次用于非常不同的应用程序 .
就像@Rico提到的那样，这是一个意见问题 . 这是我的意见：
我认为从一张适合所有人的图表开始是一个好主意 . 但是当你必须为有特殊要求的少数服务添加非常具体的东西时，你应该创建另一个图表 . 当谈到微服务时，这个想法与Monolith first非常相似 .
在我的公司，我们有一张约30项服务的图表 . 它们有非常相似的需求，因此模板文件不是太复杂，_helpers文件只有大约50行 . 我们对此解决方案非常满意，因为您只需要几行值.yaml即可为操作做好准备 .