Kubernetes配置:代码仓库vs掌舵图表仓库 [英] Kubernetes config: on code repo vs on helm charts repo

问题描述

Helm被宣传为在k8s上管理应用程序部署的方法".

Helm is advertised as pretty much "the way to manage the deployment of apps on k8s".

我们有微服务，它们具有代码仓库和可部署的1-to-1映射，我发现将k8s配置映射与代码一起使用会更加方便，以便它们一起发展，例如.在为功能标记添加新的环境变量时.

We have microservices whith a 1-to-1 mapping of code repo and deployable, and I would find it much more convenient to have the k8s config map along with the code, so that they evolve together, e.g. when adding a new environment variable for a feature flag.

但是，我们改为维护一个头盔图表git repo，有时需要与代码同步进行更新.

However, we maintain instead a single helm charts git repo, that would need to be occasionally updated in sync with the code.

最佳做法是什么:

• 何时使用头盔图表?在具有代码仓库和可部署的一对一映射时，是否适用?还是主要是为了协调复合应用程序的部署?
• 您是否一直在成功地使用每个回购的掌舵图表(对于所有图表来说都是一个回购)?
• 如果使用vanilla k8s配置图从git repo中配置部署，您遇到了什么问题? IE.您什么时候开始需要掌舵?

希望它不是太笼统或自以为是，但很高兴对其进行编辑以使其更加具体.

Hope it is not too generic or opinionated, but happy to edit to make it more concrete.

推荐答案

我们在 Activiti 云项目，因此可以根据我的经验进行回答:

We've encountered some of these same questions on the Activiti cloud project so can answer based on my experience:

1何时使用头盔图表?在具有代码仓库和可部署的一对一映射时，是否适用?还是主要是为了协调复合应用程序的部署?

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?

如果您发现自己需要针对不同环境的不同配置，那么掌舵会很有用.如果您有一些外部使用者，他们也想使用您的可部署项目并将其部署到他们自己的环境中，或者扩展或进一步配置可部署项目，则将更加有用.

If you find yourself needing different configurations for different environments then helm can be useful. Even more useful if you've got external consumers who also want to use your deployables and deploy with them to their own environments or extend or further configure the deployable.

2您是否一直在成功地使用每个回购的掌舵图表(对于所有图表来说都是一个回购)?

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

我们有完成 出于某些目的，并且它是默认设置如果您使用 Jenkins-X ，它会为您提供一个针对性的kubernetes集群CI/CD的特定方式.它在该集群中包括一个 chartmuseum ，并且当您使用其默认管道在Jenkins-X中构建应用时，该图表将发布到内部图表博物馆.

We have done this for some purposes and it's the default if you work with Jenkins-X, which gives you an opinionated kubernetes cluster set up for a particular way of doing CI/CD. It includes a chartmuseum in that cluster and when you build an app in Jenkins-X using its default pipeline then the chart is published to the internal chartmuseum.

但是，我们也使用了一个回购.如果您使用 github页面存储库托管图表，这是一种自然的方法如果源与托管位置在同一位置，则更容易构建图表包并发布它们.我认为这不是必需的-如果您设置了CI，则您应该可以添加打包的文件图表到docs目录，并为存储库重新编制索引.这意味着您每个项目的CI都需要提交到头盔仓库项目.

However, we've also used a single repo. That is a natural way to go if you're hosting your charts using a github pages repository as it makes it easier to build the chart packages and publish them if the source is in the same place as where they are hosted. I don't think this is necessary though - if you set up your CI to do so you should be able to add packaged charts to the docs directory and re-index the repo. It would mean that your CI for each project would need to make commits to the helm repo project.

3如果使用vanilla k8s config map在git repo之外配置部署，您面临什么问题? IE.你什么时候开始需要掌舵?

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)或分发以允许其他人创建覆盖默认设置的新程序包，则可以真正获得价值.能够将某些配置外部化为部署时参数也可能有所帮助，这样特定参数就不必存在于git中(例如，您可能希望使用某些密码来做到这一点).

As with 1, you really get value if you need to be able to change config at deploy time (e.g. to set a url that is specific to a cluster) or distribute to allow others to create new packages that override the defaults. It might also help to be able to externalise some config as deploy-time parameters so that specific parameters don't have to live in git (e.g. you might want to do this with certain passwords).

这篇关于Kubernetes配置:代码仓库vs掌舵图表仓库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！