Helm 图表最佳实践：最新标签与否

Question

我想知道您在管理 helm 图表版本方面的最佳做法（或只是您的做法）。

我想知道处理应用程序版本控制、持续集成/交付和图表打包的最佳方式是什么。

今天，我有许多微服务过着它们的生活。每个都有自己的生命周期，并且在自己的 git 存储库中拥有自己的版本控制。

此外，我们选择为所有图表使用一个 git 存储库。

现在，我们有太多选择了：

• 每次微服务更改时，都会构建一个新的 docker 映像并创建一个新版本的图表（仅包含在 value.yaml 文件中更改的 docker 映像的标签）
• 或者，即使微服务发生变化，我们也不会创建图表的新版本。图表中 docker 标签的默认值设置为“default”，当我们要升级图表时，我们必须使用--set image.tag=vx.x.x 标志。

从“ops”的角度来看，第一种方法的好处是，我们随时都知道集群上运行的每个图表（和每个 docker 映像）的版本。缺点是在某个时间，每个图表都会有很多很多版本，只有一个 docker 标签版本发生了变化。

另一方面，第二种方法的好处是，唯一使图表版本发生变化的是图表代码本身的修改，而不是应用程序的更改。它大大减少了每个图表的“无用”高版本号。缺点是我们必须在安装/升级时覆盖 docker 标签，并且我们无法观察到集群上正在运行的版本（在灾难恢复计划的情况下很有用）。

那么，你的做法是什么？也许是一种混合方法？

感谢您的帮助

Answer 1

我认为这是一个取决于您项目需求的选择。一个有趣的比较是 Kubernetes 图表存储库中公共图表的当前版本控制策略和 Jenkins-X 当前的默认版本控制策略。

仅当对图表进行更改时，公共图表才会受到影响。这可能是增加它指向的默认图像标签的版本，但每次它都是一个明确的操作，需要公关和审查，并决定它是主要、次要还是修复版本增加。

在 Jenkins-X 集群中，默认行为是，当您更改其中一个微服务的代码时，无论图表本身是否发生变化，它的图表版本都会自动调整。源代码库中的图表是指快照，但它是在显式版本下自动部署的，并且该版本在通过管道部署到的环境中被引用。该图表引用源中图像的草稿/开发标签，并且在流程中也会自动替换为显式版本。

我认为主要区别在于 Jenkins-X 是朝着高度自动化的 CI/CD 流程发展的，流程中有特定的环境。它的方法对于处理频繁的更改部署很有意义。公共图表旨在通过公共贡献提供可重用性并在广泛的环境和情况下提供稳定的体验。因此，那里的策略更侧重于可见性和易于理解的变化，相比之下，您预计这些变化不那么频繁。