关于devops:从Helm2迁移到-Helm-v3-的最佳实践

10次阅读

共计 2781 个字符，预计需要花费 7 分钟才能阅读完成。

在 JFrog，咱们依附 Kubernetes 和 Helm 来编排咱们的零碎并放弃咱们的工作负载运行并放弃最新状态。咱们的 JFrog Cloud 服务最后应用 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 提供了一些重大改良，最显着的是删除了 Tiller。这个集群内的服务器与 Helm v2 客户端交互的须要管理员权限能力执行其职责，这被认为是共享 K8S 集群中的平安危险。这能够通过 Tillerless 插件来克服，但 Helm v3 不再须要这样做。

此外，Helm v3 提供了一些新性能和更高的稳定性。它当初也是惟一一个会在将来取得有效性和安全性更新的版本。

迁徙策略
为了更轻松地将集群从 Helm v2 迁徙到 v3，Helm 开发人员社区创立了 helm-2to3 插件以与 helm3 客户端一起应用。这里有一篇 Helm 博客文章提供了无关如何应用它的一些很好的信息。

装置插件很简略：
$ helm3 plugin install https://github.com/helm/helm-…

然而您接下来如何执行工作可能会依据您须要迁徙的版本数量而有所不同。

手动迁徙
如果您只须要迁徙几个版本，您能够通过客户端在命令行上进行一一迁徙。

首先，您能够应用 helm list 命令列出以后命名空间的所有已部署或失败的版本：

$ helm2 list
NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE
postgres 1 Thu Nov 14 15:01:00 2019 DEPLOYED postgresql-7.1.0 11.5.0 postgres

而后，您能够通过迁徙插件执行每个命名版本的转换。咱们倡议首先应用 –dry-run 标记来做一下预演，以确保之后的转换运行没问题。

$ helm3 2to3 convert –dry-run postgres
$ helm3 2to3 convert postgres

您能够对所有版本反复此过程，您就实现了！

企业级的自动化迁徙

要将多个 Helm v2 版本迁徙到 v3，您须要应用 shell 脚本自动化该过程。

您的脚本将须要转换的所有版本的列表。您能够应用 Helm v2 客户端生成一个列表，在本例中生成一个名为 release.log 的文件。

$ helm2 tiller run — helm2 ls –max=0 | sed -n ‘1!p’ | awk ‘FNR > 1 {print $1}’ > releases.log

对于绝对较少的版本（最多约 200 个），这会产生疾速的后果。
然而，更多的状况下，Helm 客户端须要很长时间能力获取所有版本。
此外，我遇到了 AWS EKS 集群的 Kubernetes API 限度。

JFrog Cloud 服务在每个 Kubernetes 集群上运行数千个 Helm 版本，因而须要一种代替的、更快的办法。

因为所有 Tiller secrets 都被标记了，咱们发现咱们能够应用 kubectl 命令将它们提取到 releases.log 文件中：

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

应用咱们在 releases.log 中的 Helm v2 版本列表，咱们能够应用 bash 脚本主动执行迁徙步骤：

RELEASES=$(cat releases.log)
for r in $RELEASES
do
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，则应用；如果装置了 Tiller，则应将其删除。
–delete-v2-releases 在迁徙到 Helm v3 后删除 Helm v2 版本
–dry-run 用于测试迁徙脚本是否工作，不真正执行，执行理论迁徙时须要删除此参数

如果您抉择省略标记 –delete-v2-releases 并保留 Helm 2 版本，您能够稍后应用以下命令清理它们：

$ helm3 2to3 cleanup –tiller-out-cluster –releases-cleanup –skip-confirmation

该脚本在文件 convert.log 中查看迁徙后果，您应该查看该文件以理解可能遇到的任何迁徙问题。

在咱们迁徙 JFrog Cloud 服务时，并非所有版本都在同一 chart 版本上——它们应用了首次部署时无效的 charts。所以一些迁徙的旧版本无奈应用 Helm v3 降级。

问题是一些 Helm v3 标签和正文没有被增加到迁徙的 Kubernetes 对象中。当查看显示它们不存在时，通过将它们增加到 Helm 降级步骤很容易解决这个问题：

$ kubectl -n ${NAMESPACE} label deployment -l “app.kubernetes.io/instance=${RELEASE}” “app.kubernetes.io/managed-by=Helm”

$ kubectl -n ${NAMESPACE} annotate deployment -l “app.kubernetes.io/instance=${RELEASE}” “meta.helm.sh/release-name=${RELEASE}” “meta.helm.sh/release-namespace=${NAMESPACE}”

让咱们开心迁徙吧🙂
这就是将您的版本迁徙到 Helm v3 所需的全部内容！
这个过程很简略，但请记住，它不肯定很快。
当有数千个版本时——就像在大多数企业级组织中一样——迁徙过程的确须要工夫来实现。

应用这些步骤，您能够创立一个自动化工具，帮忙您将在 Kubernetes 中运行的大量版本从 Helm v2 迁徙到 Helm v3，并使您的 Kubernetes 基础设施放弃最新。

正文完