从零开始入门 K8s | Kubernetes API 编程利器：Operator 和 Operator Framework
作者? | ?夙興??阿里巴巴高級(jí)工程師
本文整理自《CNCF x Alibaba 云原生技術(shù)公開課》第 24 講，點(diǎn)擊“閱讀原文”直達(dá)課程頁(yè)面。
關(guān)注“阿里巴巴云原生”公眾號(hào)，回復(fù)關(guān)鍵詞**“入門”**，即可下載從零入門 K8s 系列文章 PPT。
導(dǎo)讀：本文將從實(shí)踐出發(fā)，結(jié)合案例來(lái)說(shuō)明，如何借助 Operator 開發(fā)框架來(lái)擴(kuò)展 Kubernetes API。內(nèi)容主要分為三個(gè)部分：首先會(huì)簡(jiǎn)單介紹一下 Operator 相關(guān)的知識(shí)；然后會(huì)介紹 Operator 開發(fā)框架并結(jié)合案例來(lái)詳細(xì)說(shuō)明整個(gè)開發(fā)過(guò)程；最后會(huì)結(jié)合案例的工作流程來(lái)重新說(shuō)明 Operator 是如何工作的。
一、operator 概述
基本概念
首先介紹一下本文內(nèi)容所涉及到的基本概念。
-
CRD (Custom Resource Definition): 允許用戶自定義 Kubernetes 資源，是一個(gè)類型；
-
CR (Custom Resourse): CRD 的一個(gè)具體實(shí)例；
-
webhook: 它本質(zhì)上是一種 HTTP 回調(diào)，會(huì)注冊(cè)到 apiserver 上。在 apiserver 特定事件發(fā)生時(shí)，會(huì)查詢已注冊(cè)的 webhook，并把相應(yīng)的消息轉(zhuǎn)發(fā)過(guò)去。
按照處理類型的不同，一般可以將其分為兩類：一類可能會(huì)修改傳入對(duì)象，稱為 mutating webhook；一類則會(huì)只讀傳入對(duì)象，稱為 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 處理的類型不同，比如 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)用戶業(yè)務(wù)邏輯，即 operator = CRD + webhook + controller。
常見的 operator 工作模式
工作流程：
這里是從 High-Level 大概介紹一下，后面會(huì)結(jié)合案例重新梳理。
二、operator framework 實(shí)戰(zhàn)
operator framework 概述
在開始之前，首先介紹一下 operator framework。 它實(shí)際上給用戶提供了 webhook 和 controller 的框架，它的主要意義在于幫助開發(fā)者屏蔽了一些通用的底層細(xì)節(jié)，不需要開發(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 這類上層操作的支持更好一些。
kuberbuildere 實(shí)戰(zhàn)
這里的實(shí)戰(zhàn)選用的是 kuberbuilder。案例選用的是阿里云對(duì)外開放的 kruise 項(xiàng)目下的 SidercarSet。
SidercarSet 的功能就是負(fù)責(zé)給 Pod 插入 sidecar 容器（也稱為輔助容器），例如可以插入一些監(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 域名。
效果解讀：拉取依賴代碼庫(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)整，不要依賴；
- v1beta1: api 已穩(wěn)定，會(huì)保證向后兼容，特性可能會(huì)調(diào)整；
- v1: api 和特性都已穩(wěn)定；
- kind: 此 CRD 的類型，類似于社區(qū)原生的 Service 的概念；
- namespaced: 此 CRD 是全局唯一還是 namespace 唯一，類似 node 和 Pod。
它的參數(shù)基本可以分為兩類。group, version, kind 基本上對(duì)應(yīng)了 CRD 元信息的三個(gè)重要組成部分。這里給出了一些常見的標(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 依賴注釋生成代碼，因此有時(shí)需要調(diào)整注釋。以下列出了本次實(shí)戰(zhàn)中 SidecarSet 需要調(diào)整的注釋：
+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) 填充字段
填充字段是令用戶的 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 描述需要生成哪種類型的框架；
- 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
需要改寫、填充的一般包括以下兩個(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 的注釋，我們可以按照自己的需求修改，該注釋最終會(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 是如何工作的。
以上就是 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ò)展用戶業(yè)務(wù)邏輯的一套機(jī)制；
- kubebuilder 是社區(qū)認(rèn)可度很高的一種官方、標(biāo)準(zhǔn)化 Operator 框架；
- 按照上文實(shí)戰(zhàn)步驟，填充用戶自定義代碼，就可以很方便的實(shí)現(xiàn)一個(gè) Operator。
“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的技術(shù)圈。”
總結(jié)
以上是生活随笔為你收集整理的从零开始入门 K8s | Kubernetes API 编程利器：Operator 和 Operator Framework的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 从零开始入门 K8s | Kuberne
- 下一篇： 轻松构建基于 Serverless 架构