Helm 被宣传为“在 k8s 上管理应用部署的方式”。
我们的微服务具有代码仓库的一对一映射和可部署性，我发现将 k8s 配置映射与代码一起使用会更方便，以便它们一起发展，例如为功能标志添加新环境变量时。
但是，我们改为维护一个 helm charts git repo，它需要不时与代码同步更新。
最佳做法是什么：
希望它不是太笼统或固执己见，但很高兴对其进行编辑以使其更具体。
【问题讨论】：
标签： kubernetes microservices kubernetes-helm
我们在Activiti 云项目中遇到了一些相同的问题，因此可以根据我的经验来回答：
1 何时使用掌舵图？它是否适用于代码仓库的一对一映射和可部署？还是主要是为了协调复合应用的部署？
如果您发现自己需要针对不同环境进行不同配置，那么 helm 会很有用。如果您的外部消费者也想使用您的可部署项并与他们一起部署到他们自己的环境或扩展或进一步配置可部署项，则更加有用。
2 您是否已成功使用每个 repo 的 helm chart（而不是所有图表的单个 repo）？
我们有done thisfor some purposes，如果您使用Jenkins-X，这是默认设置，它为您提供了一个固执己见的 kubernetes 集群，用于以特定方式执行 CI/CD。它在该集群中包含一个chartmuseum，当您使用其默认管道在 Jenkins-X 中构建应用程序时，该图表将发布到内部图表博物馆。
但是，我们有 also used a single repo。如果您使用github pages repository 托管您的图表，这是一种自然的方式，因为如果源与托管它们的位置相同，那么它可以更轻松地构建和发布图表包。我不认为这是必要的 - 如果你设置你的 CI 这样做你应该能够add packaged charts to the docs directory and re-index the repo。这意味着每个项目的 CI 都需要提交到 helm repo 项目。
3 如果使用 vanilla k8s config map 从 git repo 配置部署，您遇到了什么问题？ IE。你什么时候开始需要掌舵？
与 1 一样，如果您需要能够在部署时更改配置（例如，设置特定于集群的 url）或分发以允许其他人创建覆盖默认值的新包，那么您确实会获得价值。能够将一些配置外部化为部署时参数也可能会有所帮助，这样特定参数就不必存在于 git 中（例如，您可能希望使用某些密码来执行此操作）。
【讨论】：