一文詳解雲上自動化部署集羣管理工具 Nebula Operator

本文首發於 Nebula Graph 公衆號：Nebula Operator 開源啦！一文詳解這個雲上自動化部署集羣管理工具

在介紹 Nebula Operator 以前，讓咱們先來了解下什麼是 Operator。

Operator 是一種封裝、部署和管理 Kubernetes 應用的方法，經過擴展 Kubernetes API 的功能，來管理用戶建立、配置和管理複雜應用的實例。它基於自定義資源 CRD 和控制器概念構建，涵蓋了特定領域或應用的知識，用於實現其所管理軟件的整個生命週期的自動化。

在 Kubernetes 中，控制平面的控制器實施控制循環，反覆比較集羣的指望狀態和實際狀態。若是集羣的實際狀態與指望狀態不符，控制器將繼續協調內部業務邏輯直到應用更新爲指望狀態。

Nebula Operator 將 NebulaGraph 的部署管理抽象成自定義資源 CRD，經過 StatefulSet、Service、ConfigMap 等多個內置的 API 對象組合在一塊兒，把平常管理維護 Nebula Graph 的流程編寫成控制循環，當 CR 實例提交時，Nebula Operator 按照控制流程驅動數據庫集羣向終態轉移。

Nebula Operator 功能介紹

CRD 定義

下面結合部署 nebula 集羣的 CR 文件，來了解下 Nebula Operator 的核心功能。

apiVersion: apps.nebula-graph.io/v1alpha1
kind: NebulaCluster
metadata:
  name: nebula
  namespace: default
spec:
  graphd:
    resources:
      requests:
        cpu: "500m"
        memory: "500Mi"
    replicas: 1
    image: vesoft/nebula-graphd
    version: v2.0.0
    storageClaim:
      resources:
        requests:
          storage: 2Gi
      storageClassName: gp2
  metad:
    resources:
      requests:
        cpu: "500m"
        memory: "500Mi"
    replicas: 1
    image: vesoft/nebula-metad
    version: v2.0.0
    storageClaim:
      resources:
        requests:
          storage: 2Gi
      storageClassName: gp2
  storaged:
    resources:
      requests:
        cpu: "500m"
        memory: "500Mi"
    replicas: 3
    image: vesoft/nebula-storaged
    version: v2.0.0
    storageClaim:
      resources:
        requests:
          storage: 2Gi
      storageClassName: gp2
  reference:
    name: statefulsets.apps
    version: v1
  schedulerName: default-scheduler
  imagePullPolicy: IfNotPresent
複製代碼

spec 裏須要重點關注三個描述部分：graphd、metad、storaged，他們分別表示 Graph 服務、Meta 服務、Storage 服務，控制器會在協調循環裏依次檢查內置的 API 對象 StatefulSet、Service、ConfigMap 是否就緒，假如某個依賴的 API 對象沒有建立成功或者某個 Nebula Graph 組件服務協調異常，控制器就會結束返回，等待下一次協調，並重復這個過程。

目前 CRD 裏提供的配置參數還不夠豐富，只覆蓋了最核心的 resource、replicas、image、schedulerName 等運行過程當中必不可少的配置參數，將來 Nebula Operator 會根據使用場景進一步豐富配置參數。

擴縮容

Storage 擴容分爲兩個階段，第一個階段須要等待全部新增擴容的 Pod 狀態爲 Ready，第二個階段執行數據 Balance Data 操做，數據 Balance 的任務由 CRD StorageBalancer 定義，這裏將控制器副本的擴容流程跟數據 Balance 流程解耦，能夠實現數據 Balance 任務的定製化，好比：添加任務執行時間，在業務流量較低時執行，可有效減少數據遷移對於線上服務的影響，這也符合 Nebula Graph 自己的設計理念：沒有采用徹底自動化 Balance 方式，Balance 時機由用戶本身控制。

Storage 縮容和擴容是一個相反的過程，縮容前須要安全移除節點，內部對應的就是 BALANCE DATA REMOVE $host_list 指令，等待移除節點任務完成後，再執行 Storage Pod 的縮容操做。

注：下圖只作解釋說明，不作真實配置參考，在高可用場景下，須要保證 3 副本實例在線。

調度均衡

在調度部分，Nebula Operator 提供了兩種選擇，可使用默認調度器或者基於 scheduler extender 接口的調度器。

默認調度器的拓撲分佈約束能夠控制 Pod 在集羣拓撲域內均勻分佈，Nebula Operator 提供了默認的節點標籤 kubernetes.io/hostname 的均勻分佈，將來會支持自定義節點標籤配置。這裏沒有選擇基於親和性調度策略主要是由於親和性本質上是控制 Pod 如何被堆疊或是打散，PodAffinity 是將多個 Pod 調度到特定的拓撲域，這是堆疊調度；PodAntiAffinity 則是保證特定拓撲域內只有一個 Pod，這是打散調度，可是這些調度策略沒法應對儘量均勻分佈的場景，尤爲是在分佈式應用場景下，須要實現高可用分佈在多個拓撲域。

固然，若是你使用的 Kubernetes 版本較低，沒法體驗拓撲分佈約束的特性，還有 Nebula-Scheduler 調度器供你選擇。它的核心邏輯就是保證每一個組件的 Pod 能夠均勻分佈在指定拓撲域上。

工做負載控制器

Nebula Operator 計劃支持多種工做負載控制器，經過使用 reference 配置項，可自主地選擇使用哪種工做負載控制器，當前在原生的 StatefulSet 基礎上，Nebula Operator 還額外支持社區版 OpenKruise 的 AdvancedStatefulSet。用戶可根據自身業務的須要，在 Nebula Operator 中使用如原地升級、指定節點下線等高級特性，固然這也須要在 Operator 內部實現相應的配置，目前只支持原地升級的參數。

reference:
    name: statefulsets.apps
    version: v1
複製代碼

其餘功能

其餘諸如 WebHook 提供高可用模式下的配置校驗，自定義參數配置更新等功能就不額外介紹了，這些特性都是爲了讓你經過 Nebula Operator 管理 Nebula Graph 集羣更加的安全方便，具體細節能夠閱讀 GitHub 上的文檔，這裏不過多闡述。

FAQ

Nebula Operator 是否能夠在 Kubernetes 以外使用？

不能夠，Operator 是依託於 Kubernetes 運行的，它是 Kubernetes API 的擴展，這是 K8s 領域內的工具。

如何保障升級、擴縮容的穩定可用，失敗後可否回退？

建議提早作好數據備份，以避免失敗還能回退。Nebula Operator 目前還不支持操做前數據備份，後續會迭代支持上。

可否兼容 NebulaGraph v1.x 集羣？

v1.x 不支持內部域名解析，Nebula Operator 須要內部域名解析的這個特性，沒法兼容。

使用本地存儲是否保證集羣穩定？

目前沒法保證，使用本地存儲就意味着 Pod 與特定的節點有綁定關係，Operator 目前不具有使用本地存儲節點宕機後故障轉移的能力，使用網絡存儲沒有這個問題。

升級功能什麼時候能支持上？

Nebula Operator 須要跟 NebulaGraph 保持一致，待數據庫支持滾動升級後，Operator 會同步支持這個功能。

Nebula Operator 現已開源，歡迎訪問 GitHub：github.com/vesoft-inc/… 來嚐鮮~

來參加 Nebula Operator 喊你提需求活動，幫它成長爲你想要的樣子吧：Nebula Operator 由你話事