Operator 生命週期管理

01 背景

隨着 Kubernetes 成爲雲原生時代容器編排的事實標準，社區統一使用 CRD + Controller 的方式來擴展 Kubernetes 的能力，開發雲原生應用程序。這也就是 Operator 的實現。而構建 Operator 的門檻相對比較高，開發者需要了解 Kubernetes 的知識並具備相關的經驗。

Operator Framework 的出現爲開發制定了一整套框架，它整合了很多 Kubernetes 的專業知識，提供了一整套標準化工具方便在 Kubernetes 上輕鬆地創建應用程序。**其中 Operator Lifecycle Manager，簡稱 OLM，用來管理 Operator 的生命週期。**OLM 擴展了 Kubernetes 的能力，遵循 Kubernetes 交互設計理念，提供聲明式的方式來安裝、更新和管理 Operator 及其在集羣中的依賴。

Operator 和 OLM 的關係，就如同在操作系統裏，通過軟件包管理去安裝更新軟件。OLM 在設計時，自身組件也是用 Operator 方式進行部署。接下來着重介紹 OLM 的模型定義、組件和安裝使用。

02 模型

OLM 主要定義了以下資源對象模型：

2.1 CatalogSource

目錄源可以理解成 Operator 倉庫，它用來存儲 Operator 的元數據信息，包括了集羣服務版本信息、自定義資源信息、軟件包信息。可以查詢該目錄源下有哪些 Operator 可以提供使用。以下示例是 OLM 默認安裝提供的目錄源，利用社區 Operator 這個 repo 構建出的鏡像。該 repo 存放了大量社區 Operator 的元數據信息，並且各個 Operator 的開發者也會不定期地更新該倉庫，保證最新開發的 Operator 能夠提供給社區使用。官方 OperatorHub 也使用了這個 Operator 倉庫。

2.2 Subscription

訂閱表示要在某個目錄源下，安裝指定版本的 Operator。 通過訂閱某個頻道，獲取 Operator 的版本更新信息，以及在安裝時指定自動或者手動的批准策略。不同的批准策略會影響 Operator 的安裝升級。另外在訂閱信息裏可以添加一些配置，如環境變量、文件掛載等，用於最終 Operator 控制器的部署。

2.3. InstallPlan

在安裝 Operator 時，會創建一個如上所述的訂閱對象，然後會創建安裝計劃。 安裝計劃表示安裝 Operator 或者升級 Operator 到特定版本時，需要創建的一組資源。安裝版本就是 ClusterServiceVersion 的對應版本。這裏會根據上面訂閱對象裏定義的不同批准策略，進行以下操作：

安裝計劃會創建指定的資源，這裏主要包括 ClusterServiceVersion、CRD 和 Operator SDK 打包 Bundle 裏的其他一些依賴資源，並在訂閱所在的命名空間下安裝 Operator。這裏需要特別注意，當有一個 Operator 正在進行審批時，其他的 Operator 無法直接安裝。

2.4. OperatorGroup

Operator 組爲 Operator 的安裝提供多租戶支持。 當開發 Operator 時，可以設置該 Operator 部署集羣后的作用範圍，也就是通常說 watch 哪些命名空間。可以在 ClusterServiceVersion 裏設置具體的安裝模式。OLM 默認會在 operators 命名空間下安裝一個 global-operators 的 Operator 組，該組定義安裝在所有命名空間。當選擇安裝某個 Operator 時，根據不同的安裝模式，來確定是否創建 Operator 組。分爲以下幾種情形：

2.5. ClusterServiceVersion

集羣服務版本，簡稱 CSV，記錄了某個 Operator 具體的版本信息。 它提供了 Operator 元數據清單信息，主要包括了 Operator 的名稱、版本、圖標、描述、安裝模式、能力級別、維護者信息、安裝所需資源並提供 Operator 使用的一些 sample。在發佈新版本 Operator 時會提供版本更新策略。

03 架構

如圖所示，OLM 的組件包括 Package Server、Operator Registry、Catalog Operator、OLM Operator。

Package Server： 會在集羣上註冊 packagemanifest 的 APIService，通過 gRPC 協議調用 operator registry 服務，獲取 package 信息，並生成一個個 packagemanifest 對象。

Operator Registry： 上面 catalogsource 創建後，運行的 pod 其實就是 registry 服務。該服務存儲了 CSV、CRD、軟件包和頻道的元數據信息。package manifest 是 registry 中的一個實體對象，軟件包裏會包含多個頻道，每個頻道會指向特定的 CSV 版本。各個 CSV 版本之間會明確替換關係以及升級規則，這樣可以完成 Operator 每個中間版本的替換和安裝，最終達到運行頻道中最新版本的目的。

Catalog Operator： 負責目錄源的創建，並負責完成 Operator 部分資源的安裝。主要包括以下步驟：

  1. 監聽目錄源，可以定義不同類型的 catalogsource 資源對象。

  2. 當目錄源是 gRPC 類型時，可以使用 catalogsource 鏡像去運行 registry server 的 pod 或者直接指定一個已存在 registry server 的 gRPC 地址。當目錄源是 configmap 或 internal 類型時，會創建 configmap server。

  3. 由上述 Package Server 組件完成相應的功能。

  4. 安裝 Operator 時，會創建訂閱，訂閱信息裏會指定需要安裝 Operator 的版本。此時 Catalog Operator 控制器會運行 bundleUnpack job，該 job 會運行 pod 去解壓指定 Operator 的 bundle 鏡像，將 bundle 鏡像裏 Operator 的元數據信息，寫入到 configmap 資源對象裏。

  5. 控制器會爲訂閱創建相對應的 installplan 資源對象。

  6. 基於 configmap 裏提供的 Operator 元數據信息，調和 installplan 對象，添加需要安裝的資源信息。包括 CSV 資源、CSV 裏定義的依賴資源如 CRD、APIService 和 webhook、RBAC 相關資源以及 Operator 運行依賴的其他資源對象。

  7. 根據 installplan 對象裏的安裝內容，進行資源對象的創建。

另外控制器會監聽目錄源中，安裝包對應的頻道版本是否有更新，當有更新時，同樣會創建出新版本的 CSV 資源和 installplan 對象，以便進行更新升級。

OLM Operator： 在 Catalog Operator 控制器完成一些資源對象創建後，OLM Operator 的控制器主要調和 CSV 資源和 Operator 組資源，執行以下邏輯：

  1. OLM Operator 控制器會處理 CSV 的版本升級，並保持使用最新的版本。

  2. 當 Operator 作用在所有命名空間時，會將安裝命名空間下的 role、rolebinding 提升到 clusterrole 和 clusterrolebinding，這樣可以擁有集羣管理的權限。

  3. Operator 作用在指定多個命名空間或所有命名空間時，根據 olmconfig 裏 disableCopiedCSVs 的功能配置，在其他命名空間下拷貝安裝的源 CSV 去創建新的 CSV。

  4. 根據不同的安裝模式會選擇創建 Operator 組，當 Operator 作用在指定多個命名空間時，會到這些命名空間下創建 Operator 運行需要的 RBAC 權限。

  5. 根據訂閱信息裏的 config 配置和 CSV 裏定義的 deployment 的安裝信息，由 OLM Operator 完成每個 Operator 控制器部署。

04 安裝

在瞭解 OLM 的功能和基礎架構後，可以看一下 OLM 的安裝。這裏以 0.21.2 版本爲例，提供腳本和命令行安裝兩種方式。

4.1. 腳本

通過執行以下命令來安裝 OLM。

# curl -L
https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.21.2/install.sh -o install.sh
# chmod +x install.sh
# ./install.sh v0.21.2

4.2. 命令行

用戶只需要安裝好 Operator SDK 命令行工具，執行以下命令便可在集羣上進行 OLM 的安裝。

#operator-sdk olm install --version v0.21.2

大概的安裝過程如下：

  1. 部署 OLM 資源對象模型，即各個自定義資源對象 CRD；

  1. 部署 OLM olm-operator 和 catalog-operator 組件，創建名爲 olm-operator 和 catalog-operator 的 deployment ；

  2. 部署 OLM package-server 組件，先創建名爲 packageserver 的 CSV，CSV 創建後會部署一個名爲 packageserver 的 deployment；

  1. 部署一個 operator-registry 組件，先創建名爲 operatorhubio-catalog 的 catalogsource CR，catalog-operator 組件 watch 該資源並使用 catalogsource CR 裏指定鏡像生成 pod，該 pod 提供 50051 端口的 gRPC 服務；

安裝完後，可以調用 packagemanifest 的 API，獲取到目錄源提供了哪些 Operator。

05 使用

在完成 OLM 默認安裝後，用戶可以去安裝自己需要的 Operator。如安裝 Elasticsearch Operator，去創建一個訂閱信息。

創建一個 Operator 組，只在 eck1 和 eck2 命名空間下安裝 Elasticsearch Operator。

訂閱創建後，會創建安裝計劃，並進行 CSV 等資源的創建。

安裝成功後，會在集羣上安裝 CRDs，並在 eck1 命名空間下運行 elastic-operator 的 deployment，此時就可以在 eck1 和 eck2 命名空間下，創建 CR 使用 ECK 的功能。

06 總結

目前 Operator 技術已經成爲擴展 Kubernetes 能力的標準方式，Operator 的開發從像使用原生資源對象一樣擴展應用，發展到了封裝自己的組件，開發一些有狀態的、持久化的中間件，將能力以標準的方式暴露出來。在開發過程中，OLM 會提供軟件的打包、安裝和升級，並實現一些監控告警能力，更加高效地進行 Operator 的生命週期管理，簡化運維的複雜度。目前官方 OperatorHub 上提供的 Operator 已經有 297 個，涉及應用運行時、數據庫、可觀測性、消息中間件、開發工具等衆多類別。隨着像紅帽、亞馬遜、騰訊雲等巨頭公司的使用，Operator 的技術發展也會更加地成熟穩定。

參考資料

[1] https://operatorhub.io/

[2] https://github.com/k8s-operatorhub/community-operators

[3] https://operatorframework.io/operator-capabilities/

[4] https://github.com/operator-framework/operator-sdk

[5] https://github.com/operator-framework/operator-lifecycle-manager

[6] https://github.com/operator-framework/operator-registry

[7] https://github.com/operator-framework/community-operators

[8] https://olm.operatorframework.io/docs/getting-started/#installing-olm-in-your-cluster

本文作者  潘桂才

雲原生高級後端開發工程師

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Zozhr30_XYj9oTSu_WCkrA

猜你喜歡