初探雲原生應用管理（二）: 爲何你必須儘快轉向 Helm v3

系列介紹：這個系列是介紹如何用雲原生技術來構建、測試、部署、和管理應用的內容專輯。作這個系列的初衷是爲了推廣雲原生應用管理的最佳實踐，以及傳播開源標準和知識。在這個系列文章的開篇初探雲原生應用管理（一）: 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 文件組成的：

1. web-deploy.yaml ，用 K8s 的 Deployment 描述的 Java Web 程序；
2. web-svc.yaml ，用 K8s 的 Service 描述的程序訪問的入口；
3. mysql.yaml ，用 K8s StatefulSet 描述的 MySQL 實例；
4. 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 ，上傳到開放雲原生應用中心（AppHub）讓全國的開發者使用到呢？

咱們拭目以待！

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。