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://juejin.im/post/5cee310ce51d4576bc1a0d86

總結

以上是生活随笔為你收集整理的Helm V3 新版本发布的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。