【云駐共創】Kubernetes應用管理深度剖析

【云駐共創】Kubernetes應用管理深度剖析

本篇我們會聊到Kubernetes，也簡稱K8s。那么Kubernetes到底是什么呢？

簡單來說，它就是一個容器集群管理系統，是Google開源的一個項目。可能這時會有人想到另外一個容器管理引擎Docker，我們可以使用K8S來管理大規模的Docker容器，這里不過多描述。接下來將進入到K8S的世界。

本篇文章詳細介紹主流K8S應用管理生態的使用場景 ，深入了解Helm chart模板機制和Operator機制。

目錄

一、K8S應用模板有哪些使用場景？

1. 應用管理生態的使用場景

2. Helm chart模板機制

3. Operator機制

二、工具：Helm chart模板機制

1.Helm chart架構

2.Hook機制

三、大腦：Operator機制

1.Operator原理

2.Operator管理

四、總結

1.Helm小結

2.Operator小結

一、K8S應用模板有哪些使用場景？

1.應用管理生態的使用場景

當容器和云原生的理念被更多人認可，也會有更多的企業和軟件工程師將自己的應用搬到云原生或者容器上面來，那么在搬到容器或者容器集群上來，我們應該如何去更好的管理這些復雜應用以及相關的進程呢？特別是復雜應用需要完成資源間的編排、打包發布，標準化交付等。在Kubernetes里，我們可以使用Helm的模板-參數形式來支持對應用的多種資源進行編排，使之成為K8S領域最熱門的應用包管理工具。

2.Helm chart模板機制

Helm能夠很好的幫助我們實現K8s應用打包和標準化交付，對于實例運行態的生命周期管理，則通過資源的基礎生命周期動作來驅動。然而，對于一些復雜應用的生命周期管理，基本的資源操作是無法很好的能夠勝任，也需要根據應用它自身的特點，在一些關鍵生命周期結點上補充額外的動作。因此，CoreOS首先倡導了Operator的理念，即將特定應用的操作知識編碼到軟件中，利用功能強大的Kubernetes抽象來正確地運行和管理應用程序。

那么Helm能給我們帶來什么呢？

完整的應用通常不只是簡單的deployment，StatefulSet等負載資源，通常還包括配置的（服務）service，（數據交互）PV/PVC，（證書）configmap等一系列資源，我們在進行實例下發、升級、更新迭代等一系列生命周期操作時，這些資源都是需要我們統籌考慮的。

To：Helm可以幫助開發者完成應用打包、版本管理、應用的創建刪除、升級更新等生命周期管理操作。

3.Operator機制

以分布式系統為代表的有狀態應用，并不像Web應用一樣“開箱即用”，這些系統需要特定應用領域的知識才能擴展、升級和重新配置，同時防止數據丟失或者不可用。

怎么說呢，Operator算不上一個工具，只是我們為解決問題而存在的一種思路，將特定應用程序的操作知識編碼到軟件中，然后利用功能強大的Kubernetes抽象來正確的運行和管理應用程序。

那么Helm和Operator有什么區別或者不同的地方呢？

對比：Helm是一種標準化的普適性工具，主要目標是將K8S資源模塊化，以方便我們用來管理以及共享，并且在不同的配置中重用；Operator本質上是針對特定的場景去做有狀態服務，或者說針對擁有復雜應用的應用場景去簡化其運維管理的工具，Operator與特定應用是一對一的關系。

關系：Helm與Operator并不是完全獨立的，很多Operator能做的事情如應用集群初始化配置，監控更新等通過一些init Container，以及Helm的Hook機制，最終也能夠達到同等效果，不過這些配置可能顯得極為復雜且不易維護，得不償失。兩者實際上也有可以結合的場景，比如市面上很多開源項目的Operator本省就是通過Helm進行部署和管理的。

小結：Helm是為了配置分離，Operator則是通過復雜應用的自動化管理，兩者的出發點和面向的主要目標場景不同。

二、工具：Helm chart模板機制

1.Helm chart架構

這里我們先來看一下它的核心組件：

Chart Repository：Chart包儲存倉庫，可以是公共也可以是內部搭建的，只要符合通信協議的標準就可以。

Helm Client：終端用戶的命令行倉庫，可以用命令本地化初始一個包的框架，再往里面塞一些需要的模板，最后組合打包成一個業務包，然后去發布。

%2) 本地chart開發

%2) 管理倉庫

%2) 管理發布

%2) 與K8S Server端交互，發送chart（releas）安裝、升級或卸載請求

其中，最重要的Chart包實例：

其中chart包文件中的關鍵要素：

? Chart.yaml：chart包的元數據， 包含了chart信息(比如名稱、版本號)的YAML文件。

? Requirement：可選，列舉chart的依賴關系。

? Chart目錄：可選，列舉chart的依賴關系。

? Crds目錄：可選，自定義資源的定義，比如Crds的一些模板。

? Template目錄：模板目錄，內含go templa格式的模板文件。

? Value.yaml文件：chart的默認配置值，與templa結合，生成有效的kubernetes manifest文件。

? Values.schema.json文件：可選，JSON schema格式的value屬性和規格描述。

包文件內容實例：

這里我們將講到Template-Value的示例：

? Chart：創建Kubernetes應用程序所需的一組信息。Chart目錄：可選，chart依賴的其他chart。

? Config：包含了可以合并到chart中的配置信息，用于創建一個可發布的對象。

? Release：是一個與特定配置相結合的運行實例。

其中的內置對象有：

? Release：代表Release對象，屬性包括：Release.Name、Relaese.Namespace、Release.Revision等

? Values:表示Values.yaml文件數據

? Chart：表示Chart.yaml數據

? Files：用于訪問chart中非標準文件

? Capabilities：用于獲取K8S集群的一些信息

? -Capabilities.KubeVersion.Major：K8s的主版本

? Template：表示當前被執行的模板

? -Name：表示模板名

? -BasePath：表示路徑

其中Release代表一次應用發布，下面是Release對象包含的屬性字段：

1. Release.Name-release的名字，一般通過Chart.yaml定義，或者通過heml命令在安裝應用的時候指定

2. Release.Time-release安裝時間

3. Release.Namespace-K8s名字空間

4. Release.Revision-release版本號，每次更新都會加一

5. Release.lsUpgrade-true代表當前release是一次更新

6. Release.lsInstall-true代表當前release是一次安裝

7. Release.Service-release服務的名稱(始終是Helm)

To：在chart中以下劃線開頭的文件，成為子模板。

2.Hook機制

Kubernetes為容器在其生命周期內提供了兩種鉤子（hook），分別是postStart與preStop兩種事件：

PostStart：在容器啟動之后，PostStart hook會立即被執行，需要注意的是，容器里的ENTRYPOINT與PostStart hook的執行順序誰先誰后并不是確定的。

PreStop：在容器被終止之前被執行，會采用一種阻塞式的方式，也就是必須在PreStop hook執行完畢之后，銷毀容器的動作才會被執行。

Chart依賴管理：

Requirement.yaml文件會列出chart之間的依賴關系，有了依賴關系文件，就可以通過運行helm dependency update，將依賴關系文件所有指定的chart下載到chart/目錄下。

To：chart目錄的內容可以手動管理維護

三、大腦：Operator機制

1.Operator原理——擴展Kubernetes API，定義應用

標準的API定義：/apis/{group}/{version}/namespace/{namespace}/{kind}${name}

Operator原理-Kubernetes Controller機制（如圖）

Operator原理-實現Operator，管理應用（如圖）

實際上機制都是差不多的，只是思路有些變化。

2.Operator自身管理-Operator Framework

其中關鍵組件和概念：

1. Operator Lifecycle Manager：負責管理具體應用和Operator的生命周期。

2. 應用業務Operator：由開發者針對特定應用業務開發的Operator本身。

3. Operator Registry：存儲CSV和自定義資源定義等構成的應用配置。

4. ClusterServiceVersion（CSV）：由Operator元數據創建的YAML清單，可在集群中運行Operator。

5. Subscription:通過跟蹤安裝包中的channel保證CSV版本更新。

6. InstallPlan：計算自動安裝或升級CSV過程中需創建的資源集合。

四、總結

1.Helm小結：

我們可以將Helm看作Kubernetes下的apt-get/yum。Helm是Deist開發的一個用于Kubernetes的包管理器。

1. 對于應用發布者而言，可以通過Helm打包應用，管理應用依賴關系，管理應用版本并發布到應用軟件倉庫。

2. 對于使用者而言，使用Helm后不用需要了解Kubernetes的yaml語法并編寫應用部署文件，可以通過Helm下載并在Kubernetes上安裝需要的應用。

3. 除此之外，Helm還提供了Kubernetes上的軟件部署、刪除、升級、回滾應用的能力

2.Operator小結：

Kubernetes Operator是一種封裝、部署、和管理Kubernetes應用的方法。

Kubernetes Operator 是一種特定用于應用的控制器，可擴展Kubernetes API的功能，來代表Kubernetes用戶創建、配置和管理復雜應用的實例。

Operator基于基本Kubernetes資源和控制器概念構建，但又涵蓋了特定領域或應用的知識，用于實現其所管理軟件的整個生命周期的自動化。

本文整理自華為云社區【內容共創】活動第14期。

查看活動詳情：https://bbs.huaweicloud.com/blogs/336904

任務21：華為云云原生鉆石課程 11：Kubernetes應用管理深度剖析

應用平臺 應用管理與運維平臺 ServiceStage 上云必讀 Kubernetes

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。