本篇文章給大家分享的是有關如何理解Kubernetes API中的Operator 和Operator Framework，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

創(chuàng)新互聯(lián)建站專注于潼關網(wǎng)站建設服務及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供潼關營銷型網(wǎng)站建設，潼關網(wǎng)站制作、潼關網(wǎng)頁設計、潼關網(wǎng)站官網(wǎng)定制、微信小程序服務，打造潼關網(wǎng)絡公司原創(chuàng)品牌,更為您提供潼關網(wǎng)站排名全網(wǎng)營銷落地服務。

一、operator 概述

基本概念

首先介紹一下本文內(nèi)容所涉及到的基本概念。

• CRD (Custom Resource Definition): 允許用戶自定義 Kubernetes 資源，是一個類型；

• CR (Custom Resourse): CRD 的一個具體實例；

• webhook: 它本質上是一種 HTTP 回調，會注冊到 apiserver 上。在 apiserver 特定事件發(fā)生時，會查詢已注冊的 webhook，并把相應的消息轉發(fā)過去。

按照處理類型的不同，一般可以將其分為兩類：一類可能會修改傳入對象，稱為 mutating webhook；一類則會只讀傳入對象，稱為 validating webhook。

• 工作隊列: controller 的核心組件。它會監(jiān)控集群內(nèi)的資源變化，并把相關的對象，包括它的動作與 key，例如 Pod 的一個 Create 動作，作為一個事件存儲于該隊列中；

• controller:它會循環(huán)地處理上述工作隊列，按照各自的邏輯把集群狀態(tài)向預期狀態(tài)推動。不同的 controller 處理的類型不同，比如 replicaset controller 關注的是副本數(shù)，會處理一些 Pod 相關的事件；

• operator:operator 是描述、部署和管理 kubernetes 應用的一套機制，從實現(xiàn)上來說，可以將其理解為 CRD 配合可選的 webhook 與 controller 來實現(xiàn)用戶業(yè)務邏輯，即 operator = CRD + webhook + controller。

常見的 operator 工作模式

工作流程：

1. 用戶創(chuàng)建一個自定義資源 (CRD)；

2. apiserver 根據(jù)自己注冊的一個 pass 列表，把該 CRD 的請求轉發(fā)給 webhook；

3. webhook 一般會完成該 CRD 的缺省值設定和參數(shù)檢驗。webhook 處理完之后，相應的 CR 會被寫入數(shù)據(jù)庫，返回給用戶；

4. 與此同時，controller 會在后臺監(jiān)測該自定義資源，按照業(yè)務邏輯，處理與該自定義資源相關聯(lián)的特殊操作；

5. 上述處理一般會引起集群內(nèi)的狀態(tài)變化，controller 會監(jiān)測這些關聯(lián)的變化，把這些變化記錄到 CRD 的狀態(tài)中。

這里是從 High-Level 大概介紹一下，后面會結合案例重新梳理。

二、operator framework 實戰(zhàn)

operator framework 概述

在開始之前，首先介紹一下 operator framework。 它實際上給用戶提供了 webhook 和 controller 的框架，它的主要意義在于幫助開發(fā)者屏蔽了一些通用的底層細節(jié)，不需要開發(fā)者再去實現(xiàn)消息通知觸發(fā)、失敗重新入隊等，只需關注被管理應用的運維邏輯實現(xiàn)即可。

主流的 operator framework 主要有兩個：kubebuilder和 operator-sdk。

兩者實際上并沒有本質的區(qū)別，它們的核心都是使用官方的 controller-tools 和 controller-runtime。不過細節(jié)上稍有不同，比如 kubebuilder 有著更為完善的測試與部署以及代碼生成的腳手架等；而 operator-sdk 對 ansible operator 這類上層操作的支持更好一些。

kuberbuildere 實戰(zhàn)

這里的實戰(zhàn)選用的是 kuberbuilder。案例選用的是阿里云對外開放的 kruise 項目下的 SidercarSet。

SidercarSet 的功能就是負責給 Pod 插入 sidecar 容器（也稱為輔助容器），例如可以插入一些監(jiān)控，日志采集來豐富這個 Pod 的功能，然后根據(jù)插入的狀態(tài)、Pod 的狀態(tài)反過來更新 SidercarSet 以記錄這些輔助容器的狀態(tài)。

Step 1: 初始化

操作：新建一個 gitlab 項目，運行 “kubebuilder init —domain=kruise.io”。

參數(shù)解讀：domain 指定了后續(xù)注冊 CRD 對象的 Group 域名。

效果解讀：拉取依賴代碼庫、生成代碼框架、生成 Makefile/Dockerfile 等工具文件。

我們來看一下它具體生成的內(nèi)容_(為了方便演示，實際生成文件做了部分刪減)：

具體的內(nèi)容大家可以在實戰(zhàn)的時候自己進行詳細的確認。

Step 2: 創(chuàng)建 API

操作：運行 “kubebuilder create api —group apps —version v1alpha1 —kind SidecarSet —namespace=false”
實際上不僅會創(chuàng)建 API，也就是 CRD，還會生成 Controller 的框架。

參數(shù)解讀：- group 加上之前的 domian 即此 CRD 的 Group: apps.kruise.io；

• version 一般分三種，按社區(qū)標準：

• v1alpha1: 此 api 不穩(wěn)定，CRD 可能廢棄、字段可能隨時調整，不要依賴；

• v1beta1: api 已穩(wěn)定，會保證向后兼容，特性可能會調整；

• v1: api 和特性都已穩(wěn)定；

• kind: 此 CRD 的類型，類似于社區(qū)原生的 Service 的概念；

• namespaced: 此 CRD 是全局唯一還是 namespace 唯一，類似 node 和 Pod。

它的參數(shù)基本可以分為兩類。group, version, kind 基本上對應了 CRD 元信息的三個重要組成部分。這里給出了一些常見的標準，大家實際使用的時候可以參考一下。namespaced 則用于指定我們剛剛創(chuàng)建的 CRD 時全局唯一的（如 node）還是 namespace 唯一的（如 Pod）。這里用了 false，即指定 SidecarSet 為全局唯一的。

效果解讀：

生成了 CRD 和 controller 的框架，后面需要手工填充代碼。

實際結果如下圖所示：

我們重點關注是圖中藍色字體部分。sidecarset_types.go 就是定義 CRD 的地方，需要我們填充。sidecarset_controller.go 則用于定義 controller，同樣需要進行填充。

Step 3: 填充 CRD

1. 生成的 CRD 位于 “pkg/apis/apps/v1alpha1/sidecarset_types.go”，通常需要進行如下兩個操作：

(1) 調整注釋

code generator 依賴注釋生成代碼，因此有時需要調整注釋。以下列出了本次實戰(zhàn)中 SidecarSet 需要調整的注釋：

+genclient:nonNamespaced: 生成非 namespace 對象；
+kubebuilder:subresource:status: 生成 status 子資源；
+kubebuilder:printcolumn:name=”MATCHED”,type=’integer’,JSONPath=”.status.matchedPods”,description=”xxx”: kubectl get sidecarset： 后續(xù)展示相關。

(2) 填充字段

填充字段是令用戶的 CRD 實際生效、實際有意義的重要部分。

• SidecarSetSpec: 填充 CRD 描述信息；

• SidecarSetStatus: 填充 CRD 狀態(tài)信息。

  2. 填充完運行 make 重新生成代碼即可

需要注意的是，研發(fā)人員無需參與 CRD 的 grpc 接口、編解碼等 controller 的底層實現(xiàn)。

實際的填充如下圖所示：

SidecarSet 的功能是給 Pod 注入 Sidecar，為了完成該功能，我們在 SidecarSetSpec（左圖） 定義了兩個主要信息：一個是用于選擇哪些 Pod 需要被注入的 Selector；一個是定義 Sidecar 容器的 Containers。

在 SidecarSetStatus（右圖）中定義了狀態(tài)信息，MatchedPods 反映的是該 SidecarSet 實際匹配了多少 Pod，UpdatedPods 反映的是已經(jīng)注入了多少，ReadyPods 反映的則是有多少 Pod 已經(jīng)正常工作了。

完整的內(nèi)容可以參考 該文檔。

Step 4: 生成 webhook 框架

1. 生成 mutating webhook，運行：

“kubebuilder alpha webhook —group apps —version v1alpha1 —kind SidecarSet —type=mutating —operations=create”

“kubebuilder alpha webhook —group core —version v1 —kind Pod —type=mutating —operations=create”

2. 生成 validating webhook，運行：

“kubebuilder alpha webhook —group apps —version v1alpha1 —kind SidecarSet —type=validating —operations=create,update”

參數(shù)解讀：

• group/kind 描述需要處理的資源對象；

• type 描述需要生成哪種類型的框架；

• operations 描述關注資源對象的哪些操作。

效果解讀：

• 生成了 webhook 框架，后面需要手工填充代碼

實際生成結果如下圖所示：

我們執(zhí)行了三條命令，分別生成了三個不同的需要填充的 handler 中（上圖藍色字體部分）。這里先不提，在下一步填充操作中再對其詳細講解。

Step 5: 填充 webhook

生成的 webhook handler 分別位于：

• pkg/webhook/default_server/sidecarset/mutating/xxx_handler.go

• pkg/webhook/default_server/sidecarset/validating/xxx_handler.go

• pkg/webhook/default_server/pod/mutating/xxx_handler.go

需要改寫、填充的一般包括以下兩個部分：

• 是否需要注入 K8s client：取決于除了傳入的 CRD 以外是否還需要其它資源。在本實戰(zhàn)中，不僅要關注 SidecarSet，同時還要注入 Pod，因此需要注入 K8s client；

• 填充 webhook 的關鍵方法：即 mutatingSidecarSetFn 或 validatingSidecarSetFn。由于待操作資源對象指針已經(jīng)傳入，因此直接調整該對象屬性即可完成 hook 的工作。

我們來看一下實際的填充結果。

因為第四步我們定義了三個：sidecarset mutating、sidecarset mutaing、pod mutating。

先來看上圖左側的 sidecarset mutating，首先是 setDefaultSidecarSet 把默認值設置好，這也是 mutaing 最常做的事情。

上圖右側 validating 也是非常的標準，也是對 SidecarSet 一些字段進行校驗。

關于 pod mutaing 這里沒有做展示，這里面有些不同，這里面的 mutaingSidecarSetFn 不是進行默認值設置，而是獲取 setDefaultSidecarSet 的數(shù)值，然后注入到 Pod 里面。

Step 6: 填充 controller

生成的 controller 框架位于 pkg/controller/sidecarset/sidecarset_controller.go。主要有三點需要進行修改：

• 修改權限注釋。框架會自動生成形如 //+kuberbuilder:rbac;groups=apps,resources=deployments/status,verbs=get;update;path 的注釋，我們可以按照自己的需求修改，該注釋最終會生成 rbac 規(guī)則；

• 增加入隊邏輯。缺省的代碼框架會填充 CRD 本身的入隊邏輯（如 SidecarSet 對象的增刪改都會加入工作隊列），如果需要關聯(lián)資源對象的觸發(fā)機制（如 SidecarSet 也需關注 Pod 的變化），則需手工新增它的入隊邏輯；

• 填充業(yè)務邏輯。修改 Reconcile 函數(shù)，循環(huán)處理工作隊列。Reconcile 函數(shù)主要完成「根據(jù) Spec 完成業(yè)務邏輯」和「將業(yè)務邏輯結果反饋回 status」兩部分。需要注意的是，如果 Reconcile 函數(shù)出錯返回 err，默認會重新入隊。

我們來看一下 SidecarSet 的 Controller 的填充結果：

addPod 中先取回該 Pod 對應的 SidecarSet 并將其加入隊列以便 Reconcile 進行處理。

Reconcile 將 SidercarSet 取出之后，根據(jù) Selector 選擇匹配的 Pod，最后根據(jù) Pod 當前的狀態(tài)信息計算出集群的狀態(tài)，然后回填到 CRD 的狀態(tài)中。

三、SidecarSet 的工作流程

最后我們再來重新梳理一下 SidecarSet 的工作流程以便我們理解 operator 是如何工作的。

1. 用戶創(chuàng)建一個 SidecarSet；

2. webhook 收到該 SidecarSet 之后，會進行缺省值設置和配置項校驗。這兩個操作完成之后，會完成真正的入庫，并返回給用戶；

3. 用戶創(chuàng)建一個 Pod；

4. webhook 會拿回對應的 SidecarSet，并從中取出 container 注入 Pod 中，因此 Pod 在實際入庫時就已帶有了剛剛的 sidecar；

5. controller 在后臺不停地輪詢，查看集群的狀態(tài)變化。第 4 步中的注入會觸發(fā) SidecarSet 的入隊，controller 就會令 SidecarSet 的 UpdatedPods 加 1。

以上就是 SidecarSet 前期一個簡單的功能實現(xiàn)。

這里我們再補充一個問題。一般的 webhook 由 controller 來完成業(yè)務邏輯、狀態(tài)更新，但這個不是一定的，兩者之一可以不是必須的。在以上的示例中就是由 webhook 完成主要的業(yè)務邏輯，無需 controller 的參與。

四、總結

主要內(nèi)容就到此為止了，這里為大家簡單總結一下：

• Operator 是 CRD 配合 可選的 webhook 和 controller，在 Kubernetes 體系下擴展用戶業(yè)務邏輯的一套機制；

• kubebuilder 是社區(qū)認可度很高的一種官方、標準化 Operator 框架；

• 按照上文實戰(zhàn)步驟，填充用戶自定義代碼，就可以很方便的實現(xiàn)一個 Operator。

以上就是如何理解Kubernetes API中的Operator 和Operator Framework，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降?。希望你能通過這篇文章學到更多知識。更多詳情敬請關注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

新聞標題：如何理解KubernetesAPI中的Operator和OperatorFramework
分享鏈接：http://chinadenli.net/article0/ppsooo.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供App開發(fā)、關鍵詞優(yōu)化、網(wǎng)站改版、品牌網(wǎng)站設計、App設計、面包屑導航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)