容器化 | ClickHouse Operator 原理解析

語言: CN / TW / HK

作者:蘇厚鎮 青雲科技資料庫研究工程師

從事 RadonDB ClickHouse 相關工作,熱衷於研究資料庫核心。

通過《ClickHouse on K8s 部署篇》,對比了 RadonDB ClickHouse 叢集在 Kubernetes 中部署的幾種方案,表明使用 Operator 進行部署和管理是最方便快捷的。

那麼到底什麼才是 Operator,Operator 又是如何與 Kubernetes 進行協同工作的,Operator 的程式碼邏輯又是怎樣的?本篇將基於 Operator 基本概念和原始碼解析,深度解析 ClickHouse Operator 執行原理。

什麼是 Operator?

在 Kubernetes 官方文件[1]中,對 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.

簡單來說:Operator = 定製資源 + 控制器。

那麼定製資源和控制器又是什麼呢?

定製資源

在 Kubernetes 官方文件[1]中,對定製資源的定義如下:

Custom resources are extensions of the Kubernetes API. It represents a customization of a particular Kubernetes installation.

Kubernetes 提供了一系列的資源,包括 Statefulset、Service、Configmap 等。但是這些資源並不能完全滿足使用需求,例如在 K8s 中部署 ClickHouse 應用時,需定製一個 ClickHouse 應用資源。

Kubernetes 提供了兩種方式向叢集中新增定製資源:

  • CRD:無需程式設計。K8s 從 1.7 版本增加了 CRD 來擴充套件 API,通過 CRD 可以向 API 中增加新資源型別,無需修改 K8s 原始碼或建立自定義的 API server,該功能大大提高了 Kubernetes 的擴充套件能力。
  • API 聚合:需要程式設計。但支援對 API 行為進行更多的控制,例如資料如何儲存以及在不同 API 版本間如何轉換等。

ClickHouse Operator 在定製資源方面,選用了 CRD 方式新增定製資源。

但是使用 CRD 定製資源後,僅僅是讓 Kubernetes 能夠識別定製資源的身份。建立定製資源例項後,Kubernetes 只會將建立的例項儲存到資料庫中,並不會觸發任何業務邏輯。在 ClickHouse 資料庫儲存定製資源例項是沒有意義的,如果需要進行業務邏輯控制,就需要建立控制器

控制器

Controller 的作用就是監聽指定物件的新增、刪除、修改等變化,並針對這些變化做出相應的響應,關於 Controller 的詳細設計,可以參考 Harry (Lei) Zhang 老師在 twitter 上的分享,基本架構圖如下:

file

從圖中可看出,定製資源例項的變化會通過 Informer 存入 WorkQueue,之後 Controller 會消費 WorkQueue,並對其中的資料做出業務響應。

Operator 其實就是圖中除了 API Server 和 etcd 的剩餘部分。由於 Client、Informer 和 WorkQueue 是高度相似的,所以有很多專案可以自動化生成 Controller 之外的業務邏輯(如 Client、Informer、Lister),因此使用者只需要專注於 Controller 中的業務邏輯即可。

ClickHouse Operator 程式碼解析

程式碼結構

.
├── cmd         # metrics_exporter 和 operator 的入口函式
│   ├── metrics_exporter
│   └── operator
├── config      # ClickHouse 和 ClickHouse Operator 的配置檔案,會通過 ConfigMap 掛載到 pod
├── deploy      # 各類元件的部署指令碼和部署 yaml 檔案
│   ├── dev         # clickhouse operator 開發版本安裝部署
│   ├── grafana     # grafana 監控面板安裝部署
│   ├── operator    # clickhouse operator 安裝部署
│   ├── operator-web-installer
│   ├── prometheus  # prometheus 監控部署
│   └── zookeeper   # zookeeper 安裝部署
├── dev         # 各類指令碼,如映象生成、應用構建、應用啟動等
├── dockerfile  # 映象 dockerfile
├── docs        # 文件
├── grafana-dashboard
├── hack
├── pkg         # 程式碼邏輯
│   ├── announcer   # 通知器
│   ├── apis        # api, 定製資源型別
│   │   ├── clickhouse.radondb.com
│   │   └── metrics
│   ├── chop        # clickhouse operator 型別
│   ├── client      # 自動生成,作用參考上面的圖
│   │   ├── clientset
│   │   ├── informers
│   │   └── listers
│   ├── controller  # controller 邏輯,主要關心部分
│   ├── model       # controller 呼叫 model
│   ├── util        # util
│   └── version     # version 資訊
└── tests       # 自動測試程式碼

程式碼邏輯

以下程式碼均為簡化版,僅取核心邏輯部分。

Controller 中主要的工作邏輯存在於 Worker 中。

Run

Run 是 Worker 中整個工作邏輯入口。Run 是一個無休止的工作迴圈,期望在一個執行緒中執行。

func (w *worker) run() {
    ...
     
    for {
        // 消費 workqueue,該方法會阻塞,直到它可以返回一個專案
        item, shutdown := w.queue.Get()
​
        // 處理任務
        if err := w.processItem(item); err != nil {
            utilruntime.HandleError(err)
        }
​
        // 後置處理,從 workqueue 中刪除專案
        w.queue.Forget(item)
        w.queue.Done(item)
    }
     
    ...
}

processItem

processItem 處理 item,根據 item 的型別決定需要呼叫的處理邏輯。

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 建立或者更新 CHI
func (w *worker) updateCHI(old, new *chop.ClickHouseInstallation) error {
    ...
​
    // 判斷是否需要執行處理
    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)      // 如果沒有,則新增 finalizer 防止 CHI 被刪除
    } else {
        return w.finalizeCHI(new)   // 如果刪除,則無法繼續執行操作,返回
    }
​
    // 歸一化,方便後面使用
    old = w.normalize(old)
    new = w.normalize(new)
     
    actionPlan := NewActionPlan(old, new)   // 對比 old 和 new,生成 action plan
​
    // 進行一系列的標記,方便 reconcile 進行處理,如 add、update 等,程式碼省略
​
    // 執行 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 的專案
    actionPlan.WalkRemoved(
        func(cluster *chop.ChiCluster) {
            _ = w.deleteCluster(cluster)
        },
        func(shard *chop.ChiShard) {
            _ = w.deleteShard(shard)
        },
        func(host *chop.ChiHost) {
            _ = w.deleteHost(host)
        },
    )
    // 將新的 CHI 新增到監控中
    if !new.IsStopped() {
        w.c.updateWatch(new.Namespace, new.Name, chopmodel.CreatePodFQDNsOfCHI(new))
    }
     
    ...
}

reconcile

updateCHI 中最重要的方法即 reconcile,該方法根據新增的標記做實際的處理。 

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},不過貌似沒有?
        w.reconcileCluster,
        // 處理分片
        // 1. 處理 Shard svc,即 svc/shard-{CHIName}-{ClusterName}-{ShardName},不過貌似沒有?
        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 狀態
        // 6. 判斷 Host 是否正常執行
        // 7. 將副本新增到叢集中,如果 Host 出錯,則回滾
        w.reconcileHost,
        // 後置處理
        // 1. 更新 CHI configmap,即 configmap/chi-{CHIName}-common-configd
        w.reconcileCHIAuxObjectsFinal,
    )
}

總結

至此,便揭開了 Operator 的神祕面紗。如果對 Operator 有更多興趣,歡迎到 Github 程式碼庫檢視更多細節。

[1]. Kubernetes 官方文件 : https://kubernetes.io/docs/concepts/extend-kubernetes/operator/

[2]. RadonDB ClickHouse Kubernetes : https://github.com/radondb/radondb-clickhouse-operator/tree/chronus

推薦閱讀