使用 Helm 管理我的“应用程序”，但使用 kubectl 管理版本答案

【问题标题】：Using Helm to manage my "app" but kubectl to manage the version使用 Helm 管理我的“应用程序”，但使用 kubectl 管理版本
【发布时间】：2020-05-02 18:28:56
【问题描述】：

所以，我要做的是使用 helm 将应用程序安装到我的 kubernetes 集群。假设图表中的图像标签为 1.0.0。

然后，作为 CI/CD 构建管道的一部分，我想使用 kubectl 更新图像标签，即kubectl set image deployment/myapp...

问题是，如果我随后对掌舵图进行任何更改（例如副本数），并且我 helm upgrade myapp 这会将图像标签恢复为 1.0.0。

我尝试将 --reuse-values 标志传递给 helm upgrade 命令，但这没有帮助。

有人有什么想法吗？我需要使用 helm 来更新图像标签吗？我试图避免这种情况，因为该图表在管道的这个阶段不可用。

【问题讨论】：

我认为你不需要使用helm更新image标签，你需要通过CI/CD更新image标签后将image标签同步到helm chart。跨度>
我应该指出我正在使用 helm3
澄清一下，您只想升级标签名称，而不是整个图像？另外，您是尝试在本地还是在本地进行？
好吧，当使用 kubectl set image 时，我正在更新整个图像。但我实际上改变的是图像标签。本地与本地有什么区别吗？

标签： kubernetes kubernetes-helm

【解决方案1】：

当使用 CI/CD 构建和部署时，您应该使用 single source-of-truth，这意味着文件版本控制在例如Git 然后你在该文件中进行所有更改。因此，如果您使用 Helm 图表，它们应该存储在例如Git 和所有更改（例如新图像）都应在您的 Git 存储库中完成。

您可以有一个构建管道，最终将新映像提交到 Kubernetes 配置存储库。然后触发一个部署管道，该管道使用 Helm 或 Kustomize 应用您的更改并可能执行测试。

【讨论】：

我同意这是一个不错的解决方案。但是，我使用 gitlab 和 git 标签来跟踪每个环境的版本。我试图避免自动 git 提交。我目前的解决方案是将 helm chart 添加为 git 子模块，然后执行 helm upgrade set=image.tag 而不是 kubectl。不太确定这会有多好。