基於Helm和Operator的K8S應用管理的分享

本文由3月7日晚李平輝，Rancher Labs 研發工程師所作的技術分享整理而成。
李平輝熟悉應用容器化解決方案設計和實施，熟悉持續集成方案，關注並參與K8S生態的發展，負責Rancher中國區持續集成服務研發。
搜索微信號RancherLabsChina，添加Rancher小助手爲好友，可加入官方技術交流羣，實時參加下一次分享~
  
  
   

你們好，今天咱們分享的內容是基於Helm和Operator的K8S應用管理。咱們知道，Kubernetes基於服務粒度提供了多種資源描述類型。描述一個應用系統尤爲是微服務架構系統，須要組合使用大量的Kubernetes資源。針對有狀態應用，經常還須要複雜的運維管理操做以及更多的領域知識。
  
今晚的分享就將介紹如何用Helm這一Kubernetes應用包管理的社區主導方案來簡化應用的部署管理，如何製做應用模板以及打造Kubernetes版應用商店，以及如何利用operator自動化應用的運維。
    
咱們知道在K8S社區裏面，根據不一樣的領域，分紅了不一樣的興趣小組，英文叫SIG。今晚的話題屬於APP這個領域。它們是爲了解決K8S的應用管理裏面的一些問題而生的。
    

1、Helm

   

讓咱們從零開始吧。好比說咱們如今已經部署了一個K8S的集羣。無論是用GKE或者是EKS，都不是難事，由於如今部署K8S已經不是之前那麼麻煩的事情了。而後咱們作了應用的容器化。接下來，咱們要試着去把咱們的應用部署到K8S上面去。
   
其實在K8S裏面，資源對象是不少的：
 

 
對於一些微服務架構來講，會有不一樣的服務在上面運行，你可能要管理諸如deployment、service、有狀態的Statefulset、權限的控制等等。你會發現，部署應用後還會有不少其餘關聯的東西以及你須要考慮的點：好比說你的不一樣團隊，要去管理這樣一個應用，從開發到測試再到生產，在不一樣的環境中，一樣一套東西可能都須要不一樣的配置。例如，你在開發的時候，不須要用到PV，而是用一些暫時的存儲就好了；可是在生產環境中，你必需要持久存儲；而且你可能會在團隊之間作共享，而後去存檔。
  
另外，你不只僅要部署這個應用資源，你還要去管理其生命週期，包括升級、更新換代、後續的刪除等。咱們知道，K8S裏面的deployment是有版本管理的，可是從整個應用或某個應用模塊來考慮的話，除了deployment，可能還會有其餘的configmap之類的去跟其關聯。這時咱們會想，是否有這樣一個工具能夠在更上層的維度去管理這些應用呢？這個時候咱們就有了社區的一個包管理工具：Helm。
   
咱們知道K8S的意思是舵手，即掌控船舵的那我的。而Helm其實就是那個舵。在Helm裏面，它的一個應用包叫Charts，Charts實際上是航海圖的意思。它是什麼東西呢？
   
它其實就是一個應用的定義描述。裏面包括了這個應用的一些元數據，以及該應用的K8S資源定義的模板及其配置。其次，Charts還能夠包括一些文檔的說明，這些能夠存儲在chart的倉庫裏面。
 
怎麼用Helm這個工具呢？Helm其實就是一個二進制工具。你只要把它下載下來，已經配置好了kubeconfig的一些相關配置信息，就能夠在K8S中作應用的部署和管理了。
用Helm能夠作什麼事情呢？其實Helm分爲服務端跟客戶端兩部分，你在helm init以後，它會把一個叫作Tiller的服務端，部署在K8S裏面。這個服務端能夠幫你管理Helm Chart應用包的一個完整生命週期。
   
Release == Chart 的安裝實例：

接着說說Helm Chart。它本質上是一個應用包，你能夠把它理解成dpkg或者像rpm這樣的包。只不過，它是基於K8S領域的一個應用包的概念。你能夠對同一個chart包進行屢次部署，每次安裝它都會產生一個Release。這個Release至關於一個chart中的安裝實例。
   
如今咱們已經把Tiller部署進去了，那麼就能夠去作咱們應用的管理了：

$ helm install <chart>
# (stable/mariadb, ./nginx-1.2.3.tgz, ./nginx, https://example.com/charts/nginx-1.2.3.tgz)
$ helm upgrade <release>
$ helm delete <release>

關於一些經常使用的命令例如安裝一個應用包，能夠用install，它實際上是能夠支持不一樣格式的：好比說本地的一些chart包，或者說你的遠程倉庫路徑。
對於應用的更新，用Helm upgrade。
若是要刪除的話，就用Helm Delete。
  
Helm的一個Release會生成對應的Configmap，由它去存儲這個Release的信息，並存在K8S裏面。它至關於把應用的一個生命週期的迭代，直接跟K8S去作關聯，哪怕Tiller掛了，但只要你的配置信息還在，這個應用的發佈和迭代歷程不會丟失：例如想回滾到之前的版本，或者是查看它的升級路徑等。
  
接下來咱們看一個chart的結構。
  
$ helm create demoapp

用Helm create的話，它會提供一個大概的框架，你能夠去建立本身的一個應用。好比說這個應用就叫作Demoapp，裏面會有以下內容：

其中最核心的是templates，即模板化的K8S manifests文件，這裏面會包括資源的定義，例如deployment、service等。如今咱們create出來的是一個默認的、用一個nginx deployment去部署的應用。
   
它本質上就是一個Go的template模板。Helm在Go template模板的基礎上，還會增長不少東西。如一些自定義的元數據信息、擴展的庫以及一些相似於編程形式的工做流，例如條件語句、管道等等。這些東西都會使得咱們的模板變得很是豐富。
   
有了模板，咱們怎麼把咱們的配置融入進去呢？用的就是這個values文件。這兩部份內容其實就是chart的核心功能。

這個deployment，就是一個Go template的模板。裏面能夠定義一些預設的配置變量。這些變量就是從values文件中讀取出來的。這樣一來，咱們就有了一個應用包的模板，能夠用不一樣的配置將這個應用包部署在不一樣的環境中去。除此以外，在Helm install/upgrade時候，可使用不一樣的value。
   
配置選項：

$ helm install --set image.tag=latest ./demoapp
$ helm install -f stagingvalues.yaml ./demoapp
  
好比說你能夠set某個單獨的變量，你能夠用整個File去作一個部署，它會用你如今的配置覆蓋掉它的默認配置。所以咱們能夠在不一樣的團隊之間，直接用不一樣的配置文件，並用一樣的應用包去作應用管理。Chart.yaml即chart的元數據，描述的就是這個chart包的信息。

另外還有一些文檔的說明，例如NOTES.txt，通常放在templates裏面，它是在你安裝或者說你察看這個部署詳情之時(helm status)，自動列出來的。一般會放一些部署了的應用和如何訪問等一些描述性的信息。
 

 
除了模板之外，Helm chart的另外一個做用就是管理依賴。

 
好比說你部署一個Wordpress，它能夠依賴一些數據庫服務。你能夠把數據庫服務做爲一個chart形式，放在一個依賴的目錄下面。這樣的話應用之間的依賴管理就能夠作的很方便了。
假如如今已經建立了咱們本身的應用包，想要有一個倉庫去管理這個包，在團隊之間共享應該怎麼作？
  
chart的倉庫其實就是一個HTTP服務器。只要你把你的chart以及它的索引文件放到上面，在Helm install的時候，就能夠經過上面的路徑去拿。
  
Helm工具自己也提供一個簡單的指令，叫Helm serve，幫你去作一個開發調試用的倉庫。
  
例如 https://example.com/charts 的倉庫目錄結構：

  
關於 Helm，社區版其實已經有了不少的應用包，通常放在K8S下面的一些項目中，好比安裝Helm時候，它默認就有一個Stable的項目。裏面會有各類各樣的應用包。Stable和incubator chart 倉庫：https://github.com/kubernetes/charts
  
另外，社區版還會提供相似於Rancher Catalog應用商店的這樣一個概念的UI，你能夠在這上面作管理。它叫Monocular，即單筒望遠鏡的意思，這些項目的開發都很是的活躍，一直在隨着K8S的迭代作着更新。
  
Monocular: chart的UI管理項目：https://github.com/kubernetes-helm/monocular

 
那麼怎麼去部署K8S版的應用商店呢？其實也很是簡單。由於有了Helm以後，你只要使用Helm install這個Monocular，先把它的倉庫加進來，再install一下，就能夠把這個應用部署到你的K8S集羣之中了。它其實也是利用了Helm Tiller去作部署。咱們能夠在上面去搜索一些chart，管理你的倉庫，例如官方的stable，或者是incubator裏面的一些項目。

 
你也能夠管理一些已經部署的應用。好比說你要搜索一個應用，點一下部署，就能夠把它部署上去了。不過這其中還有不少亟待完善的東西，好比這裏的部署不能配置各類不一樣的參數，它只能輸入namespace。其次，裏面的一些管理依然存在侷限性，好比不能很方便地在UI上作更新。
  
圍繞Helm chart咱們也會跟一些公有云廠商有相關的合做。由於Helm chart的好處就是：一個應用包能夠在多個地方部署。好比公有云的服務，能夠基於它去實現應用的編排和管理，把一個服務便利地提供給不一樣的用戶。Rancher也會在2.0的應用商店中加入對helm chart的支持，但願幫助用戶在方便利用已有模板的同時提供良好的體驗。
  
在stable的倉庫裏面已經有不少chart，其實並非特別完善，還有不少應用是能夠補充和加強的。就咱們的實踐經驗來講，什麼均可以chart化，無論是分佈式的數據庫集羣，仍是並行計算框架，均可以以這樣的形式在K8S上部署和管理起來。
  
另一點就是Helm是插件化的，helm的插件有Helm-templates, helm-github，等等。
  
好比你在Helm install的時候，它能夠調用插件去作擴展。它沒有官方的倉庫，可是已經有一些功能可用。實際上是把Restless/release的信息以及你的chart信息以及Tiller的鏈接信息交給插件去處理。Helm自己無論插件是用什麼形式去實現的，只要它是應用包，則對傳入的這些參數作它本身的處理就行。
  
Helm的好處，大概就有這些：
• 利用已有的Chart快速部署進行實驗
• 建立自定義Chart，方便地在團隊間共享
• 便於管理應用的生命週期
• 便於應用的依賴管理和重用
• 將K8S集羣做爲應用發佈協做中心
  

2、Operator

  
咱們接下來講說Operator。爲何講Operator呢？Operator其實並非一個工具，而是爲了解決一個問題而存在的一個思路。什麼問題？就是咱們在管理應用時，會遇到無狀態和有狀態的應用。管理無狀態的應用是相對來講比較簡單的，可是有狀態的應用則比較複雜。在Helm chart的stable倉庫裏面，不少數據庫的chart實際上是單節點的，由於分佈式的數據庫作起來會較爲麻煩。
  
Operator的理念是但願注入領域知識，用軟件管理複雜的應用。例如對於有狀態應用來講，每個東西都不同，均可能須要你有專業的知識去處理。對於不一樣的數據庫服務，擴容縮容以及備份等方式各有區別。能不能利用K8S便捷的特性去把這些複雜的東西簡單化呢？這就是Operator想作的事情。
  
以無狀態應用來講，把它作成一個Scale UP的話是比較簡單的：擴充一下它的數量就好了。
 

   

接着在deployment或者是說ReplicaSet的controller中，會去判斷它當前的狀態，並向目標狀態進行遷移。對有狀態的應用來講，咱們經常須要考慮不少複雜的事情，包括升級、配置更新、備份、災難恢復、Scale調整數量等等，有時至關於將整個配置刷一遍，甚至可能要重啓一些服務。
   
好比像Zookeeper315之前不能實時更新集羣狀態，想要擴容很是麻煩，可能須要把整個節點重啓一輪。有些數據庫可能方便一點，到master那裏註冊一下就好。所以每一個服務都會有它本身的特色。
  
拿etcd來講，它是K8S裏面主要的存儲。若是對它作一個Scale up的話，須要往集羣中添加一些新節點的鏈接信息，從而獲取到集羣的不一樣Member的配置鏈接。而後用它的集羣信息去啓動一個新的etcd節點。
  
若是有了etcd Operator，會怎麼樣？Operator實際上是CoreOS佈道的東西。CoreOS給社區出了幾個開源的Operator，包括etcd，那麼如何在這種狀況下去擴容一個etcd集羣？
  
首先能夠以deployment的形式把etcd Operator部署到K8S中。部署完這個Operator以後，想要部署一個etcd的集羣，其實很方便。由於不須要再去管理這個集羣的配置信息了，你只要告訴我，你須要多少的節點，你須要什麼版本的etcd，而後建立這樣一個自定義的資源，Operator會監聽你的需求，幫你建立出配置信息來。
  
$ kubectl create –f etcd-cluster.yaml

 
 
要擴容的話也很簡單，只要更新數量（好比從3改到5），再apply一下，它一樣會監聽這個自定義資源的變更，去作對應的更新。
  
$ kubectl apply -f upgrade-example.yaml

這樣就至關於把之前須要運維人員去處理集羣的一些工做所有都交付給Operator去完成了。如何作到的呢？即應用了K8S的一個擴展性的API——CRD（在之前稱爲第三方資源）。
  
在部署了一個etcd Operator以後，經過kubernetes API去管理和維護目標的應用狀態。本質上走的就是K8S裏面的Controller的模式。K8S Controller會對它的resource作這樣的一個管理：去監聽或者是說檢查它預期的狀態，而後跟當前的狀態做對比。若是其中它會有一些差別的話，它會去作對應的更新。
  
Kubernetes Controller 模式：

  
etcd的作法是在拉起一個etcd Operator的時候，建立一個叫etcd cluster的自定義資源，監聽應用的變化。好比你的聲明你的更新，它都會去產生對應的一個事件，去作對應的更新，將你的etcd集羣維護在這樣的狀態。
  
除了etcd之外，社區好比還有普羅米修斯Operator均可以以這種方便的形式，去幫你管理一些有狀態的應用。
  
值得一提的是，Rancher2.0普遍採用了Kubernetes-native的Controller模式，去管理應用負載乃至K8S集羣，調侃地說，是個Kubernetes operator。
 

3、Helm和Operator的對比

  這兩個東西講完了，咱們來對比一下兩者吧。   Operator本質上是針對特定的場景去作有狀態服務，或者說針對擁有複雜應用的應用場景去簡化其運維管理的工具。Helm的話，它實際上是一個比較普適的工具，想法也很簡單，就是把你的K8S資源模板化，方便共享，而後在不一樣的配置中重用。  其實Operator作的東西Helm大部分也能夠作。用Operator去監控更新etcd的集羣狀態，也能夠用定製的Chart作一樣的事情。只不過你可能須要一些更復雜的處理而已，例如在etcd沒有創建起來時候，你可能須要一些init Container去作配置的更新，去檢查狀態，而後把這個節點用對應的信息給拉起來。刪除的時候，則加一些PostHook去作一些處理。因此說Helm是一個更加普適的工具。二者甚至能夠結合使用，好比stable倉庫裏就有etcd-operator chart。  就我的理解來講，在K8S這個龐然大物之上，他們二者都誕生於簡單但天然的想法，helm是爲了配置分離，operator則是針對複雜應用的自動化管理。