共計 6515 個字符，預計需要花費 17 分鐘才能閱讀完成。
這期內容當中丸趣 TV 小編將會給大家帶來有關基于 Helm 和 Operator 的 K8S 應用管理的分析是怎樣的，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
今天我們分享的內容是基于 Helm 和 Operator 的 K8S 應用管理。我們知道，Kubernetes 基于服務粒度提供了多種資源描述類型。描述一個應用系統尤其是微服務架構系統，需要組合使用大量的 Kubernetes 資源。針對有狀態應用，常常還需要復雜的運維管理操作以及更多的領域知識。
今晚將介紹如何用 Helm 這一 Kubernetes 應用包管理的社區主導方案來簡化應用的部署管理，如何制作應用模板以及打造 Kubernetes 版應用商店，以及如何利用 operator 自動化應用的運維。
一、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 集群作為應用發布協作中心
二、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。
三、Helm 和 Operator 的對比
這兩個東西講完了，我們來對比一下二者吧。
Operator 本質上是針對特定的場景去做有狀態服務，或者說針對擁有復雜應用的應用場景去簡化其運維管理的工具。Helm 的話，它其實是一個比較普適的工具，想法也很簡單，就是把你的 K8S 資源模板化，方便共享，然后在不同的配置中重用。
其實 Operator 做的東西 Helm 大部分也可以做。用 Operator 去監控更新 etcd 的集群狀態，也可以用定制的 Chart 做同樣的事情。只不過你可能需要一些更復雜的處理而已，例如在 etcd 沒有建立起來時候，你可能需要一些 init Container 去做配置的更新，去檢查狀態，然后把這個節點用對應的信息給拉起來。刪除的時候，則加一些 PostHook 去做一些處理。所以說 Helm 是一個更加普適的工具。兩者甚至可以結合使用，比如 stable 倉庫里就有 etcd-operator chart。
就個人理解來說，在 K8S 這個龐然大物之上，他們兩者都誕生于簡單但自然的想法，helm 是為了配置分離，operator 則是針對復雜應用的自動化管理。
上述就是丸趣 TV 小編為大家分享的基于 Helm 和 Operator 的 K8S 應用管理的分析是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注丸趣 TV 行業資訊頻道。
