Helm V3 新版本发布

Helm v3.0.0 Alpha 1 is coming!

Helm 做为 Kubernetes 体系的包管理工具，已经逐渐成为了事实上的应用分发标准。根据 2018 年 CNCF 的一项云原生用户调研，超过百分之六十八用户选择 Helm 来做为应用打包交付方式。在开源社区中，愈来愈多的软件被搬迁到 Kubernetes 集群上，它们中的绝大部分都是经过 Helm 来进行交付的。

Helm 当前的稳定版本为 v2.14.0，最新发布的测试版本为 v3.0.0-alpha.1。v3.x 的 alpha 版本可谓千呼万唤始出来，它带来了很是多的新特性及优化改进，让人无比兴奋，所以做此文以总结安利一番。

架构性变化 - 去除了 Tiller

在 Helm 2 中，一次基于 Helm 的软件交付会涉及到多个组件：

在 Helm 2 中，Tiller 是做为一个 Deployment 部署在 kube-system 命名空间中，不少状况下，咱们会为 Tiller 准备一个 ServiceAccount ，这个 ServiceAccount 一般拥有集群的全部权限。用户可使用本地 Helm 命令，自由地链接到 Tiller 中并经过 Tiller 建立、修改、删除任意命名空间下的任意资源。

然而在多租户场景下，这种方式也会带来一些安全风险，咱们即要对这个 ServiceAccount 作不少剪裁，又要单独控制每一个租户的控制，这在当前的 Tiller 模式下看起来有些不太可能。

因而在 Helm 3 中，Tiller 被移除了。新的 Helm 客户端会像 kubectl 命令同样，读取本地的 kubeconfig 文件，使用咱们在 kubeconfig 中预先定义好的权限来进行一系列操做。这样作法即简单，又安全。

虽然 Tiller 文件被移除了，但 Release 的信息仍在集群中以 ConfigMap 的方式存储，所以体验和 Helm 2 没有区别。

Tiller 变动引入的新变化 - Release 再也不是全局资源

在 Helm 2 中，Tiller 自身部署每每在 kube-system 下，虽然不必定是 cluster-admin 的全局管理员权限，可是通常都会有 kube-system 下的权限。当 Tiller 想要存储一些信息的时候，它被设计成在 kube-system 下读写 ConfigMap 。

在 Helm 3 中，Helm 客户端使用 kubeconfig 做为认证信息直接链接到 Kubernetes APIServer，不必定拥有 cluster-admin 权限或者写 kube-system 的权限，所以它只能将须要存储的信息存在当前所操做的 Kubernetes Namespace 中，继而 Release 变成了一种命名空间内的资源。

Values 支持 JSON Schema 校验器

Helm Charts 是一堆 Go Template 文件、一个变量文件 Values 和一些 Charts 描述文件的组合。Go Template 和 Kubernetes 资源描述文件的内容十分灵活，在开发迭代过程当中，很容易出现一些变量未定义的问题。Helm 3 引入了 JSON Schema 校验，它支持用一长串 DSL 来描述一个变量文件的格式、检查全部输入的变量的格式。

当咱们运行 helm install 、 helm upgrade 、 helm lint 、 helm template 命令时，JSON Schema 的校验会自动运行，若是失败就会当即报错。

一个来自官方的例子

当咱们指定一个 JSON Schema 文件为下述时：

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "properties": {
    "image": {
      "description": "Container Image",
      "properties": {
        "repo": {
          "type": "string"
        },
        "tag": {
          "type": "string"
        }
      },
      "type": "object"
    },
    "name": {
      "description": "Service name",
      "type": "string"
    },
    "port": {
      "description": "Port",
      "minimum": 0,
      "type": "integer"
    },
    "protocol": {
      "type": "string"
    }
  },
  "required": [
    "protocol",
    "port"
  ],
  "title": "Values",
  "type": "object"
}

咱们看到 JSON Schema 描述文件中指定了 protocol 和 port 为必填字段，因而咱们能够指定一个 values.yaml 以下：

name: frontend
protocol: https
port: 443

但事实上，咱们也能够指定为以下，由于咱们能够在 helm 命令行传入变量参数，例如 helm install --set port=443 

name: frontend
protocol: https

试验性功能 - 推送 Charts 到容器镜像仓库中

互联网上有一些 Helm Charts 托管平台，负责分发常见的开源应用，例如 Helm Hub、KubeApps Hub。

在企业环境中，用户须要私有化的 Helm Charts 托管。最多见的方案是部署 ChartMuseum，使其对接一些云存储。固然也有一些较为小众的方案，好比 [App-Regsitry]() 直接复用了 Docker 镜像仓库 Registry V2，再好比 helm-s3 直接经过云存储 S3 存取 Charts 文件。

现在在 Helm 3，Helm 直接支持了推送 Charts 到容器镜像仓库的能力，但愿支持知足 OCI 标准的全部 Registry。但这部分尚未彻底被开发完，会在将来的 alpha 版本中被完善。

代码复用 - Library Chart 支持

Helm 3 中引入了一种新的 Chart 类型，名为 Library Chart 。它不会部署出一些具体的资源，只能被其余的 Chart 所引用，提升代码的可用复用性。当一个 Chart 想要使用该 Library Chart 内的一些模板时，能够在 Chart.yaml 的 dependencies 依赖项中指定。

其余的一些变化

• Go Import 的路径由 k8s.io/helm 变成了 helm.sh/helm。
• 简化了 Chart 内置变量 Capabilities 的一些属性[2]。
• helm install 再也不默认生成一个 Release 的名称，除非指定了 --generate-name 。
• 移除了用于本地临时搭建 Chart Repository 的 helm serve 命令。
• helm delete 改名为 helm uninstall ， helm inspect 改名为 helm show ， helm fetch 改名为 helm pull ，但以上旧的命令当前仍能使用。
• requirements.yaml 被整合到了 Chart.yaml 中，但格式保持不变。

如今怎么办呢？

当前 Helm 3 仍在紧张而有序地开发当中，若是须要在生产环境使用，Helm 2 看起来会更加稳妥一些。

若是您刚好须要私有的 Helm Chart 仓库，欢迎申请试用阿里云容器镜像服务企业版（ACR EE），咱们即将上线 Helm Charts 托管功能。

阿里云容器镜像服务（ACR）是国内最大的公有云镜像服务平台，支撑数万名开发者，共计十亿级别的镜像拉取，为开发者的每一个应用镜像保驾护航。容器镜像服务企业版（ACR EE）是新推出的面向企业级客户的安全镜像托管平台，支持镜像服务企业版实例独享部署、OSS Bucket 独享加密存储、自定义网络访问控制及 P2P 大规模镜像分发功能。点击了解产品详情 https://www.aliyun.com/product/acr

Reference

[1] CNCF Survey: Use of Cloud Native Technologies in Production Has Grown Over 200% https://www.cncf.io/blog/2018/08/29/cncf-survey-use-of-cloud-native-technologies-in-production-has-grown-over-200-percent/
[2] The Chart Template Developer’s Guide https://v3.helm.sh/docs/chart_template_guide/#built-in-objects

 

本文做者：予栖

原文连接

本文为云栖社区原创内容，未经容许不得转载。