如何理解Kubernetes API中的Operator 和Operator Framework

本篇文章給大家分享的是有關(guān)如何理解Kubernetes API中的Operator 和Operator Framework，小編覺(jué)得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話(huà)不多說(shuō)，跟著小編一起來(lái)看看吧。

一、operator 概述

基本概念

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

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

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

• webhook: 它本質(zhì)上是一種 HTTP 回調(diào)，會(huì)注冊(cè)到 apiserver 上。在 apiserver 特定事件發(fā)生時(shí)，會(huì)查詢(xún)已注冊(cè)的 webhook，并把相應(yīng)的消息轉(zhuǎn)發(fā)過(guò)去。

按照處理類(lèi)型的不同，一般可以將其分為兩類(lèi)：一類(lèi)可能會(huì)修改傳入對(duì)象，稱(chēng)為 mutating webhook；一類(lèi)則會(huì)只讀傳入對(duì)象，稱(chēng)為 validating webhook。

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

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

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

常見(jiàn)的 operator 工作模式

工作流程：

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

2. apiserver 根據(jù)自己注冊(cè)的一個(gè) pass 列表，把該 CRD 的請(qǐng)求轉(zhuǎn)發(fā)給 webhook；

3. webhook 一般會(huì)完成該 CRD 的缺省值設(shè)定和參數(shù)檢驗(yàn)。webhook 處理完之后，相應(yīng)的 CR 會(huì)被寫(xiě)入數(shù)據(jù)庫(kù)，返回給用戶(hù)；

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

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

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

二、operator framework 實(shí)戰(zhàn)

operator framework 概述

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

主流的 operator framework 主要有兩個(gè)：kubebuilder 和 operator-sdk。

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

kuberbuildere 實(shí)戰(zhàn)

這里的實(shí)戰(zhàn)選用的是 kuberbuilder。案例選用的是阿里云對(duì)外開(kāi)放的 kruise 項(xiàng)目下的 SidercarSet。

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

Step 1: 初始化

操作：新建一個(gè) gitlab 項(xiàng)目，運(yùn)行 “kubebuilder init —domain=kruise.io”。

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

效果解讀：拉取依賴(lài)代碼庫(kù)、生成代碼框架、生成 Makefile/Dockerfile 等工具文件。

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

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

Step 2: 創(chuàng)建 API

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

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

• version 一般分三種，按社區(qū)標(biāo)準(zhǔn)：

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

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

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

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

• namespaced: 此 CRD 是全局唯一還是 namespace 唯一，類(lèi)似 node 和 Pod。

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

效果解讀：

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

實(shí)際結(jié)果如下圖所示：

我們重點(diǎn)關(guān)注是圖中藍(lán)色字體部分。sidecarset_types.go 就是定義 CRD 的地方，需要我們填充。sidecarset_controller.go 則用于定義 controller，同樣需要進(jìn)行填充。

Step 3: 填充 CRD

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

(1) 調(diào)整注釋

code generator 依賴(lài)注釋生成代碼，因此有時(shí)需要調(diào)整注釋。以下列出了本次實(shí)戰(zhàn)中 SidecarSet 需要調(diào)整的注釋?zhuān)?/p>

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

(2) 填充字段

填充字段是令用戶(hù)的 CRD 實(shí)際生效、實(shí)際有意義的重要部分。

• SidecarSetSpec: 填充 CRD 描述信息；

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

  2. 填充完運(yùn)行 make 重新生成代碼即可

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

實(shí)際的填充如下圖所示：

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

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

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

Step 4: 生成 webhook 框架

1. 生成 mutating webhook，運(yùn)行：

“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，運(yùn)行：

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

參數(shù)解讀：

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

• type 描述需要生成哪種類(lèi)型的框架；

• operations 描述關(guān)注資源對(duì)象的哪些操作。

效果解讀：

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

實(shí)際生成結(jié)果如下圖所示：

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

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

需要改寫(xiě)、填充的一般包括以下兩個(gè)部分：

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

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

我們來(lái)看一下實(shí)際的填充結(jié)果。

因?yàn)榈谒牟轿覀兌x了三個(gè)：sidecarset mutating、sidecarset mutaing、pod mutating。

先來(lái)看上圖左側(cè)的 sidecarset mutating，首先是 setDefaultSidecarSet 把默認(rèn)值設(shè)置好，這也是 mutaing 最常做的事情。

上圖右側(cè) validating 也是非常的標(biāo)準(zhǔn)，也是對(duì) SidecarSet 一些字段進(jìn)行校驗(yàn)。

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

Step 6: 填充 controller

生成的 controller 框架位于 pkg/controller/sidecarset/sidecarset_controller.go。主要有三點(diǎn)需要進(jìn)行修改：

• 修改權(quán)限注釋。框架會(huì)自動(dòng)生成形如 //+kuberbuilder:rbac;groups=apps,resources=deployments/status,verbs=get;update;path 的注釋?zhuān)覀兛梢园凑兆约旱男枨笮薷模撟⑨屪罱K會(huì)生成 rbac 規(guī)則；

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

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

我們來(lái)看一下 SidecarSet 的 Controller 的填充結(jié)果：

addPod 中先取回該 Pod 對(duì)應(yīng)的 SidecarSet 并將其加入隊(duì)列以便 Reconcile 進(jìn)行處理。

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

三、SidecarSet 的工作流程

最后我們?cè)賮?lái)重新梳理一下 SidecarSet 的工作流程以便我們理解 operator 是如何工作的。

1. 用戶(hù)創(chuàng)建一個(gè) SidecarSet；

2. webhook 收到該 SidecarSet 之后，會(huì)進(jìn)行缺省值設(shè)置和配置項(xiàng)校驗(yàn)。這兩個(gè)操作完成之后，會(huì)完成真正的入庫(kù)，并返回給用戶(hù)；

3. 用戶(hù)創(chuàng)建一個(gè) Pod；

4. webhook 會(huì)拿回對(duì)應(yīng)的 SidecarSet，并從中取出 container 注入 Pod 中，因此 Pod 在實(shí)際入庫(kù)時(shí)就已帶有了剛剛的 sidecar；

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

以上就是 SidecarSet 前期一個(gè)簡(jiǎn)單的功能實(shí)現(xiàn)。

這里我們?cè)傺a(bǔ)充一個(gè)問(wèn)題。一般的 webhook 由 controller 來(lái)完成業(yè)務(wù)邏輯、狀態(tài)更新，但這個(gè)不是一定的，兩者之一可以不是必須的。在以上的示例中就是由 webhook 完成主要的業(yè)務(wù)邏輯，無(wú)需 controller 的參與。

四、總結(jié)

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

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

• kubebuilder 是社區(qū)認(rèn)可度很高的一種官方、標(biāo)準(zhǔn)化 Operator 框架；

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

以上就是如何理解Kubernetes API中的Operator 和Operator Framework，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見(jiàn)到或用到的。希望你能通過(guò)這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注億速云行業(yè)資訊頻道。