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

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

与许多SaaS服务提供商一样，JFrog Cloud与不同地区的许多Kubernetes集群一起运行，跨越AWS、Azure和谷歌云提供商。

在这个过程中，我们学到了一些重要的经验，我很乐意与大家分享。

为什么迁移到Helm v3

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

Helm v3提供了一些主要改进最引人注目的是蒂勒的离职。这个与Helm v2客户端交互的集群内服务器需要管理员特权来执行其职责，这被认为是共享K8s集群中的安全风险。这可以通过Tillerless插件，但Helm v3使这不再必要。

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

移民策略

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

安装插件很简单:

$ helm3插件安装https://github.com/helm/helm-2to3

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

手动迁移

如果您只需要迁移几个版本，您可以通过命令行上的客户端一个接一个地迁移。

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

应用版本命名空间postgres 1 Thu 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．

$ helm2分蘖运行——helm2 ls——max=0 | sed -n '1!p' | awk 'FNR > 1 {print $1}' >释放.log

这对于相对较少的发布(最多200个左右)产生了快速的结果。然而，远不止于此，Helm客户端需要很长时间才能将它们全部获取。此外，我在AWS EKS集群中遇到了Kubernetes API限制。

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

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

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

#！/bin/bash #获取释放列表中的释放=$(cat releases.log) for r in $ releases执行echo echo "Processing release $r" helm3 2to3 convert——分列-out-cluster——release-versions-max=5 \——delete-v2-releases——干运行2>&1 | tee -a convert.log done

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

• ——tiller-out-cluster如果在Kubenetes集群中没有运行Tiller，则使用该选项;如果安装了分蘖，则应将其移除。
• ——delete-v2-releases删除头盔v2版本时，他们被迁移到头盔v3
• ——即将用于测试迁移脚本是否首先工作。执行实际迁移时省略。

如果您选择省略标志——delete-v2-releases并保持Helm 2释放，你可以稍后用:

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

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

在我们迁移JFrog云服务的过程中，并不是所有的发布都在同一个图表版本上——他们使用的图表在第一次部署时是有效的。因此，一些已迁移的旧版本未能使用Helm v3进行升级。

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

$ kubectl -n ${NAMESPACE} label deploy -l "app.kubernetes. xml "io /实例= ${释放}”“app.kubernetes。app.kubernetes. io/managed-by=Helm" $ kubectl -n ${NAMESPACE}注解部署-l "io/instance=${RELEASE}" "meta.helm.sh/ RELEASE -name=${RELEASE}" "meta.helm.sh/ RELEASE - NAMESPACE =${NAMESPACE}"

快乐的迁移

这就是将您的版本迁移到Helm v3所需要的全部内容!这个过程很简单，但请记住，它不一定很快。当有成千上万个版本时(大多数企业级组织都会有这样的版本)，迁移过程真的需要时间来完成。

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