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
-
helm install
--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/acrReference
[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![Ajax——模闆引擎[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)