為什么必須盡快轉(zhuǎn)向，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。
創(chuàng)新互聯(lián)公司于2013年創(chuàng)立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項目成都網(wǎng)站設(shè)計、成都網(wǎng)站制作網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元麻章做網(wǎng)站,已為上家服務(wù),為麻章各地企業(yè)和個人服務(wù),聯(lián)系電話:18980820575
我們將跟你聊聊，為什么要盡快轉(zhuǎn)向 Helm V3。
在研究了一番“開放云原生應(yīng)用中心（AppHub）”之后，程序員小張似乎已經(jīng)明白了“云原生應(yīng)用”到底是怎么一回事情。
“不就是 Helm 嘛！”
說話間，小張就準備把自己開發(fā)多年的“圖書館管理系統(tǒng)”通過 Helm 打包成 Charts ，提交到 AppHub上個線試試。
“這樣，全中國的開發(fā)者就都能使用到我開發(fā)的圖書館管理系統(tǒng)了！”
想想還有點小激動呢！
然而，還沒等編譯完，小張就發(fā)現(xiàn) Helm 官方文檔上有這么一句提示非常辣眼睛：
這，到底是咋回事兒？
Helm 是目前云原生技術(shù)體系中進行應(yīng)用管理最被廣泛使用的開源項目，沒有之一。根據(jù) CNCF 剛剛發(fā)布的 KubeCon EU 2019 的總結(jié)報告，Kubernetes（ k8s ），Prometheus 和 Helm 這三個項目，再次蟬聯(lián) KubeCon 上最被關(guān)注的開源項目前三名。
Helm 項目本身的發(fā)布，則要追述到 Deis 還是一家獨立創(chuàng)業(yè)公司的時代。
2016 年，容器 PaaS （所謂的 CaaS ）創(chuàng)業(yè)方興未艾，但也開始呈現(xiàn)出同質(zhì)化競爭和低附加值的種種苗頭，而在這片紅海當中，當時已經(jīng)委身賣給 Engine Yard 的 Deis 尤其步履維艱。幸運的是，敏銳的技術(shù)嗅覺最終還是“拯救”了這個的團隊。 2016 年底，Deis 開始全面轉(zhuǎn)向 K8s 體系，很快就發(fā)布了一系列專門為 k8s 進行應(yīng)用管理的開源項目。這其中，定位為“ k8s 應(yīng)用包管理器”的 Helm ，是最受歡迎的一個。
我們知道，K8s 本身是沒有“應(yīng)用”這個概念的。比如，小張要在 K8s 上部署的“圖書館管理系統(tǒng)”，實際是由四個 YAML 文件組成的：
web-deploy.yaml ，用 K8s 的 Deployment 描述的 Java Web 程序；
web-svc.yaml ，用 K8s 的 Service 描述的程序訪問的入口；
MySQL.yaml ，用 K8s StatefulSet 描述的 MySQL 實例；
mysql-svc.yaml ，用 K8s Service 描述的 MySQL 實例的訪問入口。
然后，小張需要執(zhí)行四次
`kubectl apply -f`
把這些 YAML 文件都提交給 K8s 來負責(zé)運行和管理這個應(yīng)用。這里面的麻煩之處在于，怎么樣去管理這個應(yīng)用對應(yīng)的所有 k8s 資源？
于是 Helm 項目提供了一種簡單的思路：它定義了一種新的應(yīng)用打包格式叫 Chart 。一個 myapp 應(yīng)用的文件布局如下所示：
myapp/ Chart.yaml values.yaml templates/
其中，Chart.yaml 里面用來寫應(yīng)用元數(shù)據(jù)，比如：
apiVersion: v1 name: 圖書館管理系統(tǒng) version: 0.1 description: 全中國最受歡迎的圖書館管理系統(tǒng) maintainers: - name: 小張
在 templates/ 目錄下，則存放小張編寫好的四個 YAML 文件。
此外，小張還可以將這些 YAML 里需要修改的字段定義成“模板變量”，在部署時由 Helm 去負責(zé)注入。比如 web-deploy.yaml ：
重慶分公司
重慶分公司
apiVersion: apps/v1
kind: Deployment
metadata:
name: 圖書館管理系統(tǒng)網(wǎng)站
spec:
replicas: {{ .Values.replicaCount }}
template:
...
spec:
containers:
...通過上面的語法，小張就把這個 Deployment 的 replicas 值定義成了一個變量，將來就可以在部署的時候通過傳參來決定這個圖書館管理系統(tǒng)啟動后具體有幾個實例了，比如，指定 100 個實例：
helm install apphub/圖書館管理系統(tǒng) --set replicaCount=100
最后，Helm 項目允許你把上面這一系列文件和目錄，做成一個壓縮包上傳到網(wǎng)上，從而被別人通過 helm install 下載安裝到。這個上傳的地址，就是 Helm Hub 了。
這種應(yīng)用打包的方法，很大程度上解決了 K8s 應(yīng)用管理困難的問題，所以在推出之后就很快贏得了開發(fā)者的青睞。而 Helm Hub 也成為了繼 Docker Hub 之后云原生技術(shù)體系里第二個重要的應(yīng)用分發(fā)中心。
不過，上面這個流程聽起來很簡單，但是 Helm 在項目的一開始設(shè)計中，卻使用了一種讓人“匪夷所思”的架構(gòu)。
可以想象，無論是安裝還是更新應(yīng)用，Helm 其實都可以在客戶端調(diào)用 K8s API 來完成這些功能。但現(xiàn)實情況是，Helm 一定需要在 Kubernetes 集群里部署了一個叫做 Tiller 的 Server 端，然后把請求都提交給 Tiller ，再由 Tiller 去跟 K8s APIServer 進行交互，完成應(yīng)用的安裝操作，這個復(fù)雜的過程，可以用下圖表示清楚：
而這個“畫蛇添足”的架構(gòu)，不但成為了 Helm 發(fā)布之處的一個假設(shè)，也貫穿了 Helm v2 的整個項目生命周期。
為什么 Helm 要堅持在 K8s 放置一個 Server 端呢？
這里其中一個重要的原因，在于 Helm 項目并不只希望做一個簡單“ K8s 應(yīng)用打包工具”。
作為一個地道的 PaaS 服務(wù)商，Deis 公司從一開始就知道“應(yīng)用打包”只是自己完整拼圖的入口，而 Tiller 的存在，則是讓 Helm 成為未來云原生時代“新 PaaS” 的重要伏筆。
Tiller 這個服務(wù)端組件，其實相當于 Helm 在 K8s 內(nèi)插入的一個應(yīng)用管理控制器。有了它，Helm 不僅可以很容易在 K8s 側(cè)存儲應(yīng)用相關(guān)的狀態(tài)，還可以基于 Tiller 在 K8s 內(nèi)逐步構(gòu)建出一個微型 PaaS 的功能。并且，這些功能的設(shè)立和發(fā)展，都不需要依賴于 K8s 本身的應(yīng)用管理能力。
這也解釋了為何 Helm 很快就提出了 Release 的概念，發(fā)布了 helm upgrade 、 helm rollback 等應(yīng)用升級和回滾的能力。這些設(shè)計，其實都與 Helm 最終 PaaS 化的思路有著千絲萬縷的聯(lián)系。
不過，Helm 的這條演進路線，在 Kubernetes 這個天生以“應(yīng)用”為中心的基礎(chǔ)設(shè)施體系里，卻實實在在的栽了個跟頭。
我們知道，Kubernetes 是圍繞著聲明式 API 來設(shè)計的。Kubernetes 的容器編排理念以及 APIServer 實現(xiàn)與擴展機制，其本質(zhì)目的都是為了幫助用戶屏蔽掉基礎(chǔ)設(shè)施管理的復(fù)雜性，允許用戶通過統(tǒng)一而整潔的聲明式 API 來描述自己的意圖和訴求，這正是 Kubernetes 成為“ The Platform of Platform ”的重要基礎(chǔ)。
這也是為何，Kubernetes 從一開始就對容器進行組合，以便借助 Pod 的概念來模擬進程組的行為；并且堅持使用聲明式 API 搭配控制器模型來進行應(yīng)用編排，通過 API 資源對象的創(chuàng)建與更新（ PATCH ）來驅(qū)動整個系統(tǒng)的持續(xù)運轉(zhuǎn)。
這種設(shè)計的最終效果，就是用戶只需要將一個“描述”應(yīng)用的 YAML 文件，放在 etcd 里存起來，然后通過控制器模型驅(qū)動整個基礎(chǔ)設(shè)施的狀態(tài)不斷地向用戶聲明的狀態(tài)逼近，就也就是 Kubernetes 的核心工作原理了。這套理論，正是 Google Borg/Omega 進行應(yīng)用管理和編排的核心與基礎(chǔ)，同時也是 K8s 同 Mesos 這種資源管理器項目最大的區(qū)別。
這時候，我們也就不難發(fā)現(xiàn)。Helm 試圖在推進的一些事情，跟 K8s 的設(shè)計發(fā)生了正面沖突。
理論上來講，Helm 只需要將應(yīng)用描述文件提交給 K8s ，剩下的應(yīng)用啟動、發(fā)布和回滾等操作，就都交給 K8s 即可。比如在 K8s 的 Deployment 語義中，已經(jīng)為用戶提供了非常詳細的滾動更新策略，這些都是應(yīng)用描述（ YAML 文件）里的主要字段：
yaml strategy: type: Rolling rollingParams: updatePeriodSeconds: 1 intervalSeconds: 1 timeoutSeconds: 120 maxSurge: "20%" maxUnavailable: "10%"
但是現(xiàn)在，Helm 自己也內(nèi)置了應(yīng)用的更新和回滾策略，并且它們與 K8s 的策略沒有什么關(guān)系、都通過 Tiller 幫你完成。
這就讓用戶陷入了一種非常尷尬的境地：我到底還要不要定義和使用 K8s 的滾動更新參數(shù)了？
除此之外，Tiller 事實上還接管了其他一些的 K8s 核心功能，比如 PATCH API 的實現(xiàn)。這些都讓用戶感覺到困惑，畢竟在絕大多數(shù)情況，用戶都是先學(xué)習(xí)了 K8s API 然后再開始使用 Helm 的。
當然，Helm 項目當初做出這樣的決定其實也是可以理解的。
在 2016~2017 年，應(yīng)用管理并不是 K8s 主要透出來的核心能力，很少有人能夠意識到 K8s 異常復(fù)雜的聲明式 API 、尤其是 PACTH API 到底意味著什么————哪怕“ K8s 聲明式應(yīng)用配置”的大部分理論實際上一直存在于 K8s 文檔庫最不顯眼的一個角落中。所以，在那個時候，大家在 K8s 之上進行應(yīng)用管理第一個想到的 idea ，基本都是在 K8s 里安裝一個 Controller 來實現(xiàn)。實際上，當時 Google Cloud 團隊自己也提出了一個叫做 Deployment Manager的插件，這個插件后來跟 Tiller 部分合并在了一起。
但開源社區(qū)魔力就在于用戶“用腳投票”的神奇力量。
Helm 項目作為 “ K8s 包管理工具”的人設(shè)，讓這個項目在云原生社區(qū)風(fēng)生水起；但與此同時， Tiller 這個奇怪的存在，也成為了 Helm 項目進一步向前發(fā)展的絆腳石。長久以來，Tiller 組件帶來的使用困惑、安全隱患、部署維護的復(fù)雜度，幾乎占據(jù)了 Helm 社區(qū)的絕大多數(shù)板塊。一些廠商甚至干脆自己發(fā)布了“去 Tiller 版”的 Helm 發(fā)行版來表示“抗議“。
而另一方面， K8s 的聲明式應(yīng)用管理思路也沒有走向外置 Controller 的方式去解決，而是選擇繼續(xù)在 K8s 本身去豐富和完善應(yīng)用管理與發(fā)布能力，這很快也成為了整個 K8s 社區(qū)投入的重中之重（這個故事，我們在后續(xù)的《云原生應(yīng)用管理系列文章》中會為你進行進一步的介紹）。這也就使得 Helm 本身內(nèi)置的應(yīng)用管理體系開始與上游社區(qū)漸行漸遠。
當生態(tài)和社區(qū)都開始與項目的發(fā)展背道而馳的時候，“自我革命”就自然成為了一個勢在必行的選擇。
除了移除 Tiller、讓 Helm 變成純客戶端工具之外，Helm v3 相對于 Helm v2 ，還有如下一些重要變化：
Release 名字可縮小至 Namespace 范圍，需要顯示啟用選項 --generate-name ：這進一步規(guī)范和完善了 Helm 應(yīng)用的名稱問題；
合并描述應(yīng)用依賴的 requirements.yaml 到 Chart.yaml：進一步減小用戶的學(xué)習(xí)負擔(dān)
支持 helm push 到遠端 Helm Hub ，支持登陸認證；
支持在容器鏡像 Registry 中存儲 Charts：消除 Helm Hub 和 DockerHub 的重合定位
支持 LUA 語法：現(xiàn)有的模板變量，實際上問題很大，我們在后續(xù)文章中會詳細介紹；
對 values.yaml 里的內(nèi)容進行驗證；
…
經(jīng)歷了這樣的重構(gòu)之后，Helm v3 已經(jīng)開始調(diào)整自己的發(fā)展方向，淡化了做一個“微型 PaaS”的思路，更多的關(guān)注于應(yīng)用打包和基礎(chǔ)管理功能，將更多的自由度和發(fā)揮空間交換給了 K8s 社區(qū)。
這個變化，無論是對于 Helm 社區(qū)還是云原生應(yīng)用開發(fā)者來說，都是喜聞樂見的。不難預(yù)料，Helm v3 很大概率會成為未來云原生應(yīng)用管理體系中的一個重要工具，而與之相對應(yīng)的 App Hub ，也會成為云應(yīng)用分發(fā)與托管過程中的重要環(huán)節(jié)。
云原生時代，你還有什么理由不去嘗試一下 Helm v3 呢？
看完上述內(nèi)容，你們掌握為什么必須盡快轉(zhuǎn)向的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！
