作者:蘇厚鎮(zhèn) 青云科技數(shù)據(jù)庫(kù)研究工程師
從事 RadonDB ClickHouse 相關(guān)工作,熱衷于研究數(shù)據(jù)庫(kù)內(nèi)核。
通過(guò)《ClickHouse on K8s 部署篇》告材,對(duì)比了 RadonDB ClickHouse 集群在 Kubernetes 中部署的幾種方案坤次,表明使用 Operator 進(jìn)行部署和管理是最方便快捷的。
那么到底什么才是 Operator斥赋,Operator 又是如何與 Kubernetes 進(jìn)行協(xié)同工作的缰猴,Operator 的代碼邏輯又是怎樣的?本篇將基于 Operator 基本概念和源代碼解析疤剑,深度解析 ClickHouse Operator 運(yùn)行原理滑绒。
什么是 Operator?
在 Kubernetes 官方文檔[1]中隘膘,對(duì) Operator 的定義如下:
Operators are software extensions to Kubernetes that make use of custom resources to manage applications and their components. Operators follow Kubernetes principles, notably the control loop.
簡(jiǎn)單來(lái)說(shuō):Operator = 定制資源 + 控制器疑故。
那么定制資源和控制器又是什么呢?
定制資源
在 Kubernetes 官方文檔[1]中弯菊,對(duì)定制資源的定義如下:
Custom resources are extensions of the Kubernetes API.
It represents a customization of a particular Kubernetes installation.
Kubernetes 提供了一系列的資源纵势,包括 Statefulset、Service误续、Configmap 等吨悍。但是這些資源并不能完全滿足使用需求,例如在 K8s 中部署 ClickHouse 應(yīng)用時(shí)蹋嵌,需定制一個(gè) ClickHouse 應(yīng)用資源育瓜。
Kubernetes 提供了兩種方式向集群中添加定制資源:
- CRD:無(wú)需編程。K8s 從 1.7 版本增加了 CRD 來(lái)擴(kuò)展 API栽烂,通過(guò) CRD 可以向 API 中增加新資源類型躏仇,無(wú)需修改 K8s 源碼或創(chuàng)建自定義的 API server,該功能大大提高了 Kubernetes 的擴(kuò)展能力腺办。
- API 聚合:需要編程焰手。但支持對(duì) API 行為進(jìn)行更多的控制,例如數(shù)據(jù)如何存儲(chǔ)以及在不同 API 版本間如何轉(zhuǎn)換等怀喉。
ClickHouse Operator 在定制資源方面书妻,選用了 CRD 方式添加定制資源。
但是使用 CRD 定制資源后躬拢,僅僅是讓 Kubernetes 能夠識(shí)別定制資源的身份躲履。創(chuàng)建定制資源實(shí)例后,Kubernetes 只會(huì)將創(chuàng)建的實(shí)例存儲(chǔ)到數(shù)據(jù)庫(kù)中聊闯,并不會(huì)觸發(fā)任何業(yè)務(wù)邏輯工猜。在 ClickHouse 數(shù)據(jù)庫(kù)保存定制資源實(shí)例是沒(méi)有意義的,如果需要進(jìn)行業(yè)務(wù)邏輯控制菱蔬,就需要?jiǎng)?chuàng)建控制器篷帅。
控制器
Controller 的作用就是監(jiān)聽(tīng)指定對(duì)象的新增史侣、刪除、修改等變化魏身,并針對(duì)這些變化做出相應(yīng)的響應(yīng)惊橱,關(guān)于 Controller 的詳細(xì)設(shè)計(jì),可以參考 Harry (Lei) Zhang 老師在 twitter 上的分享叠骑,基本架構(gòu)圖如下:
從圖中可看出李皇,定制資源實(shí)例的變化會(huì)通過(guò) Informer 存入 WorkQueue,之后 Controller 會(huì)消費(fèi) WorkQueue宙枷,并對(duì)其中的數(shù)據(jù)做出業(yè)務(wù)響應(yīng)掉房。
Operator 其實(shí)就是圖中除了 API Server 和 etcd 的剩余部分。由于 Client慰丛、Informer 和 WorkQueue 是高度相似的卓囚,所以有很多項(xiàng)目可以自動(dòng)化生成 Controller 之外的業(yè)務(wù)邏輯(如 Client、Informer诅病、Lister)哪亿,因此用戶只需要專注于 Controller 中的業(yè)務(wù)邏輯即可。
ClickHouse Operator 代碼解析
代碼結(jié)構(gòu)
.
├── cmd # metrics_exporter 和 operator 的入口函數(shù)
│ ├── metrics_exporter
│ └── operator
├── config # ClickHouse 和 ClickHouse Operator 的配置文件贤笆,會(huì)通過(guò) ConfigMap 掛載到 pod
├── deploy # 各類組件的部署腳本和部署 yaml 文件
│ ├── dev # clickhouse operator 開(kāi)發(fā)版本安裝部署
│ ├── grafana # grafana 監(jiān)控面板安裝部署
│ ├── operator # clickhouse operator 安裝部署
│ ├── operator-web-installer
│ ├── prometheus # prometheus 監(jiān)控部署
│ └── zookeeper # zookeeper 安裝部署
├── dev # 各類腳本蝇棉,如鏡像生成、應(yīng)用構(gòu)建芥永、應(yīng)用啟動(dòng)等
├── dockerfile # 鏡像 dockerfile
├── docs # 文檔
├── grafana-dashboard
├── hack
├── pkg # 代碼邏輯
│ ├── announcer # 通知器
│ ├── apis # api, 定制資源類型
│ │ ├── clickhouse.radondb.com
│ │ └── metrics
│ ├── chop # clickhouse operator 類型
│ ├── client # 自動(dòng)生成篡殷,作用參考上面的圖
│ │ ├── clientset
│ │ ├── informers
│ │ └── listers
│ ├── controller # controller 邏輯,主要關(guān)心部分
│ ├── model # controller 調(diào)用 model
│ ├── util # util
│ └── version # version 信息
└── tests # 自動(dòng)測(cè)試代碼
代碼邏輯
以下代碼均為簡(jiǎn)化版埋涧,僅取核心邏輯部分板辽。
Controller 中主要的工作邏輯存在于 Worker 中。
Run
Run 是 Worker 中整個(gè)工作邏輯入口棘催。Run 是一個(gè)無(wú)休止的工作循環(huán)劲弦,期望在一個(gè)線程中運(yùn)行。
func (w *worker) run() {
...
for {
// 消費(fèi) workqueue醇坝,該方法會(huì)阻塞邑跪,直到它可以返回一個(gè)項(xiàng)目
item, shutdown := w.queue.Get()
// 處理任務(wù)
if err := w.processItem(item); err != nil {
utilruntime.HandleError(err)
}
// 后置處理,從 workqueue 中刪除項(xiàng)目
w.queue.Forget(item)
w.queue.Done(item)
}
...
}
processItem
processItem 處理 item呼猪,根據(jù) item 的類型決定需要調(diào)用的處理邏輯呀袱。
func (w *worker) processItem(item interface{}) error {
...
switch item.(type) {
...
case *ReconcileChi:
reconcile, _ := item.(*ReconcileChi)
switch reconcile.cmd {
case reconcileAdd: // 處理定制資源的新增
return w.updateCHI(nil, reconcile.new)
case reconcileUpdate: // 處理定制資源的修改
return w.updateCHI(reconcile.old, reconcile.new)
case reconcileDelete: // 處理定制資源的刪除
return w.deleteCHI(reconcile.old)
}
utilruntime.HandleError(fmt.Errorf("unexpected reconcile - %#v", reconcile))
return nil
...
}
...
}
updateCHI
以最常用的 updateCHI 邏輯為例,看一下其處理邏輯郑叠。
// updateCHI 創(chuàng)建或者更新 CHI
func (w *worker) updateCHI(old, new *chop.ClickHouseInstallation) error {
...
// 判斷是否需要執(zhí)行處理
update := (old != nil) && (new != nil)
if update && (old.ObjectMeta.ResourceVersion == new.ObjectMeta.ResourceVersion) {
w.a.V(3).M(new).F().Info("ResourceVersion did not change: %s", new.ObjectMeta.ResourceVersion)
return nil
}
// 判斷 new chi 是否正在被刪除
if new.ObjectMeta.DeletionTimestamp.IsZero() {
w.ensureFinalizer(new) // 如果沒(méi)有,則添加 finalizer 防止 CHI 被刪除
} else {
return w.finalizeCHI(new) // 如果刪除明棍,則無(wú)法繼續(xù)執(zhí)行操作乡革,返回
}
// 歸一化,方便后面使用
old = w.normalize(old)
new = w.normalize(new)
actionPlan := NewActionPlan(old, new) // 對(duì)比 old 和 new,生成 action plan
// 進(jìn)行一系列的標(biāo)記沸版,方便 reconcile 進(jìn)行處理嘁傀,如 add、update 等视粮,代碼省略
// 執(zhí)行 reconcile(需要深入理解)
if err := w.reconcile(new); err != nil {
w.a.WithEvent(new, eventActionReconcile, eventReasonReconcileFailed).
WithStatusError(new).
M(new).A().
Error("FAILED update: %v", err)
return nil
}
// 后置處理
// 移除需要 delete 的項(xiàng)目
actionPlan.WalkRemoved(
func(cluster *chop.ChiCluster) {
_ = w.deleteCluster(cluster)
},
func(shard *chop.ChiShard) {
_ = w.deleteShard(shard)
},
func(host *chop.ChiHost) {
_ = w.deleteHost(host)
},
)
// 將新的 CHI 添加到監(jiān)控中
if !new.IsStopped() {
w.c.updateWatch(new.Namespace, new.Name, chopmodel.CreatePodFQDNsOfCHI(new))
}
...
}
reconcile
updateCHI 中最重要的方法即 reconcile细办,該方法根據(jù)添加的標(biāo)記做實(shí)際的處理。
func (w *worker) reconcile(chi *chop.ClickHouseInstallation) error {
w.a.V(2).M(chi).S().P()
defer w.a.V(2).M(chi).E().P()
w.creator = chopmodel.NewCreator(w.c.chop, chi) // cretea creator
return chi.WalkTillError(
// 前置處理
// 1. 處理 CHI svc蕾殴,即 svc/clickhouse-{CHIName}
// 2. 處理 CHI configmap笑撞,即 configmap/chi-{CHIName}-common-{configd/usersd}
w.reconcileCHIAuxObjectsPreliminary,
// 處理集群
// 1. 處理 Cluster svc,即 svc/cluster-{CHIName}-{ClusterName}钓觉,不過(guò)貌似沒(méi)有茴肥?
w.reconcileCluster,
// 處理分片
// 1. 處理 Shard svc,即 svc/shard-{CHIName}-{ClusterName}-{ShardName}荡灾,不過(guò)貌似沒(méi)有瓤狐?
w.reconcileShard,
// 處理副本
// 0. 將副本從集群中解除
// 1. 處理 Host Configmap,即 chi-{CHIName}-deploy-confd-{ClusterName}-{ShardName}-{HostName}
// 2. 處理 Host StatefulSet批幌,即 chi-{CHIName}-{ClusterName}-{ShardName}-{HostName}
// 3. 處理 Host PV础锐,即 chi-{CHIName}-{ClusterName}-{ShardName}-{HostName}
// 4. 處理 Host svc,即 chi-{CHIName}-{ClusterName}-{ShardName}-{HostName}
// 5. 解除 Host 的 add 狀態(tài)
// 6. 判斷 Host 是否正常運(yùn)行
// 7. 將副本添加到集群中荧缘,如果 Host 出錯(cuò)皆警,則回滾
w.reconcileHost,
// 后置處理
// 1. 更新 CHI configmap,即 configmap/chi-{CHIName}-common-configd
w.reconcileCHIAuxObjectsFinal,
)
}
總結(jié)
至此胜宇,便揭開(kāi)了 Operator 的神秘面紗耀怜。如果對(duì) Operator 有更多興趣,歡迎到 Github 代碼庫(kù)查看更多細(xì)節(jié)桐愉。
[1]. Kubernetes 官方文檔 : https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
[2]. RadonDB ClickHouse Kubernetes : https://github.com/radondb/radondb-clickhouse-operator/tree/chronus