无论你喜欢与否，你都不得不承认Helm是管理Kubernetes应用程序独一无二的工具，你甚至可以通过不同的方式使用它。
在Helm的使用过程中，我们注意到有几个问题不断出现：
你将你的Helm chart放在哪里？
你是使用app文件保存它们还是使用chart仓库？
你如何划分Helm chart？
你是使用一个共享的chart或是为每个服务维护一个chart？
我正在通过我以往在各种创业公司的经验来尝试解决这些问题，但是我也借鉴了大型公司的做法。
以下是我要概述的几个方法：
使用一个chart仓库来存储一个大型共享chart
使用一个chart仓库来存储许多特定于服务的chart
使用特定于服务的chart，这些chart与服务本身存储在同一仓库中
然后，我将介绍在决定这些选项时应该考虑的因素，例如依赖项差异和团队结构等。
在我们一个项目中，我们从一个用于部署多个服务的大型chart开始。它存储在ChartMuseum中，并由负责部署基础架构的人员进行维护。
如果你的各个服务在本质上十分类似，那么共享chart可以为你省去很多麻烦。这里我们采用Helm维护者Josh Dolitsky在KubeCon 2019上描述的情况：
我最近在负责一个项目，这个项目包含9个微服务……我意识到它们几乎都是相同的HTTP监听服务。所以我决定仅仅构建一个helm chart来部署9个不同的服务，为每个服务做不同的配置——仅为特定的服务设置一个新的docker标签。
在这种情况下，将Helm chart存储在ChartMuseum等chart仓库中是有意义的，因为只有值需要保存在这些特定服务的仓库中。
Option2：在一个chart仓库中维护几个特定于服务的chart特定于服务的chart优势在于，你可以更改一项服务，而无需担心会破坏另一项服务。但是它们可能会导致重复的工作——如果你要更新通用配置，则必须在每个chart中进行相同的更改。
是否需要在一个chart仓库中保存它们则是另一个问题了。如果这些chart是特定于服务的，那么将它们存储在一起尚没有强有力的架构论证。当然，如果你有专门的人员或团队来维护所有的chart，一起存储多个特定于服务的chart通常会比较容易。
例如，与我一起工作的一位DevOps工程师，他在一个中心chart仓库中维护15种不同的微服务chart。对于他而言，在同一个位置更新所有chart比向15个不同的仓库提交拉取请求要容易得多。开发人员当然清楚如何更新chart，但是处理资源相关的设置显然更吸引他们。
Option3：在与服务本身相同的仓库种维护特定于服务的chart对于基于微服务的应用程序来说，特定于服务的chart是一个很好的选择。而当你将每个chart与服务代码保存在同一仓库中时，使用特定于服务的chart则会更好。
如果你在服务仓库中存储Helm chart，那么可以更轻松地独立于其他项目持续部署服务。并且你可以将chart更新（例如添加新变量）与应用程序逻辑的更改一起提交，使其更易于识别和还原重大更改。
然而，本选项的优势取决于你所维护的微服务的数量。如果你的微服务数量正迈入两位数，那么这一选项的优势则没有那么明显，更多的是阻碍。如果你要处理非常同质的服务（如Josh Dolisky），则尤其如此。
决定选项时需要考虑的因素一般情况下，有两个方面需要考虑：
依赖项和可重现：每个服务的依赖项有多少区别？对一个服务的更改有多大风险会中断另一个服务？你如何再现特定的开发条件？
团队结构：你负责每个服务的小型自治团队吗？你有了解DevOps的开发人员吗？你的团队中DevOps文化流行程度如何？
依赖项和可重现如果你将你的chart和应用程序分开维护，它们的版本将彼此不同。如果你在部署时遇到问题，并且需要重现导致该问题的条件，则需要确定：a）服务版本；b）用于部署它的chart版本。你可能想要走捷径，使用“latest” chart来测试服务x.x.x，但这并不是一个好想法，因为这样你将永远无法重现造成问题的确切条件。
那么，如果你经常需要更改的chart版本怎么办？是不是应该一起测试这些改动呢？
考虑到许多开发人员需要创建同一共享chart中的分支版本这一场景：
开发人员（图中的Edeltraud和Eberhardt）分别在不同的分支中工作，并且想要在开发环境中测试他们的更改以及图表更改——所以他们还需要分支chart。同时，DevOps工程师在他的共享chart的分支中更新一些常用组件。
如果没有人将他们的chart更改更新到各个分支，那么就有可能破坏另一个服务部署。