Kubernetes 配置 : on code repo vs on helm charts repo

Question

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

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

但是，我们维护的是一个 helm Charts git 存储库，需要偶尔与代码同步更新。

最佳实践是什么:

• 何时使用 Helm chart ？当代码存储库和可部署具有一对一映射时是否适用？或者主要是为了协调复合应用程序的部署？
• 您是否在每个存储库中成功使用了 Helm Chart(而不是对所有图表使用单个存储库)？
• 如果使用 vanilla k8s 配置映射来配置 git 存储库的部署，您遇到了哪些问题？ IE。你什么时候开始需要 Helm ？

希望它不是太笼统或固执己见，但很乐意进行编辑以使其更加具体。

Answer 1

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

1 When to use helm charts? Is it applicable when having 1-to-1 mapping of code repo and deployable? Or mainly to coordinate deployment of composite apps?

如果您发现自己需要针对不同环境进行不同配置，那么 helm 可能会很有用。如果您的外部使用者也想使用您的可部署项并将其部署到自己的环境中，或者扩展或进一步配置可部署项，那么这会更加有用。

2 Have you been using successfully helm chart per repo (isntead of a single repo for all charts)?

我们有done this for some purposes如果您使用Jenkins-X，则它是默认值，它为您提供了一个专为执行 CI/CD 的特定方式而设置的固执己见的 kubernetes 集群。它包括 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 If using vanilla k8s config map for configuring the deployment out of a git repo, what issues have you faced? I.e. when do you start needing helm?

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