Helm版本升级差异文档

CCE云引擎调用：

描述 V2 V3
请求方式 grpc远程过程调用tiller提供的服务 使用Helm_v3版本官方提供的go语言sdk，封装提供restfulAPI服务
安装release hapi.services.tiller.ReleaseServiceGrpc.ReleaseServiceBlockingStub#installRelease POST /api/namespaces/:namespace/releases/:release?chart=
更新release hapi.services.tiller.ReleaseServiceGrpc.ReleaseServiceBlockingStub#updateRelease PUT /api/namespaces/:namespace/releases/:release?chart=
回滚release到上个版本 hapi.services.tiller.ReleaseServiceGrpc.ReleaseServiceBlockingStub#rollbackRelease PUT /api/namespaces/:namespace/releases/:release/versions/:reversion
删除release hapi.services.tiller.ReleaseServiceGrpc.ReleaseServiceBlockingStub#uninstallRelease DELETE /api/namespaces/:namespace/releases/:release
列举releases列表 hapi.services.tiller.ReleaseServiceGrpc.ReleaseServiceBlockingStub#listReleases GET /api/namespaces/:namespace/releases
获取release的健康状态 hapi.services.tiller.ReleaseServiceGrpc.ReleaseServiceBlockingStub#getReleaseStatus GET /api/namespaces/:namespace/releases/:release
获取release的详细信息 hapi.services.tiller.ReleaseServiceGrpc.ReleaseServiceBlockingStub#getReleaseContent GET /api/namespaces/:namespace/releases/:release
根据Release名称获取历史信息 hapi.services.tiller.ReleaseServiceGrpc.ReleaseServiceBlockingStub#getHistory GET /api/namespaces/:namespace/releases/:release/histories

Helm v3版本新增特性：

  • 移除了tiller组件，支持Kubernetes的安全、 身份和授权特性，通过kubeconfig文件授权

    helm v2版本通过helm init 命令，在k8s集群中安装一个叫tiller-deploy的容器，用于和集群交互。helm v3版本移除了tiller组件，也移除了helm init 命令，默认通过~/.kube/config与集群进行交互，也就是说使用了与kubctl相同的上下文访问权限，若不在默认位置可通过–kubeconfig参数进行指定。

  • 移除了helm serve

    helm serve 出于开发目的，运行本地chart repository，用于托管本地 local repo 中的 Chart 信息。它作为一种开发工具并没有得到太多的认可，并且在设计上存在许多问题。

  • 不同的 namespace 可以使用相同的 Release Name

    helm v2版本中release name存在tiller组件部署的命名空间下面，意味着一旦某个版本使用了一个名称，其他版本就不能使用相同的名称，即使它部署在不同的命名空间中。在 Helm 3 中，release 信息现在存储在与 release 本身相同的命名空间中，意味着 release name 是在租户下唯一。

  • 简化模板对象 .Capabilities

    .Capabilities内置对象会在已经简化的渲染阶段生效。

  • 改进升级策略: 三路策略合并补丁

    Helm 2 使用了一种双路策略合并补丁。在升级过程中，会对比最近一次的 chart manifest 和提出的 chart manifest (通过helm upgrade提供)。升级会对比两个chart的不同来决定哪些更改会应用到 Kubernetes 资源中。 如果更改是集群外带的（比如通过kubectl edit），则不会被考虑。结果就是资源不会回滚到之前的状态： 因为Helm只考虑最后一次应用的chart manifest作为它的当前状态，如果chart状态没有更改，则资源的活动状态不会更改。

    现在Helm 3中，我们使用一种三路策略来合并补丁。Helm在生成一个补丁时会考虑之前老的manifest的活动状态。

  • 使用JSONSchema验证 charts 的 Values

    在charts目录下创建values.schema.json配置需要验证的helm command(helm [install | upgrade | lint]),方便验证用户设置的value是否合法

  • 将requirements.yaml合并到Chart.yaml

    Chart依赖体系从 requirements.yaml 和 requirements.lock 移动到 Chart.yaml 和 Chart.lock。我们推荐在Helm 3的新chart中使用新格式。不过Helm 3 依然可以识别 Chart API 版本1 (v1) 并且会加载已有的 requirements.yaml 文件

  • 支持 push 到远端 registry （如：harbor），新增了helm chart/library [subcommand]命令

    #之前可以通过安装chartmuseum/helm-push插件，将chart推送到仓库

    #现在默认支持登录仓库、推送chart

    helm registry login –insecure 192.168.86.5
    helm chart save /root/mariadb 192.168.86.5/chart/mariadb:test
    helm chart push 192.168.86.5/chart/mariadb:test
    helm registry logout 192.168.86.5

  • 命令行变化（将原先的命令保留为别名Aliases）

    • helm delete –> helm uninstall
    • helm inspect -> helm show
    • helm fetch -> helm pull

  • go 导入路径改变 k8s.io/helm –> helm.sh/helm

    Helm 3 首次发布了完全重组的Go SDK，以便在构建利用Helm的软件和工具时有更好的体验。SDK导入路径改为了helm.sh/helm

  • helm 测试优化

    Helm v3中，任务定义需要包含helm的测试钩子注释之一：helm.sh/hook: test-success 或者 helm.sh/hook: test-failure。在Helm的一个版本中运行预定义的测试，执行 helm test <RELEASE_NAME>。对于chart用户来说， 这是验证chart Release（或应用）可以正常运行的很好的方式。

  • Library chart支持

    Helm 3 支持的一类chart称为 “library chart”。 这是一个被其他chart共享的chart， 但是它自己不能创建发布组件。library chart的模板只能声明 define 元素。

  • 作为默认存储器的密钥

    在 Helm 3中, 密钥被作为默认存储驱动使用。 Helm 2默认使用ConfigMaps记录版本信息。

  • Chart.yaml api版本切换

    Chart.yaml的apiVersion从 v1 切换到了 v2。helm v3 兼容支持v1，helm v2 不支持v2。

  • XDG 基本目录支持

    XDG 基本目录规范是一个定义了配置、数据和缓存文件应该存储在文件系统什么位置的可移植标准。Helm 3中，Helm现在遵守XDG 基本目录规范使用以下环境变量：

    • $XDG_CACHE_HOME
    • $XDG_CONFIG_HOME
    • $XDG_DATA_HOME

  • 自动创建namespace

    当用命名空间创建版本时，命名空间不存在，Helm 2会创建一个命名空间。 Helm 3中沿用了其他Kubernetes 工具的形式，如果命名空间不存在，就返回错误。 如果您明确指定 --create-namespace 参数，Helm 3 会创建一个命名空间。