2019, Kubernetes package manager --Helm released the latest version Helm 3, and this version has been stable. Some key features of the 3 Helm our previous article has been introduced, some of these features attracted many developers. Well, now you probably want to know the upgrade / migration to a new version of Helm whether the trouble. Although Helm may be complex, but do not worry, the upgrade process is very simple. Helm official blog provides guidance on the migration process, very detailed, welcome to view:
https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/
This official guide will tell you quite intuitively are migrating to version everything you need to prepare Helm 3. But if you want time to complete the migration should be how to do it? How do you make sure not to use any of the components in it before deleting Tiller
Download Helm 3 binary files
We tested Helm 2 and the latest version, so before Helm 2 completely uninstall, we should be prepared two versions of the binaries. Download the latest Stable version of a binary file and add it to your PATH. The existing v2 binary file is renamed helm2 and the latest version renamed to helm3. I will be two versions are stored in /usr/local/binso I can switch between them at any time:
➜ 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 prepare scripts and Chart
Before you run the upgrade process, you need to make sure your scripts and Custom Chart CI is compatible with Helm 3. Before I wrote an article ( https://itnext.io/breaking-changes-in-helm-3-and-how-to-fix-them-39fea23e06ff ), the article covers some things that need attention, which most can be easily resolved. Although OpenAPI authentication mechanism is interesting, but it is likely to make you by surprise:
➜ 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.VolumeMountOnce you solve all these problems trouble, then you can begin to migrate to Helm 3 it!
Configuration migration 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"