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

從事 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

容器化 | ClickHouse Operator 原理決議