深度解讀Helm 3: 猶抱琵琶半遮面
自去年年初開始放風Helm v3將要開始開發,到去年年底KubeConn 上海被一堆人追問到底啥時候發版本。今年五月份,Helm v3 終於釋出了第一個alpha版本,讓我們來一窺新版本的Helm 到底帶來了什麼。
Removal of Tiller
Helm 3最大的期待莫過於移除掉Tiller。很難想象一個開源專案,移除其中的一個核心元件會受到如此巨大的歡迎,其實毫不吝嗇的說,Helm v3 alpha 1最大的功能就是去除了tiller。
由於歷史原因,tiller 在叢集應用版本管理和查詢上扮演了重要的角色。但是隨著RBAC等許可權控制體系的元件完善,多租戶和安全的需求日益興起,tiller變得越來越不安全,社群在許可權控制領域遇到了極大的阻礙。
移除tiller的好處主要有一下幾點:
- 更加簡單和靈活的架構
- 可以直接使用Kubernetes API互動
- 客戶端渲染Chart, 在Kubernetes叢集中儲存release資訊
- 客戶使用壁壘更加的降低
CLI changes
helm delete
--->helm uninstall
: 曾經完全刪除一個release需要helm delete xxx --purge
, 現在只需要uninstall
就可以,purge
會作為一個預設的行為helm inspect
--->helm show
helm fetch
--->helm pull
: 與docker pull
看齊,為下一步相容registry 做鋪墊,像拉取映象一樣拉取Chart部署
Breaking Changes (Warning)
-
Namespaces changes
Helm v2 只使用tiller 的namespace 作為release資訊的儲存,這樣全叢集的release名字都不能重複。Helm v3只會在release安裝的所在namespace記錄對應的資訊,這樣不同的namepsace就可以出現相同名字的release。
同樣的原因,如果已經使用Helm v2建立了release,那麼就無法使用helm v3來進行升級操作,因為無法將原來的單一namespace資訊遷移到所屬namespace 下。這一塊的遷移功能,社群正在緊鑼密鼓的開發中
-
Chart dependency management
- 老版本通過requirements.yaml和requirements.lock 來管理Chart的依賴,一個requirements.yaml 一般長相如下
dependencies: - name: mariadb version: 5.x.x repository: https://kubernetes-charts.storage.googleapis.com/ condition: mariadb.enabled tags: - database
- 新版本直接使用Chart.yaml 來記錄依賴資訊,新的Chart.yaml格式和requirements.yaml 基本相同
dependencies: - name: mariadb version: 5.x.x repository: https://kubernetes-charts.storage.googleapis.com/ condition: mariadb.enabled tags: - database
-
Generate Name
老版本Helm 可以直接安裝chart 並不需要指定名稱,Helm v3需要指定名稱
Try
我們來試用一下Helm v3, 下載地址在這裡https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1。 為了防止與已經安裝的Helm v2衝突,我們需要設定一下
$HELM_HOME set an alternative location for Helm files. By default, these are stored in ~/.helm
,比如放到/tmp目錄下。安裝完畢後,helmv3 init
初始化一下就可以使用。
我們使用wordpress為例子
[root@iZ8vbbnhdit552y4lytxpiZ ~]# ./helmv3 install stabel/wordpress
[root@iZ8vbbnhdit552y4lytxpiZ ~]# ./helmv3 ls
NAME NAMESPACE REVISION UPDATED STATUS CHART
test-v3 default 1 2019-05-27 16:50:46.100265945 +0800 CST deployed wordpress-0.6.13
可以看到,目前已經存在的Chart可以完全無縫遷移到helmv3 ,完全相容。只是不需要tiller 來協助安裝。以前Helm v2儲存的release 都在tiller 所在的namespace。
[root@iZ8vbbnhdit552y4lytxpiZ ~]# kubectl get cm -n kube-system -l OWNER=TILLER
NAME DATA AGE
wordpress-default.v1 1 26h
wordpress-default.v2 1 26h
wordpress-default.v3 1 26h
這就是Helm v2儲存release 資訊的地方,可以看到都在kube-system
名稱空間下。
[root@iZ8vbbnhdit552y4lytxpiZ ~]# kubectl get secret | grep word
test-v3-wordpress Opaque 2 26h
wordpress-default-mariadb Opaque 2 26h
wordpress-default-wordpress Opaque 2 26h
在看Helm v3,所有的資訊都儲存在release對應的namespace 下,而且以secret儲存。這是v2和v3很不相同的地方。
Migrate from v2 to v3
- 針對目前已經存在的chart, helm v3可以無縫安裝,無需遷移
- v2與v3可以共存,tiller 可以繼續存在
-
已經使用v2安裝的release,不能通過v3來升級,檢視
Pushing Charts to OCI Registries
在如何遠端託管Chart這件事上,經歷了很多次的發展。最初是儲存在本地,然後是打成壓縮包,上傳到oss 等遠端儲存,然後社群出現了Chartmuseum 這樣的開源工具,提供公共的Chart託管。但是關於許可權認證等方便並沒有很好的解決方案。同時在後端儲存方面,也沒有能像Docker Registry 那樣很好的節省空間避免重複儲存的功能。
因此所有的目光都轉向了Docker Registry,畢竟目前各大廠商都已經提供了映象託管功能,能否複用這個能力來託管Chart是一個很好的方向。由此微軟推出了 OCI Registry As Storage。根據映象 OCI 標準規範,複用Registry 來儲存Chart。這個目前已經整合到Helm v3試驗版本里面。
我們來試用一下這個功能.
首先本地啟動一個registry
docker run -dp 5000:5000 --restart=always --name registry registry:2
然後下載一個chart包helm fetch stable/wordpress
[root@iZ8vbbnhdit552y4lytxpiZ ~]# ./helmv3 chart save wordpress localhost:5000/wordpress:latest
Name: wordpress
Version: 0.6.13
Meta: sha256:83c48dd3c01a2952066ead67023ea14963a88db4287650baad5ea1ddd8ff9590
Content: sha256:248c8c68f4f614003c8b1a9d78787e5f07e979e9b996981df993cf380f498c97
latest: saved
[root@iZ8vbbnhdit552y4lytxpiZ ~]# ./helmv3 chart list
REF NAME VERSION DIGEST SIZE CREATED
localhost:5000/wordpress:latest wordpress 0.6.13 248c8c6 12.0 KiB 11 seconds
[root@iZ8vbbnhdit552y4lytxpiZ ~]# ./helmv3 chart push localhost:5000/wordpress:latest
The push refers to repository [localhost:5000/wordpress]
Name: wordpress
Version: 0.6.13
Meta: sha256:83c48dd3c01a2952066ead67023ea14963a88db4287650baad5ea1ddd8ff9590
Content: sha256:248c8c68f4f614003c8b1a9d78787e5f07e979e9b996981df993cf380f498c97
latest: pushed to remote (2 layers, 12.6 KiB total)
這樣就完成了將Chart 推送到Registry的功能。這個功能目前處於實驗性質,社群還是希望未來大家能夠都轉到這種儲存方式上來。
What's Next
- alpha1: 移除Tiller, 提供Library charts, 儲存格式改成secret, 開始OCI整合工作
- alpha2: 更好的 OCI 整合,Lua 模板支援
- alpha3: 重構更新策略(可能是客戶端側進行,也可能是服務端側進行)
容器服務 Kubernetes 版(ACK)
阿里雲容器服務是 Kubernetes 認證服務提供商(KCSP),國內唯一進入 Gartner 競爭格局的公有云容器平臺。容器服務 Kubernetes 版(ACK)是安全穩定的企業級容器平臺,支援高效能網路和儲存,提供面向應用的異構資源統一管理,為企業上雲提供最佳雲原生支援。
本文作者:xianlubird
本文為雲棲社群原創內容,未經