从 Helm v2 迁移到 v3

本指南介绍如何将 Helm v2 迁移到 v3。需要安装 Helm v2 并管理一个或多个集群中的发布版本。

Helm 3 变更概述

Helm 2 到 3 的所有变更都在 常见问题解答部分 中记录。以下是对用户在迁移之前和期间应该注意的一些变更的总结。

  1. 删除 Tiller
    • 用客户端/库架构替换客户端/服务器架构(仅 helm 二进制文件)
    • 安全性现在基于每个用户(委托给 Kubernetes 用户集群安全性)
    • 发布版本现在存储为集群内密钥,并且发布版本对象元数据已更改
    • 发布版本现在根据发布版本命名空间持久化,不再位于 Tiller 命名空间中
  2. 图表仓库已更新
    • helm search 现在支持本地仓库搜索和对 Artifact Hub 进行搜索查询
  3. 图表 apiVersion 升级为 "v2" 以遵循规范变更
    • 动态链接的图表依赖项已移至 Chart.yamlrequirements.yaml 已删除,requirements --> dependencies)
    • 库图表(辅助/通用图表)现在可以作为动态链接的图表依赖项添加
    • 图表具有一个 type 元数据字段,用于定义图表为 applicationlibrary 图表。默认情况下为 application,这意味着它可渲染和安装
    • Helm 2 图表 (apiVersion=v1) 仍然可以安装
  4. 添加了 XDG 目录规范
    • Helm home 已删除,并替换为 XDG 目录规范,用于存储配置文件
    • 不再需要初始化 Helm
    • helm inithelm home 已删除
  5. 其他更改
    • Helm 安装/设置已简化
      • 仅 Helm 客户端(helm 二进制文件)(没有 Tiller)
      • 按原样运行模式
    • 默认情况下不会设置 localstable 仓库
    • crd-install 钩子已删除,并替换为图表中的 crds 目录,其中定义的所有 CRD 将在渲染图表之前安装
    • test-failure 钩子注释值已删除,test-success 已弃用。请改用 test
    • 已删除/替换/添加的命令
      • delete --> uninstall:默认情况下删除所有发布版本历史记录(以前需要 --purge
      • fetch --> pull
      • home(已删除)
      • init(已删除)
      • install:需要发布版本名称或 --generate-name 参数
      • inspect --> show
      • reset(已删除)
      • serve(已删除)
      • template:-x/--execute 参数已重命名为 -s/--show-only
      • upgrade:添加了参数 --history-max,用于限制每个发布版本保存的最大修订次数(0 表示无限制)
    • Helm 3 Go 库已发生很大变化,与 Helm 2 库不兼容
    • 发布版本二进制文件现在托管在 get.helm.sh

迁移用例

迁移用例如下

  1. Helm v2 和 v3 管理同一个集群

    • 仅当您打算逐步淘汰 Helm v2 并且不需要 v3 管理 v2 部署的任何发布版本时,才建议使用此用例。所有正在部署的新发布版本都应由 v3 执行,而现有的 v2 部署的发布版本仅由 v2 更新/删除
    • Helm v2 和 v3 可以很好地管理同一个集群。Helm 版本可以安装在相同或不同的系统上
    • 如果在同一系统上安装 Helm v3,则需要执行一个额外的步骤以确保两个客户端版本可以共存,直到准备删除 Helm v2 客户端。重命名或将 Helm v3 二进制文件放在不同的文件夹中以避免冲突
    • 否则,由于以下区别,两个版本之间不存在冲突
      • v2 和 v3 发布版本(历史记录)存储相互独立。变更包括用于存储的 Kubernetes 资源和资源中包含的发布版本对象元数据。发布版本也将位于每个用户命名空间,而不是使用 Tiller 命名空间(例如,v2 默认 Tiller 命名空间 kube-system)。v2 使用 Tiller 命名空间下的 "ConfigMaps" 或 "Secrets" 以及 TILLER 所有权。v3 在用户命名空间中使用 "Secrets" 以及 helm 所有权。发布版本在 v2 和 v3 中都是增量的
      • 唯一的问题可能是如果 Kubernetes 集群范围的资源(例如 clusterroles.rbac)在图表中定义。即使在命名空间中是唯一的,v3 部署也会失败,因为资源会发生冲突
      • v3 配置不再使用 $HELM_HOME,而是使用 XDG 目录规范。它也会在需要时动态创建。因此,它独立于 v2 配置。这仅适用于在同一系统上安装两个版本的情况
  2. 将 Helm v2 迁移到 Helm v3

    • 当您希望 Helm v3 管理现有的 Helm v2 发布版本时,此用例适用
    • 需要注意的是,Helm v2 客户端
      • 可以管理 1 到多个 Kubernetes 集群
      • 可以连接到集群的 1 到多个 Tiller 实例
    • 这意味着您在迁移时必须意识到这一点,因为发布版本是由 Tiller 及其命名空间部署到集群中的。因此,您必须注意为 Helm v2 客户端实例管理的每个集群和每个 Tiller 实例进行迁移
    • 推荐的数据迁移路径如下
      1. 备份 v2 数据
      2. 迁移 Helm v2 配置
      3. 迁移 Helm v2 发布版本
      4. 当确信 Helm v3 正如预期的那样管理所有 Helm v2 数据(对于 Helm v2 客户端实例的所有集群和 Tiller 实例)时,请清理 Helm v2 数据
    • 迁移过程由 Helm v3 2to3 插件自动完成

参考

  • Helm v3 2to3 插件
  • 解释 2to3 插件用法并提供示例的博客 文章