为企业迁移到Helm v3的最佳实践

在JFrog，我们依靠Kubernetes和舵编排我们的系统，并保持我们的工作负载运行和最新。我们的JFrog云服务最初部署在Helm v2和Tillerless插件增强了安全性，但我们现在已经成功地将数千个版本迁移到了Helm v3。

与许多SaaS服务提供商一样，JFrog Cloud在不同地区与许多Kubernetes集群一起运行，包括AWS、Azure和Google云提供商。

在此过程中，我们学到了一些重要的经验教训，我很高兴与大家分享。

为什么迁移到Helm v3

虽然Helm v3的第一个版本于2019年11月发布，但Helm v2的更新版本继续支持了一年。但随着Helm 2.17.0的最终版本于2020年11月发布，Helm v3现在是Helm开发人员社区支持的唯一标准。

Helm v3提供了一些主要的改进最引人注目的是蒂勒的下台。这个与Helm v2客户端接口的集群内服务器需要管理员权限才能执行其职责，这在共享k8集群中被认为是一个安全风险。这是可以克服的Tillerless插件，但是Helm v3使这个不再必要。

此外，Helm v3提供了一些新功能和更高的稳定性。它现在也是唯一的版本，将接受未来的有效性和安全性更新。

移民战略

为了使集群从Helm v2迁移到v3更加容易，Helm开发人员社区创建了helm-2to3插件用于helm3客户端。一个Helm博客文章提供了一些关于如何使用它的有用信息。

安装插件很简单:

$ helm3 plugin install https://github.com/helm/helm-2to3

但是，根据需要迁移的发布版本的数量，接下来如何执行任务可能会有所不同。

手动迁移

如果您只需要迁移几个版本，那么您可以在命令行上通过客户机逐一迁移。

首先，你可以使用领导名单命令列出当前命名空间的所有已部署或失败的版本:

$ helm2 list名称修订更新状态图应用版本命名空间postgres 1星期四11月14日15:01:00 2019已部署postgresql-7.1.0 11.5.0 postgres

然后，您可以通过迁移插件执行每个命名版本的转换。我们建议使用——即将首先标记以确定转换将干净地运行。

$ helm3 2to3转换postgres

您可以对所有版本重复此过程，这样就完成了!

为企业自动化迁移

要将多个Helm v2版本迁移到v3，您需要使用shell脚本自动化该过程。

您的脚本将需要一个需要转换的所有版本的列表。您可以使用Helm v2客户端生成一个列表，在本例中生成一个名为releases.log。

# # # # # # # # # # # # # # # # # #p' | awk 'FNR > 1 {print $1}' > release .log

这可以在相对较少的版本(最多200个)中快速生成结果。然而，更重要的是，它将花费Helm客户端时间来获取它们。此外，我在使用AWS EKS集群时遇到了Kubernetes API限制。

JFrog云服务在每个Kubernetes集群上运行数千个Helm版本，因此需要一种替代的、更快的方法。因为所有蒂勒的秘密都有标签我们发现我们可以用kubectl命令将它们提取到releases.log文件:

$ kubectl -n kube-system获取secret -l OWNER=TILLER,STATUS=DEPLOYED | awk 'FNR > 1 {print $1}' | cut -f1 -d"."> releases.log

使用我们的Helm v2版本列表releases.log，我们可以使用bash脚本自动执行迁移步骤:

#！/bin/bash #获取版本列表release =$(cat release .log) for r在$ release中做echo echo "Processing release $r" helm3 2to3 convert——tiller-out-cluster——release-versions-max=5 \——delete-v2-releases——dry-run 2>&1 | tee -a convert.log done

在这个脚本中，你可能想要或需要改变这些标志:

• ——tiller-out-cluster如果没有在Kubenetes集群中运行Tiller，则使用;如果安装了分蘖，则应将其拆除。
• ——delete-v2-releases当Helm v2版本迁移到Helm v3时删除它们
• ——即将用于首先测试迁移脚本是否有效。在执行实际迁移时忽略。

如果你选择省略这个标志——delete-v2-releases并保留Helm 2版本，您可以稍后使用:

$ helm3 2to3 cleanup—tiller-out-cluster—release -cleanup—skip-confirmation

脚本将迁移结果捕获到一个文件中，convert.log您应该检查可能遇到的任何迁移问题。

在我们迁移JFrog云服务的过程中，并不是所有的发行版都使用相同的图表版本——它们使用的是首次部署时有效的图表。因此，迁移的一些旧版本无法使用Helm v3进行升级。

问题是一些Helm v3的标签和注解没有被添加到迁移的Kubernetes对象中。这很容易修复，当检查显示它们不存在时，将它们添加到Helm升级步骤:

$ kubectl -n ${NAMESPACE} label deployment -l "app.kubernetes. "io /实例= ${释放}”“app.kubernetes。$ kubectl -n ${NAMESPACE} annotate deployment -l "app.kubernetes. io/manage -by=Helm""meta.helm.sh/ RELEASE -name=${RELEASE}" "meta.helm.sh/ RELEASE - NAMESPACE =${NAMESPACE}"

快乐的迁移

这就是将您的版本迁移到Helm v3所需要做的一切!这个过程很简单，但请记住，它不一定很快。当有成千上万个版本时——就像在大多数企业级组织中一样——迁移过程确实需要时间来完成。

通过这些步骤，您可以创建一个自动化工具，它可以帮助您将运行在Kubernetes中的大量版本从Helm v2迁移到Helm v3，并使Kubernetes基础架构保持最新状态。