这篇文章主要介绍“怎么一次性完成Helm3迁移”，在日常操作中，相信很多人在怎么一次性完成Helm3迁移问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”怎么一次性完成Helm3迁移”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
屯溪ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为创新互联公司的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：13518219792（备注：SSL证书合作）期待与您的合作！
我们测试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是否与Helm 3兼容。尽管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啦！
如果你在诸如Jenkins、TeamCity或TravisCI之类的CI系统中的构建代理运行Helm，那么可以这一步骤。如果你在本地机器或有持久文件系统的中央服务器中运行Helm，那么一定要在整个配置中进行迁移，尤其是当你拥有自己的Helm repo或使用自定义插件时。无论哪种方式，请确保你已经通读了这一部分，以确定是否与你有关。
现在，我们有几种方式可以实现迁移。你可以迁移特定版本到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删除。如果你确定自己不再需要任何信息，你可以执行这一操作，风险自担。
这一步是我最不想略过的一步，以防万一我们需要回滚到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-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"
到此，关于“怎么一次性完成Helm3迁移”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！