一文教你一次性完成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 version  
Client: &version.Version{SemVer:"v2.16.0", GitCommit:"e13bc94621d4ef666270cfbe734aaabf342a49bb", GitTreeState:"clean"}  
Server: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}
➜ helm3 version  
version.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 TLS  
RELEASES=$(helm list --tls -aq)

# Loop through releases and, for each one, test conversion  
while IFS= read -r release; do  
  helm3 2to3 convert $release --dry-run  
done <<< "$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 dev  
NAMESPACE 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.v1  
secret "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 TLS  
RELEASES=$(helm list --tls -aq)
# Loop through releases and, for each one, test conversion  
while IFS= read -r release; do  
  helm3 2to3 convert $release --tiller-out-cluster  
done <<< "$RELEASES"