系列介紹：這個系列是介紹如何用雲原生技術來建構、測試、部署、和管理應用的内容專輯。做這個系列的初衷是為了推廣雲原生應用管理的最佳實踐，以及傳播開源标準和知識。在這個系列文章的開篇 初探雲原生應用管理（一）: Helm 與 App Hub
中，我們介紹了如何用 Helm 來快速部署 K8s 應用。在本篇文章我們将跟你聊聊，為什麼要盡快轉向 Helm V3。
在研究了一番“
開放雲原生應用中心（AppHub）”之後，程式員小張似乎已經明白了“雲原生應用”到底是怎麼一回事情。
“不就是 Helm 嘛！”
說話間，小張就準備把自己開發多年的“圖書館管理系統”通過 Helm 打包成 Charts ，送出到
AppHub上個線試試。
“這樣，全中國的開發者就都能使用到我開發的圖書館管理系統了！”
想想還有點小激動呢！
然而，還沒等編譯完，小張就發現 Helm 官方文檔上有這麼一句提示非常辣眼睛：
Helm 項目的緣起
Helm 是目前雲原生技術體系中進行應用管理最被廣泛使用的開源項目，沒有之一。根據 CNCF 剛剛釋出的
KubeCon EU 2019 的總結報告，Kubernetes（ k8s ），Prometheus 和 Helm 這三個項目，再次蟬聯 KubeCon 上最被關注的開源項目前三名。
Helm 項目本身的釋出，則要追述到 Deis 還是一家獨立創業公司的時代。
2016 年，容器 PaaS （所謂的 CaaS ）創業方興未艾，但也開始呈現出同質化競争和低附加值的種種苗頭，而在這片紅海當中，當時已經委身賣給 Engine Yard 的 Deis 尤其步履維艱。幸運的是，敏銳的技術嗅覺最終還是“拯救”了這個的團隊。 2016 年底，Deis 開始全面轉向 K8s 體系，很快就釋出了一系列專門為 k8s 進行應用管理的開源項目。這其中，定位為“ k8s 應用包管理器”的 Helm ，是最受歡迎的一個。
我們知道，K8s 本身是沒有“應用”這個概念的。比如，小張要在 K8s 上部署的“圖書館管理系統”，實際是由四個 YAML 檔案組成的：
- web-deploy.yaml ，用 K8s 的 Deployment 描述的 Java Web 程式；
- web-svc.yaml ，用 K8s 的 Service 描述的程式通路的入口；
- mysql.yaml ，用 K8s StatefulSet 描述的 MySQL 執行個體；
- mysql-svc.yaml ，用 K8s Service 描述的 MySQL 執行個體的通路入口。
然後，小張需要執行四次
`kubectl apply -f` 把這些 YAML 檔案都送出給 K8s 來負責運作和管理這個應用。這裡面的麻煩之處在于，怎麼樣去管理這個應用對應的所有 k8s 資源？
于是 Helm 項目提供了一種簡單的思路：它定義了一種新的應用打包格式叫 Chart 。一個 myapp 應用的檔案布局如下所示：
myapp/
Chart.yaml
values.yaml
templates/ 其中，Chart.yaml 裡面用來寫應用中繼資料，比如：
apiVersion: v1
name: 圖書館管理系統
version: 0.1
description: 全中國最受歡迎的圖書館管理系統
maintainers:
- name: 小張 在 templates/ 目錄下，則存放小張編寫好的四個 YAML 檔案。
此外，小張還可以将這些 YAML 裡需要修改的字段定義成“模闆變量”，在部署時由 Helm 去負責注入。比如 web-deploy.yaml ：
apiVersion: apps/v1
kind: Deployment
metadata:
name: 圖書館管理系統網站
spec:
replicas: {{ .Values.replicaCount }}
template:
...
spec:
containers:
... 通過上面的文法，小張就把這個 Deployment 的 replicas 值定義成了一個變量，将來就可以在部署的時候通過傳參來決定這個圖書館管理系統啟動後具體有幾個執行個體了，比如，指定 100 個執行個體：
helm install apphub/圖書館管理系統 --set replicaCount=100 最後，Helm 項目允許你把上面這一系列檔案和目錄，做成一個壓縮包上傳到網上，進而被别人通過 helm install 下載下傳安裝到。這個上傳的位址，就是 Helm Hub 了。
這種應用打包的方法，很大程度上解決了 K8s 應用管理困難的問題，是以在推出之後就很快赢得了開發者的青睐。而 Helm Hub 也成為了繼 Docker Hub 之後雲原生技術體系裡第二個重要的應用分發中心。
Helm 的架構問題
不過，上面這個流程聽起來很簡單，但是 Helm 在項目的一開始設計中，卻使用了一種讓人“匪夷所思”的架構。
可以想象，無論是安裝還是更新應用，Helm 其實都可以在用戶端調用 K8s API 來完成這些功能。但現實情況是，Helm 一定需要在 Kubernetes 叢集裡部署了一個叫做 Tiller 的 Server 端，然後把請求都送出給 Tiller ，再由 Tiller 去跟 K8s APIServer 進行互動，完成應用的安裝操作，這個複雜的過程，可以用下圖表示清楚：
而這個“畫蛇添足”的架構，不但成為了 Helm 釋出之處的一個假設，也貫穿了 Helm v2 的整個項目生命周期。
為什麼 Helm 要堅持在 K8s 放置一個 Server 端呢？
這裡其中一個重要的原因，在于 Helm 項目并不隻希望做一個簡單“ K8s 應用打包工具”。
作為一個道地的 PaaS 服務商，Deis 公司從一開始就知道“應用打包”隻是自己完整拼圖的入口，而 Tiller 的存在，則是讓 Helm 成為未來雲原生時代“新 PaaS” 的重要伏筆。
Tiller 這個服務端元件，其實相當于 Helm 在 K8s 内插入的一個應用管理控制器。有了它，Helm 不僅可以很容易在 K8s 側存儲應用相關的狀态，還可以基于 Tiller 在 K8s 内逐漸建構出一個微型 PaaS 的功能。并且，這些功能的設立和發展，都不需要依賴于 K8s 本身的應用管理能力。
這也解釋了為何 Helm 很快就提出了 Release 的概念，釋出了 helm upgrade 、 helm rollback 等應用更新和復原的能力。這些設計，其實都與 Helm 最終 PaaS 化的思路有着千絲萬縷的聯系。
Helm v3：迫不得已與勢在必行
不過，Helm 的這條演進路線，在 Kubernetes 這個天生以“應用”為中心的基礎設施體系裡，卻實實在在的栽了個跟頭。
我們知道，Kubernetes 是圍繞着聲明式 API 來設計的。Kubernetes 的容器編排理念以及 APIServer 實作與擴充機制，其本質目的都是為了幫助使用者屏蔽掉基礎設施管理的複雜性，允許使用者通過統一而整潔的聲明式 API 來描述自己的意圖和訴求，這正是 Kubernetes 成為“ The Platform of Platform ”的重要基礎。
這也是為何，Kubernetes 從一開始就對容器進行組合，以便借助 Pod 的概念來模拟程序組的行為；并且堅持使用聲明式 API 搭配控制器模型來進行應用編排，通過 API 資源對象的建立與更新（ PATCH ）來驅動整個系統的持續運轉。
這種設計的最終效果，就是使用者隻需要将一個“描述”應用的 YAML 檔案，放在 etcd 裡存起來，然後通過控制器模型驅動整個基礎設施的狀态不斷地向使用者聲明的狀态逼近，就也就是 Kubernetes 的核心工作原理了。這套理論，正是 Google Borg/Omega 進行應用管理和編排的核心與基礎，同時也是 K8s 同 Mesos 這種資料總管項目最大的差別。
這時候，我們也就不難發現。Helm 試圖在推進的一些事情，跟 K8s 的設計發生了正面沖突。
理論上來講，Helm 隻需要将應用描述檔案送出給 K8s ，剩下的應用啟動、釋出和復原等操作，就都交給 K8s 即可。比如在 K8s 的 Deployment 語義中，已經為使用者提供了非常詳細的滾動更新政策，這些都是應用描述（ YAML 檔案）裡的主要字段：
yaml
strategy:
type: Rolling
rollingParams:
updatePeriodSeconds: 1
intervalSeconds: 1
timeoutSeconds: 120
maxSurge: "20%"
maxUnavailable: "10%" 但是現在，Helm 自己也内置了應用的更新和復原政策，并且它們與 K8s 的政策沒有什麼關系、都通過 Tiller 幫你完成。
這就讓使用者陷入了一種非常尴尬的境地：我到底還要不要定義和使用 K8s 的滾動更新參數了？
除此之外，Tiller 事實上還接管了其他一些的 K8s 核心功能，比如 PATCH API 的實作。這些都讓使用者感覺到困惑，畢竟在絕大多數情況，使用者都是先學習了 K8s API 然後再開始使用 Helm 的。
當然，Helm 項目當初做出這樣的決定其實也是可以了解的。
在 2016~2017 年，應用管理并不是 K8s 主要透出來的核心能力，很少有人能夠意識到 K8s 異常複雜的聲明式 API 、尤其是 PACTH API 到底意味着什麼————哪怕“ K8s 聲明式應用配置”的大部分理論實際上一直存在于 K8s 文檔庫最不顯眼的一個角落中。是以，在那個時候，大家在 K8s 之上進行應用管理第一個想到的 idea ，基本都是在 K8s 裡安裝一個 Controller 來實作。實際上，當時 Google Cloud 團隊自己也提出了一個叫做 Deployment Manager的插件，這個插件後來跟 Tiller 部分合并在了一起。
但開源社群魔力就在于使用者“用腳投票”的神奇力量。
Helm 項目作為 “ K8s 包管理工具”的人設，讓這個項目在雲原生社群風生水起；但與此同時， Tiller 這個奇怪的存在，也成為了 Helm 項目進一步向前發展的絆腳石。長久以來，Tiller 元件帶來的使用困惑、安全隐患、部署維護的複雜度，幾乎占據了 Helm 社群的絕大多數闆塊。一些廠商甚至幹脆自己釋出了“去 Tiller 版”的 Helm 發行版來表示“抗議“。
而另一方面， K8s 的聲明式應用管理思路也沒有走向外置 Controller 的方式去解決，而是選擇繼續在 K8s 本身去豐富和完善應用管理與釋出能力，這很快也成為了整個 K8s 社群投入的重中之重（這個故事，我們在後續的《雲原生應用管理系列文章》中會為你進行進一步的介紹）。這也就使得 Helm 本身内置的應用管理體系開始與上遊社群漸行漸遠。
當生态和社群都開始與項目的發展背道而馳的時候，“自我革命”就自然成為了一個勢在必行的選擇。
Helm v3，雲原生應用管理的重要裡程碑
除了移除 Tiller、讓 Helm 變成純用戶端工具之外，Helm v3 相對于 Helm v2 ，還有如下一些重要變化：
- Release 名字可縮小至 Namespace 範圍，需要顯示啟用選項 --generate-name ：這進一步規範和完善了 Helm 應用的名稱問題；
- 合并描述應用依賴的 requirements.yaml 到 Chart.yaml：進一步減小使用者的學習負擔
- 支援 helm push 到遠端 Helm Hub ，支援登陸認證；
- 支援在容器鏡像 Registry 中存儲 Charts：消除 Helm Hub 和 DockerHub 的重合定位
- 支援 LUA 文法：現有的模闆變量，實際上問題很大，我們在後續文章中會詳細介紹；
- 對 values.yaml 裡的内容進行驗證；
- …
關于 Helm v3 的詳細解讀和執行個體，你可以繼續閱讀這篇
《深度解讀Helm 3: 猶抱琵琶半遮面》來一探究竟。
經曆了這樣的重構之後，Helm v3 已經開始調整自己的發展方向，淡化了做一個“微型 PaaS”的思路，更多的關注于應用打包和基礎管理功能，将更多的自由度和發揮空間交換給了 K8s 社群。
這個變化，無論是對于 Helm 社群還是雲原生應用開發者來說，都是喜聞樂見的。不難預料，Helm v3 很大機率會成為未來雲原生應用管理體系中的一個重要工具，而與之相對應的 App Hub ，也會成為雲應用分發與托管過程中的重要環節。
雲原生時代，你還有什麼理由不去嘗試一下 Helm v3 呢？
即刻開始！
雖然還有一些疑惑，小張似乎也摸索出了 Helm v3 背後的一些“大計劃”。
說幹就幹！
由于 Helm v3 現在還在預覽版，沒有正式的下載下傳管道，小張隻能打開 GitHub 從 Release 頁面下載下傳二進制檔案。然而 …………
“怎麼會這麼卡！”
由于不可描述的原因，GitHub 托管 Release 的存儲在國内通路非常困難。不過，善于利用 百度搜尋的小張，還是找到了好心人在國内托管的 Helm v3 鏡像和安裝方法：
https://github.com/cloudnativeapp/workshop/tree/master/kubecon2019china/charts/guestbook#installing-helm-v3在有了 Helm v3 之後，小張到底能不能順利的把“圖書館管理系統”做成 Charts ，上傳到
讓全國的開發者使用到呢？
我們拭目以待！
作者簡介: 張磊，阿裡雲容器平台進階技術專家，CNCF Ambassador （CNCF 官方大使），Kubernetes 項目資深成員與維護者，曾就職于 Hyper、微軟研究院（MSR），現在負責 Kubernetes 技術及上下遊相關工作。