容器化 | 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

推薦閲讀