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
於是在 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
本文作者：予棲
本文為雲棲社群原創內容，未經