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