這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)基于Helm和Operator的K8S應(yīng)用管理的分析是怎樣的，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
創(chuàng)新互聯(lián)建站專業(yè)為企業(yè)提供漠河網(wǎng)站建設(shè)、漠河做網(wǎng)站、漠河網(wǎng)站設(shè)計、漠河網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、漠河企業(yè)網(wǎng)站模板建站服務(wù)，十載漠河做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。
今天我們分享的內(nèi)容是基于Helm和Operator的K8S應(yīng)用管理。我們知道，Kubernetes基于服務(wù)粒度提供了多種資源描述類型。描述一個應(yīng)用系統(tǒng)尤其是微服務(wù)架構(gòu)系統(tǒng)，需要組合使用大量的Kubernetes資源。針對有狀態(tài)應(yīng)用，常常還需要復(fù)雜的運維管理操作以及更多的領(lǐng)域知識。
今晚將介紹如何用Helm這一Kubernetes應(yīng)用包管理的社區(qū)主導(dǎo)方案來簡化應(yīng)用的部署管理，如何制作應(yīng)用模板以及打造Kubernetes版應(yīng)用商店，以及如何利用operator自動化應(yīng)用的運維。
讓我們從零開始吧。比如說我們現(xiàn)在已經(jīng)部署了一個K8S的集群。不管是用GKE或者是EKS，都不是難事，因為現(xiàn)在部署K8S已經(jīng)不是以前那么麻煩的事情了。然后我們做了應(yīng)用的容器化。接下來，我們要試著去把我們的應(yīng)用部署到K8S上面去。
其實在K8S里面，資源對象是很多的： 
對于一些微服務(wù)架構(gòu)來說，會有不同的服務(wù)在上面運行，你可能要管理諸如deployment、service、有狀態(tài)的Statefulset、權(quán)限的控制等等。你會發(fā)現(xiàn)，部署應(yīng)用后還會有很多其他關(guān)聯(lián)的東西以及你需要考慮的點：比如說你的不同團隊，要去管理這樣一個應(yīng)用，從開發(fā)到測試再到生產(chǎn)，在不同的環(huán)境中，同樣一套東西可能都需要不同的配置。例如，你在開發(fā)的時候，不需要用到PV，而是用一些暫時的存儲就行了；但是在生產(chǎn)環(huán)境中，你必須要持久存儲；并且你可能會在團隊之間做共享，然后去存檔。
另外，你不僅僅要部署這個應(yīng)用資源，你還要去管理其生命周期，包括升級、更新?lián)Q代、后續(xù)的刪除等。我們知道，K8S里面的deployment是有版本管理的，但是從整個應(yīng)用或某個應(yīng)用模塊來考慮的話，除了deployment，可能還會有其他的configmap之類的去跟其關(guān)聯(lián)。這時我們會想，是否有這樣一個工具可以在更上層的維度去管理這些應(yīng)用呢？這個時候我們就有了社區(qū)的一個包管理工具：Helm。
我們知道K8S的意思是舵手，即掌控船舵的那個人。而Helm其實就是那個舵。在Helm里面，它的一個應(yīng)用包叫Charts，Charts其實是航海圖的意思。它是什么東西呢？
它其實就是一個應(yīng)用的定義描述。里面包括了這個應(yīng)用的一些元數(shù)據(jù)，以及該應(yīng)用的K8S資源定義的模板及其配置。其次，Charts還可以包括一些文檔的說明，這些可以存儲在chart的倉庫里面。
怎么用Helm這個工具呢？Helm其實就是一個二進制工具。你只要把它下載下來，已經(jīng)配置好了kubeconfig的一些相關(guān)配置信息，就可以在K8S中做應(yīng)用的部署和管理了。 用Helm可以做什么事情呢？其實Helm分為服務(wù)端跟客戶端兩部分，你在helm init之后，它會把一個叫做Tiller的服務(wù)端，部署在K8S里面。這個服務(wù)端可以幫你管理Helm Chart應(yīng)用包的一個完整生命周期。
Release == Chart 的安裝實例： 
接著說說Helm Chart。它本質(zhì)上是一個應(yīng)用包，你可以把它理解成dpkg或者像rpm這樣的包。只不過，它是基于K8S領(lǐng)域的一個應(yīng)用包的概念。你可以對同一個chart包進行多次部署，每次安裝它都會產(chǎn)生一個Release。這個Release相當(dāng)于一個chart中的安裝實例。
現(xiàn)在我們已經(jīng)把Tiller部署進去了，那么就可以去做我們應(yīng)用的管理了：
$ helm install# (stable/mariadb, ./nginx-1.2.3.tgz, ./nginx, https://example.com/charts/nginx-1.2.3.tgz) $ helm upgrade $ helm delete
關(guān)于一些常用的命令例如安裝一個應(yīng)用包，可以用install，它其實是可以支持不同格式的：比如說本地的一些chart包，或者說你的遠(yuǎn)程倉庫路徑。 對于應(yīng)用的更新，用Helm upgrade。 如果要刪除的話，就用Helm Delete。
Helm的一個Release會生成對應(yīng)的Configmap，由它去存儲這個Release的信息，并存在K8S里面。它相當(dāng)于把應(yīng)用的一個生命周期的迭代，直接跟K8S去做關(guān)聯(lián)，哪怕Tiller掛了，但只要你的配置信息還在，這個應(yīng)用的發(fā)布和迭代歷程不會丟失：例如想回滾到以前的版本，或者是查看它的升級路徑等。
接下來我們看一個chart的結(jié)構(gòu)。
$ helm create demoapp
用Helm create的話，它會提供一個大概的框架，你可以去創(chuàng)建自己的一個應(yīng)用。比如說這個應(yīng)用就叫做Demoapp，里面會有如下內(nèi)容： 
其中最核心的是templates，即模板化的K8S manifests文件，這里面會包括資源的定義，例如deployment、service等?，F(xiàn)在我們create出來的是一個默認(rèn)的、用一個nginx deployment去部署的應(yīng)用。
它本質(zhì)上就是一個Go的template模板。Helm在Go template模板的基礎(chǔ)上，還會增加很多東西。如一些自定義的元數(shù)據(jù)信息、擴展的庫以及一些類似于編程形式的工作流，例如條件語句、管道等等。這些東西都會使得我們的模板變得非常豐富。
有了模板，我們怎么把我們的配置融入進去呢？用的就是這個values文件。這兩部分內(nèi)容其實就是chart的核心功能。 
這個deployment，就是一個Go template的模板。里面可以定義一些預(yù)設(shè)的配置變量。這些變量就是從values文件中讀取出來的。這樣一來，我們就有了一個應(yīng)用包的模板，可以用不同的配置將這個應(yīng)用包部署在不同的環(huán)境中去。除此之外，在Helm install/upgrade時候，可以使用不同的value。
配置選項： 
$ helm install --set image.tag=latest ./demoapp $ helm install -f stagingvalues.yaml ./demoapp
比如說你可以set某個單獨的變量，你可以用整個File去做一個部署，它會用你現(xiàn)在的配置覆蓋掉它的默認(rèn)配置。因此我們可以在不同的團隊之間，直接用不同的配置文件，并用同樣的應(yīng)用包去做應(yīng)用管理。Chart.yaml即chart的元數(shù)據(jù)，描述的就是這個chart包的信息。
另外還有一些文檔的說明，例如NOTES.txt，一般放在templates里面，它是在你安裝或者說你察看這個部署詳情之時(helm status)，自動列出來的。通常會放一些部署了的應(yīng)用和如何訪問等一些描述性的信息。
除了模板以外，Helm chart的另一個作用就是管理依賴。 
比如說你部署一個Wordpress，它可以依賴一些數(shù)據(jù)庫服務(wù)。你可以把數(shù)據(jù)庫服務(wù)作為一個chart形式，放在一個依賴的目錄下面。這樣的話應(yīng)用之間的依賴管理就可以做的很方便了。 假如現(xiàn)在已經(jīng)創(chuàng)建了我們自己的應(yīng)用包，想要有一個倉庫去管理這個包，在團隊之間共享應(yīng)該怎么做？
chart的倉庫其實就是一個HTTP服務(wù)器。只要你把你的chart以及它的索引文件放到上面，在Helm install的時候，就可以通過上面的路徑去拿。
Helm工具本身也提供一個簡單的指令，叫Helm serve，幫你去做一個開發(fā)調(diào)試用的倉庫。
例如 https://example.com/charts 的倉庫目錄結(jié)構(gòu)： 
關(guān)于 Helm，社區(qū)版其實已經(jīng)有了很多的應(yīng)用包，一般放在K8S下面的一些項目中，比如安裝Helm時候，它默認(rèn)就有一個Stable的項目。里面會有各種各樣的應(yīng)用包。Stable和incubator chart 倉庫：https://github.com/kubernetes/charts
另外，社區(qū)版還會提供類似于Rancher Catalog應(yīng)用商店的這樣一個概念的UI，你可以在這上面做管理。它叫Monocular，即單筒望遠(yuǎn)鏡的意思，這些項目的開發(fā)都非常的活躍，一直在隨著K8S的迭代做著更新。
Monocular: chart的UI管理項目：https://github.com/kubernetes-helm/monocular 
那么怎么去部署K8S版的應(yīng)用商店呢？其實也非常簡單。因為有了Helm之后，你只要使用Helm install這個Monocular，先把它的倉庫加進來，再install一下，就可以把這個應(yīng)用部署到你的K8S集群之中了。它其實也是利用了Helm Tiller去做部署。我們可以在上面去搜索一些chart，管理你的倉庫，例如官方的stable，或者是incubator里面的一些項目。
你也可以管理一些已經(jīng)部署的應(yīng)用。比如說你要搜索一個應(yīng)用，點一下部署，就可以把它部署上去了。不過這其中還有很多亟待完善的東西，比如這里的部署不能配置各種不同的參數(shù)，它只能輸入namespace。其次，里面的一些管理依然存在局限性，比如不能很方便地在UI上做更新。
圍繞Helm chart我們也會跟一些公有云廠商有相關(guān)的合作。因為Helm chart的好處就是：一個應(yīng)用包可以在多個地方部署。比如公有云的服務(wù)，可以基于它去實現(xiàn)應(yīng)用的編排和管理，把一個服務(wù)便利地提供給不同的用戶。Rancher也會在2.0的應(yīng)用商店中加入對helm chart的支持，希望幫助用戶在方便利用已有模板的同時提供良好的體驗。
在stable的倉庫里面已經(jīng)有很多chart，其實并不是特別完善，還有很多應(yīng)用是可以補充和增強的。就我們的實踐經(jīng)驗來說，什么都可以chart化，不管是分布式的數(shù)據(jù)庫集群，還是并行計算框架，都可以以這樣的形式在K8S上部署和管理起來。
另外一點就是Helm是插件化的，helm的插件有Helm-templates, helm-github，等等。
比如你在Helm install的時候，它可以調(diào)用插件去做擴展。它沒有官方的倉庫，但是已經(jīng)有一些功能可用。其實是把Restless/release的信息以及你的chart信息以及Tiller的連接信息交給插件去處理。Helm本身不管插件是用什么形式去實現(xiàn)的，只要它是應(yīng)用包，則對傳入的這些參數(shù)做它自己的處理就行。
Helm的好處，大概就有這些： ? 利用已有的Chart快速部署進行實驗 ? 創(chuàng)建自定義Chart，方便地在團隊間共享 ? 便于管理應(yīng)用的生命周期 ? 便于應(yīng)用的依賴管理和重用 ? 將K8S集群作為應(yīng)用發(fā)布協(xié)作中心
我們接下來說說Operator。為什么講Operator呢？Operator其實并不是一個工具，而是為了解決一個問題而存在的一個思路。什么問題？就是我們在管理應(yīng)用時，會遇到無狀態(tài)和有狀態(tài)的應(yīng)用。管理無狀態(tài)的應(yīng)用是相對來說比較簡單的，但是有狀態(tài)的應(yīng)用則比較復(fù)雜。在Helm chart的stable倉庫里面，很多數(shù)據(jù)庫的chart其實是單節(jié)點的，因為分布式的數(shù)據(jù)庫做起來會較為麻煩。
Operator的理念是希望注入領(lǐng)域知識，用軟件管理復(fù)雜的應(yīng)用。例如對于有狀態(tài)應(yīng)用來說，每一個東西都不一樣，都可能需要你有專業(yè)的知識去處理。對于不同的數(shù)據(jù)庫服務(wù)，擴容縮容以及備份等方式各有區(qū)別。能不能利用K8S便捷的特性去把這些復(fù)雜的東西簡單化呢？這就是Operator想做的事情。
以無狀態(tài)應(yīng)用來說，把它做成一個Scale UP的話是比較簡單的：擴充一下它的數(shù)量就行了。 
接著在deployment或者是說ReplicaSet的controller中，會去判斷它當(dāng)前的狀態(tài)，并向目標(biāo)狀態(tài)進行遷移。對有狀態(tài)的應(yīng)用來說，我們常常需要考慮很多復(fù)雜的事情，包括升級、配置更新、備份、災(zāi)難恢復(fù)、Scale調(diào)整數(shù)量等等，有時相當(dāng)于將整個配置刷一遍，甚至可能要重啟一些服務(wù)。
比如像Zookeeper315以前不能實時更新集群狀態(tài)，想要擴容非常麻煩，可能需要把整個節(jié)點重啟一輪。有些數(shù)據(jù)庫可能方便一點，到master那里注冊一下就好。因此每個服務(wù)都會有它自己的特點。
拿etcd來說，它是K8S里面主要的存儲。如果對它做一個Scale up的話，需要往集群中添加一些新節(jié)點的連接信息，從而獲取到集群的不同Member的配置連接。然后用它的集群信息去啟動一個新的etcd節(jié)點。
如果有了etcd Operator，會怎么樣？Operator其實是CoreOS布道的東西。CoreOS給社區(qū)出了幾個開源的Operator，包括etcd，那么如何在這種情況下去擴容一個etcd集群？
首先可以以deployment的形式把etcd Operator部署到K8S中。部署完這個Operator之后，想要部署一個etcd的集群，其實很方便。因為不需要再去管理這個集群的配置信息了，你只要告訴我，你需要多少的節(jié)點，你需要什么版本的etcd，然后創(chuàng)建這樣一個自定義的資源，Operator會監(jiān)聽你的需求，幫你創(chuàng)建出配置信息來。
$ kubectl create –f etcd-cluster.yaml
要擴容的話也很簡單，只要更新數(shù)量（比如從3改到5），再apply一下，它同樣會監(jiān)聽這個自定義資源的變動，去做對應(yīng)的更新。
$ kubectl apply -f upgrade-example.yaml
這樣就相當(dāng)于把以前需要運維人員去處理集群的一些工作全部都交付給Operator去完成了。如何做到的呢？即應(yīng)用了K8S的一個擴展性的API——CRD（在以前稱為第三方資源）。
在部署了一個etcd Operator之后，通過kubernetes API去管理和維護目標(biāo)的應(yīng)用狀態(tài)。本質(zhì)上走的就是K8S里面的Controller的模式。K8S Controller會對它的resource做這樣的一個管理：去監(jiān)聽或者是說檢查它預(yù)期的狀態(tài)，然后跟當(dāng)前的狀態(tài)作對比。如果其中它會有一些差異的話，它會去做對應(yīng)的更新。
Kubernetes Controller 模式： 
etcd的做法是在拉起一個etcd Operator的時候，創(chuàng)建一個叫etcd cluster的自定義資源，監(jiān)聽?wèi)?yīng)用的變化。比如你的聲明你的更新，它都會去產(chǎn)生對應(yīng)的一個事件，去做對應(yīng)的更新，將你的etcd集群維護在這樣的狀態(tài)。
除了etcd以外，社區(qū)比如還有普羅米修斯Operator都可以以這種方便的形式，去幫你管理一些有狀態(tài)的應(yīng)用。
值得一提的是，Rancher2.0廣泛采用了Kubernetes-native的Controller模式，去管理應(yīng)用負(fù)載乃至K8S集群，調(diào)侃地說，是個Kubernetes operator。
這兩個東西講完了，我們來對比一下二者吧。
Operator本質(zhì)上是針對特定的場景去做有狀態(tài)服務(wù)，或者說針對擁有復(fù)雜應(yīng)用的應(yīng)用場景去簡化其運維管理的工具。Helm的話，它其實是一個比較普適的工具，想法也很簡單，就是把你的K8S資源模板化，方便共享，然后在不同的配置中重用。
其實Operator做的東西Helm大部分也可以做。用Operator去監(jiān)控更新etcd的集群狀態(tài)，也可以用定制的Chart做同樣的事情。只不過你可能需要一些更復(fù)雜的處理而已，例如在etcd沒有建立起來時候，你可能需要一些init Container去做配置的更新，去檢查狀態(tài)，然后把這個節(jié)點用對應(yīng)的信息給拉起來。刪除的時候，則加一些PostHook去做一些處理。所以說Helm是一個更加普適的工具。兩者甚至可以結(jié)合使用，比如stable倉庫里就有etcd-operator chart。
就個人理解來說，在K8S這個龐然大物之上，他們兩者都誕生于簡單但自然的想法，helm是為了配置分離，operator則是針對復(fù)雜應(yīng)用的自動化管理。
上述就是小編為大家分享的基于Helm和Operator的K8S應(yīng)用管理的分析是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
重慶分公司
重慶分公司
