Helm chart 最佳实践：是否使用最新标签

Question

我想知道您在管理掌舵图表版本方面的最佳实践（或只是您的实践）是什么。

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

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

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

现在，我们也有选择：

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

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

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

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

感谢您的帮助

Answer 1

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

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

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

我认为关键的区别在于 Jenkins-X 致力于实现高度自动化的 CI/CD 流程，并在流程中具有特定的环境。它的方法对于处理频繁的变更部署很有意义。公共图表旨在实现可重用性，并通过公共贡献在广泛的环境和情况下提供稳定的体验。因此，该策略更多地旨在提高可见性和易于理解的变化，而相比之下，您预计这些变化不会那么频繁。