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 大規模鏡像分發功能。

 

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。