一文教你一次性完成 Helm 3 迁移

2019 年，Kubernetes 软件包管理器——Helm 发布了最新版本 Helm 3，并且该版本已经 stable。Helm 3中的一些关键特性我们在之前的文章中已经介绍过，其中一些功能吸引了许多开发人员。那么，现在你大概想知道升级/迁移到新版本的 Helm 是否麻烦。尽管 Helm 可能十分复杂，但是请不要担心，升级过程极为简单。Helm 官方 blog 提供了有关迁移过程的指南，十分详细，欢迎查阅：

https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/

这篇官方指南十分直观地告诉你将版本分别迁移到 Helm 3 所需准备的一切。但是如果你想要一次性完成迁移应该怎么办呢？你如何确保在删除 Tiller 之前没有任何组件在使用它？

下载 Helm 3 二进制文件

我们测试 Helm 2 以及最新版本，因此在 Helm 2 完全卸载之前，我们应该准备好两个版本的二进制文件。下载最新 Stable 版本的二进制文件并将其添加到你的 PATH 中。将现有的 v2 二进制文件重命名为 helm2 以及将最新版本重命名为 helm3。我将两个版本都保存在/usr/local/bin 中，以便我能够随时切换它们：

➜ helm2 versionClient: &version.Version{SemVer:"v2.16.0", GitCommit:"e13bc94621d4ef666270cfbe734aaabf342a49bb", GitTreeState:"clean"}Server: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}➜ helm3 versionversion.BuildInfo{Version:"v3.0.1", GitCommit:"7c22ef9ce89e0ebeb7125ba2ebf7d421f3e82ffa", GitTreeState:"clean", GoVersion:"go1.13.4"}

准备 CI 脚本和 Chart

在你运行升级流程之前，你需要确认你的 CI 脚本以及自定义 Chart 是否与 Helm 3 兼容。我之前写过一篇文章（https://itnext.io/breaking-changes-in-helm-3-and-how-to-fix-them-39fea23e06ff），文章中涵盖了一些需要注意的事情，其中的大部分都能够轻松解决。尽管 OpenAPI 验证机制很有趣，但它很有可能让你措手不及：

➜ helm install prometheus .Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: ValidationError(Deployment.spec.template.spec.containers[0].volumeMounts[0]): unknown field "defaultMode" in io.k8s.api.core.v1.VolumeMount

一旦你解决了所有这些麻烦的问题，那么就可以开始迁移到 Helm 3 啦！

迁移 Helm 配置

我在文章开头提到的 Helm 博客文章中有这一步骤的详细描述，它将会更新所有你的本地配置以便 Helm 3 可以使用它：

https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/#migrate-helm-v2-configuration

如果你在诸如 Jenkins、TeamCity 或 TravisCI 之类的 CI 系统中的构建代理运行 Helm，那么可以这一步骤。如果你在本地机器或有持久文件系统的中央服务器中运行 Helm，那么一定要在整个配置中进行迁移，尤其是当你拥有自己的 Helm repo 或使用自定义插件时。无论哪种方式，请确保你已经通读了这一部分，以确定是否与你有关。

迁移版本（保留 Tiller）

现在，我们有几种方式可以实现迁移。你可以迁移特定版本到 Helm 3 来进行一些测试，具体操作在 Helm 官方博客中可以找到。你也可以选择迁移许多版本并将它们从 Tiller 中全部删除。就我个人而言，我发现一次性迁移所有版本到既定环境中更为简单，但需要将发布数据保留在 Tiller 中，直到确定在我们的环境中没有一处使用 Helm 2 为止。如此，就不会产生盲点，所有东西都使用相同版本的 Helm：

# List Helm 2 Releases# omit --tls flag if you're not using TLSRELEASES=$(helm list --tls -aq)# Loop through releases and, for each one, test conversionwhile IFS= read -r release; do  helm3 2to3 convert $release --dry-rundone <<< "$RELEASES"

你感到满意之后，可以删除–dry-run 标志，并静观 2to3 插件发挥其作用。

请注意：正如我所提到的，这里有–delete-v2-releases 标志，它将会迁移版本并从 Tiller 删除。如果你确定自己不再需要任何信息，你可以执行这一操作，风险自担。

移除 Tiller 之前……

这一步是我最不想略过的一步，以防万一我们需要回滚到 Helm 2。此时，只要你的 CI 系统和团队成员都在使用 Helm 3，就没有理由保留 Tiller。但如果你想完全确保没有任何组件还将会使用旧版本，那我建议你还是将 Tiller 保留几个小时并观察 helm ls 的输出结果以查看 UPDATEDcolumn 中的时间戳是否完全改变。如果改变了，就意味着有人/有些组件没有使用 Helm 3。

如果将版本迁移到 Helm 3 之后，由 Helm 2 对其进行了修改，你将必须删除保存了版本信息的 Helm 3 Kubernetes secret，才能够将其从 Helm 3 中清除，而不会删除相关资源：

➜ kubectl get secret -n devNAMESPACE                NAME                                                 TYPE                                  DATA   AGE                           dev          sh.helm.release.v1.postgres.v1                 helm.sh/release.v1                    1      36d➜ kubectl delete secret -n dev sh.helm.release.v1.postgres.v1secret "secret "sh.helm.release.v1.postgres.v1" deleted

现在如果我们使用 Helm 3 列出在 dev 命名空间中的版本，我们将会看到那些版本已经不复存在：

NAME           NAMESPACE      REVISION UPDATED                                 STATUS   CHART                APP VERSION

在我们弄清楚谁依旧在使用 Helm 2 之后，我们就可以再次执行迁移流程。解决此问题后，请使用 helm3 2to3 convert 进行迁移。

一旦你完全确定你可以移除 Tiller 及其相关的 RBAC 角色和数据，那么就可以运行 helm 2to3 cleanup。

迁移版本——没有 Tiller 的 Helm

直接添加–tiller-out-cluster 标志到我在之前提供的脚本中，然后 2to3 插件将从你的本地 Tiller 实例中移除版本信息。

# List Helm 2 Releases# omit --tls flag if you're not using TLSRELEASES=$(helm list --tls -aq)# Loop through releases and, for each one, test conversionwhile IFS= read -r release; do  helm3 2to3 convert $release --tiller-out-clusterdone <<< "$RELEASES"

原文链接：

https://itnext.io/additional-tips-for-migrating-to-helm-3-304c9d50f1b4