Kubernetes配置：代码repo vs helm chart repo

Question

Helm被广告宣传为“管理k8s上应用程序部署的方式”。

我们有微服务，它具有代码存储和可部署的一对一映射，我会发现将k8s配置映射与代码一起使用更加方便，以便它们一起发展，例如在添加新的环境变量时功能标志。

但是，我们维护一个单独的头盔图git repo，需要偶尔与代码同步更新。

什么是最佳做法：

• 何时使用掌舵图？ 在具有代码存储和可部署的一对一映射时是否适用？ 或主要是协调复合应用程序的部署？
• 您是否已成功使用每个仓库的头盔图表（而不是所有图表的单个仓库）？
• 如果使用vanilla k8s配置映射来配置git repo中的部署，您遇到了哪些问题？ 即你什么时候开始需要掌舵？

希望它不是太通用或固执己见，但乐于编辑以使其更具体。

Answer 1

我们在Activiti云项目上遇到了一些相同的问题，所以可以根据我的经验回答：

1何时使用头盔图？ 在具有代码存储和可部署的一对一映射时是否适用？ 或主要是协调复合应用程序的部署？

如果您发现自己需要针对不同环境的不同配置，那么helm可能很有用。 如果您有外部消费者也希望使用可部署的部署并将它们部署到自己的环境中，或者扩展或进一步配置可部署的部署，则更有用。

2您是否已成功使用每个仓库的头盔图表（并不是所有图表的单个仓库）？

我们已经出于某些目的 这样做了 ，如果您使用Jenkins-X ，它就是默认设置，它为您提供了一个针对特定方式进行CI / CD设置的自定义kubernetes集群。 它包括该集群中的图表博物馆 ，当您使用其默认管道在Jenkins-X中构建应用程序时，该图表将发布到内部图表博物馆。

但是，我们也使用了一个回购 。 如果您使用github页面存储库托管图表，这是一种自然的方法，因为如果源与托管位置相同，它可以更容易地构建图表包并发布它们。 我不认为这是必要的 - 如果您设置CI这样做，您应该能够将打包的图表添加到docs目录并重新索引repo 。 这意味着每个项目的CI都需要提交到helm repo项目。

3如果使用vanilla k8s配置映射来配置git仓库的部署，您遇到了哪些问题？ 即你什么时候开始需要掌舵？

与1一样，如果您需要能够在部署时更改配置（例如，设置特定于群集的URL）或分发以允许其他人创建覆盖默认值的新包，那么您确实获得了价值。 它也可能有助于将某些配置外部化为部署时参数，以便特定参数不必存在于git中（例如，您可能希望使用某些密码执行此操作）。