如何管理越來越多的 Operator？

作者 | 匡大虎、闞俊寶

OLM 的出現是為了幫助沒有如大數據，云監(jiān)控等領域知識的用戶能夠自助式地部署并管理像 etcd、大數據分析或監(jiān)控服務等復雜的分布式應用。因此從它的設計目標來說，OLM 官方希望實現面向云原生應用提供以下幾個方向上的通用管理能力，包括：

• 生命周期管理：管理 operator 自身以及監(jiān)控資源模型的升級和生命周期；

?

• 服務發(fā)現：發(fā)現在集群中存在哪些 operator，這些 operators 管理了哪些資源模型以及又有哪些 operators 是可以被安裝在集群中的；

?

• 打包能力：提供一種標準模式用于 operator 以及依賴組件的分發(fā)，安裝和升級；

?

• 交互能力：在完成了上述能力的標準化后，還需要提供一種規(guī)范化的方式（如 CLI）與集群中用戶定義的其他云服務進行交互。

上述在設計上的目標可以歸結為下面幾個方向上的需求：

• 命名空間部署：operator 和其管理資源模型必須被命名空間限制部署，這也是在多租環(huán)境下實現邏輯隔離和使用 RBAC 增強訪問控制的必要手段；

?

• 使用自定義資源（CR）定義：使用 CR 模型是定義用戶和 operator 讀寫交互的首選方式；同時在一個 operator 中也是通過 CRDs 聲明其自身或被其他 operator 管理的資源模型；operator 自身的行為模式配置也應當由 CRD 中的 fields 定義；

?

• 依賴解析：operator 在實現上只需要關心自身和其管理資源的打包，而不需關注與運行集群的連接；同時在依賴上使用動態(tài)庫定義，這里以 vault-operator 為例，其部署的同時需要創(chuàng)建一個 etcd 集群作為其后端存儲；這時我們在 vault-operator 中不應該直接包含 etcd operator 對應容器，而是應該通過依賴聲明的方法讓 OLM 解析對應依賴。為此在 operators 中需要有一套依賴相關的定義規(guī)范；

?

• 部署的冪等性：依賴解析和資源安裝可以重復執(zhí)行，同時在應用安裝過程中的問題是可恢復的；

?

• 垃圾收集：原則上盡可能依賴 Kubernetes 原生的垃圾收集能力，在刪除 OLM 自身的擴展模型 ClusterService 時需要同時清理其運行中的關聯資源；同時需要保證其他 ClusterService 管理的資源不被刪除；

?

• 支持標簽和資源發(fā)現。

基于上述設計目標，OLM 在實現中面向 Operator 定義了如下模型和組件。

首先，OLM 自身包含兩個 Operator：OLM Operator 和 Catalog Operator。它們分別管理了如下幾個 OLM 架構中擴展出的基礎 CRD 模型：

在 Operator 安裝管理的生命周期中 Deployment，Serviceaccount，RBAC 相關的角色和角色綁定是通過 OLM operator 創(chuàng)建的；Catalog Operator 負責 CRDs 和 CSVs 等資源的創(chuàng)建。

在介紹 OLM 的兩個 Operator 之前，我們先來看下 ClusterServiceVersion 的定義，作為 OLM 工作流程中的基本元素，它定義了在 OLM 管理下用戶業(yè)務應用的元數據和運行時刻信息的集合，包括了：

• 應用元數據（名稱，描述，版本定義，鏈接，圖標，標簽等），在下一章的實戰(zhàn)示例中我們會看到具體的定義；

?

• 安裝策略，包括 Operator 安裝過程中所需的部署集合和 service accounts，RBAC 角色和綁定等權限集合；

?

• CRDs：包括 CRD 的類型，所屬服務，Operator 交互的其他 K8s 原生資源和 spec，status 這些包含了模型語義信息的 fields 字段描述符等。

在對 ClusterServiceVersion 的概念有了基本了解后，我們來看下 OLM Operator。

首先 OLM Operator 的工作會基于 ClusterServiceVersion，一旦 CSV 中聲明的依賴資源都已經在目標集群中注冊成功，OLM Operator 就會負責去安裝這些資源對應的應用實例。注意這里 OLM Operator 并不會去關注 CSV 中聲明的依賴資源對應的 CRD 模型的創(chuàng)建注冊等工作，這些動作可以由用戶的手工 kubectl 操作或是由 Catalog Opetator 來完成。這樣的設計也給了用戶一個逐步適應 OLM 架構并最終應用起來的熟悉過程。另外，OLM Operator 對依賴資源對應自定義模型的監(jiān)聽可以是全局 all namespaces 的，也可以只限定在指定的 namespace 下。

接著我們來認識一下 Catalog Operator，它主要負責解析 CSV 中聲明的依賴資源定義，同時它通過監(jiān)聽 catalog 中安裝包對應 channels 的版本定義完成 CSV 對應的版本更新。

用戶可以通過創(chuàng)建 Subscription 模型來設置 channel 中所需安裝包和更新的拉取源，當一個可用更新被發(fā)現時，一個用戶對應的 InstallPlan 模型會在相應的 namespace 被創(chuàng)建出來。當然用戶也可以手動創(chuàng)建 InstallPlan，InstallPlan 實例中會包含目標 CSV 的定義和相關的 approval 審批策略，Catalog Operator 會創(chuàng)建相應的執(zhí)行計劃去創(chuàng)建 CSV 所需的依賴資源模型。一旦用戶完成審批，Catalog Operator 就會創(chuàng)建 InstallPlan 中的相關資源，此時剛才提及的 OLM Operator 關注的依賴資源條件得到滿足，CSV 中定義的 Operator 實例會由 OLM Operator 完成創(chuàng)建。

在上一小節(jié)中我們了解了 OLM 的基本組件模型和相關定義，本小節(jié)我們就來介紹一下它的基本架構，如下圖所示：

首先在 Operator Framework 中提供了兩個重要的元 Operator 和相應的擴展資源（如上節(jié)中介紹的 ClusterServiceVersion，InstallPlan 等），用于進行用戶應用 Operator 的生命周期管理。在自定義的 CSV 模型中定義了用戶部署 Operator 的各類資源組合，包括 Operator 是如何部署的，Operator 對應管理的自定義資源類型是什么以及使用了哪些 K8s 原生資源等。

在上節(jié)的定義中我們也了解到 OLM Operator 在安裝對應的 Operator 實例前要求其管理的自定義資源模型已經被注冊在目標安裝集群中，而這個動作可以來自于集群管理員手動 kubectl 方式的創(chuàng)建，也可以利用 Catalog Operator 完成，Catalog Operator 除了可以完成目標CRD模型的注冊，還負責資源模型版本的自動升級工作。其工作流程包括：

• 保證 CRDs 和 CSVs 模型的 cache 和 index 機制，用于對應模型的版本控制和注冊等動作；

?

• 監(jiān)聽用戶創(chuàng)建的未解析 InstallPlans:

• 尋找滿足依賴條件的 CSV 模型并將其加入到已解析資源中；

• 將所有被目標 Operator 管理或依賴的 CRD 模型加入到解析資源中；

• 尋找并管理每種依賴 CRD 對應 CSV 模型；

• 
  

• 監(jiān)聽所有被解析的 InstallPlan，在用戶審批或自動審批完成后創(chuàng)建所有對應的依賴資源；

• 監(jiān)聽 CataologSources 和 Subscriptions 模型并基于其變更創(chuàng)建對應的 InstallPlans。

一旦 OLM Operator 監(jiān)聽到 CSV 模板中安裝所需依賴資源已經注冊或是變更，就會啟動應用 Operator 的安裝和升級工作，并最終啟動 Operator 自身的工作流程，在 Kubernetes 集群中創(chuàng)建和管理對應的自定義資源實例模型。

在了解了 OLM 的基礎架構后，我們首先來看下 OLM 的安裝。在社區(qū)代碼中我們找到 OLM 各項部署資源對應的模板，用戶可以方便的通過修改相應部署參數完成定制化的 OLM 安裝。

在官方的發(fā)布公告中我們可以找到最新的發(fā)布版本和各版本對應的安裝說明。

這里以 0.13.0 版本為例，通過以下命令執(zhí)行自動化安裝腳本：

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

手動安裝 OLM 所需部署模板命令：

kubectl?apply?-f?https://github.com/operator-framework/operator-lifecycle-manager/releases/download/0.13.0/crds.yaml
kubectl?apply?-f?https://github.com/operator-framework/operator-lifecycle-manager/releases/download/0.13.0/olm.yaml

在通過 clone OLM 代碼倉庫到本地后，用戶可以執(zhí)行?make run-local?命令啟動 minikube，并通過 minikube 自帶 docker daemon 在本地 build OLM 鏡像，同時該命令會基于倉庫 deploy 目錄下的 local-values.yaml 作為配置文件構建運行本地 OLM，通過 kubectl -n local get deployments 可以驗證 OLM 各組件是否已經成功安裝運行。

另外針對用戶的定制化安裝需求，OLM 支持通過配置如下模板指定參數來生成定制化的部署模板并安裝。下面是其支持配置的模板參數：

#?sets?the?apiversion?to?use?for?rbac-resources.?Change?to?`authorization.openshift.io`?for?openshift
rbacApiVersion:?rbac.authorization.k8s.io
#?namespace?is?the?namespace?the?operators?will?_run_
namespace:?olm
#?watchedNamespaces?is?a?comma-separated?list?of?namespaces?the?operators?will?_watch_?for?OLM?resources.
#?Omit?to?enable?OLM?in?all?namespaces
watchedNamespaces:?olm
#?catalog_namespace?is?the?namespace?where?the?catalog?operator?will?look?for?global?catalogs.
#?entries?in?global?catalogs?can?be?resolved?in?any?watched?namespace
catalog_namespace:?olm
#?operator_namespace?is?the?namespace?where?the?operator?runs
operator_namespace:?operators

#?OLM?operator?run?configuration
olm:
??#?OLM?operator?doesn't?do?any?leader?election?(yet),?set?to?1
??replicaCount:?1
??#?The?image?to?run.?If?not?building?a?local?image,?use?sha256?image?references
??image:
????ref:?quay.io/operator-framework/olm:local
????pullPolicy:?IfNotPresent
??service:
????#?port?for?readiness/liveness?probes
????internalPort:?8080

#?catalog?operator?run?configuration
catalog:
??#?Catalog?operator?doesn't?do?any?leader?election?(yet),?set?to?1
??replicaCount:?1
??#?The?image?to?run.?If?not?building?a?local?image,?use?sha256?image?references
??image:
????ref:?quay.io/operator-framework/olm:local
????pullPolicy:?IfNotPresent
??service:
????#?port?for?readiness/liveness?probes
????internalPort:?8080

用戶可以通過以下方式進行模板的定制化開發(fā)和在指定集群中的安裝：

• 創(chuàng)建名稱如 my-values.yaml 的配置模板，用戶可以參考上述模板配置所需參數；

• 基于上述配置好的 my-values.yaml 模板，使用 package_release.sh 生成指定部署模板；

#?第一個參數為系統(tǒng)兼容的helm?chart目標版本
#?第二個參數為模板指定的輸出目錄
#?第三個參數為指定的配置文件路徑
./scripts/package_release.sh?1.0.0-myolm?./my-olm-deployment?my-values.yaml

• 部署指定目錄下的模板文件，執(zhí)行 kubectl apply -f ./my-olm-deployment/templates/；

最后，用戶可以通過環(huán)境變量 GLOBAL_CATALOG_NAMESPACE 定義 catalog operator 監(jiān)聽全局 catalogs 的指定 namespace，默認情況下安裝過程會創(chuàng)建 olm 命名空間并部署 catalog operator。

如同 apt/dkpg 和 yum/rpm 對于系統(tǒng)組件包的管理一樣，OLM 在管理 Operator 版本時也會遇到依賴解析和正在運行的 operator 實例的升級管理等問題。為了保證所有 operators 在運行時刻的可用性，OLM 在依賴解析和升級管理流程中需要保證：

• 不去安裝未注冊依賴 APIs 的 Operator 實例；

• 如果對于某個 Operator 的升級操作會破壞其關聯組件的依賴條件時，不去進行該升級操作。

下面我們通過一些示例來了解下當前 OLM 是如何處理版本迭代下的依賴解析：

首先介紹一下 CRD 的升級，當一個待升級的 CRD 只屬于單個 CSV 時，OLM 會立即對 CRD 進行升級；當 CRD 屬于多個 CSV 時，CRD 的升級需要滿足下列條件：

• 所有當前 CRD 使用的服務版本需要包含在新的 CRD 中；

• 所有關聯了 CRD 已有服務版本的 CR（Custom Resource）實例可以通過新 CRD schema 的校驗。

當你需要添加一個新版本的 CRD 時，官方推薦的步驟是：

1. 假如當前我們有一個正在使用的 CRD，它的版本是 v1alpha1，此時你希望添加一個新版本 v1beta1 并且將其置為新的 storage 版本，如下：

versions:
??-?name:?v1alpha1
????served:?true
????storage:?false
??-?name:?v1beta1
????served:?true
????storage:?true

2. 如果你的 CSV 中需要使用新版本的 CRD，我們需要保證 CSV 中的 owned 字段所引用的 CRD 版本是新的，如下所示：

customresourcedefinitions:
??owned:
??-?name:?cluster.example.com
????version:?v1beta1
????kind:?cluster
????displayName:?Cluster

3. 推送更新后的 CRD 和 CSV 到指定的倉庫目錄中。

當我們需要棄用或是刪除一個 CRD 版本時，OLM 不允許立即刪除一個正在使用中的 CRD 版本，而是需要首先通過將 CRD 中的 serverd 字段置為 false 來棄用該版本，然后這個不被使用的版本才會在接下來的 CRD 升級過程中被刪除。官方推薦的刪除或棄用一個 CRD 指定版本的步驟如下：

1. 將過期的棄用 CRD 版本對應的 serverd 字段標記為 false， 表示不再使用該版本同時會在下次升級時刪除此版本，如：

versions:
??-?name:?v1alpha1
????served:?false
????storage:?true

2. 如果當前即將過期的 CRD 版本中 storage 字段為 true，需要將其置為 false 同時將新版本的 storage 對應字段置為 true，比如：

versions:
??-?name:?v1alpha1
????served:?false
????storage:?false
??-?name:?v1beta1
????served:?true
????storage:?true

3. 基于上述修改更新 CRD 模型；

4. 在隨后的升級過程中，不在服務的過期版本將會從 CRD 中完成刪除，CRD 的版本終態(tài)為:

versions:
??-?name:?v1beta1
????served:?true
????storage:?true

注意在刪除指定版本的 CRD 過程中，我們需要保證該版本同時在 CRD status 中的 storedVersion 字段隊列中被刪除。當 OLM 發(fā)現某 storedversion 在新版本 CRD 中不會再使用時會幫助我們完成相應的刪除動作。另外我們需要保證 CSV 中關聯引用的 CRD 版本在老版本被刪除時及時更新。

下面我們來看一下兩個會引發(fā)升級失敗的示例以及 OLM 的依賴解析邏輯：

示例 1：假如我們有 A 和 B 兩個不同類型的 CRD。

• 使用 A 的 Operator 依賴 B

• 使用 B 的 Operator 有一個訂閱（Subscription）

• 使用 B 的 Operator 升級到了新版本 C 同時棄用了老版本 B

這樣的升級得到的結果是 B 對應的 CRD 版本沒有了對應使用它的 Operator 或 APIService，同時依賴它的 A 也將無法工作。

示例 2：假如我們有 A 和 B 兩個自定義 API。

• 使用 A 的 Operator 依賴 B

• 使用 B 的 Operator 依賴 A

• 使用 A 的 Operator 希望升級到 A2 版本同時棄用老版本 A，新的 A2 版本依賴 B2

• 使用 B 的 Operator 希望升級到 B2 版本同時棄用老版本 B，新的 B2 版本依賴 A2

此時如果我們只嘗試升級 A 而沒有同步地升級 B，即使系統(tǒng)可以找到適用的升級版本，也無法完成對應 Operator 的版本升級。

為了避免上述版本迭代中可能遇到的問題，OLM 所采用的依賴解析邏輯如下。

假設我們有運行在某一個 namespace 下的一組 operator：

• 對于該 namespace 下的每一個 subscription 訂閱，如果該 subscription 之前沒有被檢查過，OLM 會尋找訂閱對應 source/package/channel 下的最新版本 CSV，并臨時性地創(chuàng)建一個匹配新版本的 operator；如果是已知訂閱，OLM 會查詢對應 source/package/channel 的更新；

• 對于 CSV 中所依賴的每一個 API 版本，OLM 都會按照 sources 的優(yōu)先級挑選一個對應的 operator，如果找到同樣會臨時性地添加該依賴版本的新 operator，如果沒有找到對應的 operator 的話也會添加該依賴 API；

• 此時如果有不滿足 source 依賴條件的 API，系統(tǒng)會對被依賴的 operator 進行降級（回退到上一個版本）；為了滿足最終的依賴條件，這個降級過程會持續(xù)進行，最壞的情況下該 namespace 下的所有 operator 仍舊保持原先版本；

• 如果有新的 operator 完成解析并滿足了依賴條件，它會在集群中最終創(chuàng)建出來；同時會有一個相關的 subscription 去訂閱發(fā)現它的 channel/package 或是 source 以繼續(xù)查看是否有新版本的更新。

在了解了 OLM 的依賴解析和升級管理的基本原理后，我們來看下 OLM 升級相關的工作流程。

首先從上文中我們已經有所了解，ClusterServiceVersion（CSV），CatalogSource 和 Subscription 是 OLM 框架中和升級緊密相關的三種擴展模型。在 OLM 的生態(tài)系統(tǒng)中，我們通過 CatalogSource 來存儲如 CVS 這樣的 operator 元數據；OLM 會基于 CatalogSources，使用下 Operator 倉庫相關 API 去查詢可用或可升級的 operators；而在 CatalogSource 中，operators 通過 channels 來標識封裝好的不同版本安裝包。

當用戶希望升級某個 operator 時，可以通過 Subscription 來訂閱具體需要安裝哪個 channel 中指定版本的軟件包。如果訂閱中指定的包還沒有被安裝在目標集群中時，OLM 會安裝在 catalog/package/channel 等下載源的最新版本 operator。

在一個 CSV 定義中，我們可以通過 replaces 字段聲明需要替換的 operator，OLM 在收到請求后會從不同的 channels 中尋找能夠被安裝的 CSV 定義并最終將它們構建出一個 DAG（有向無環(huán)圖），在這個過程中 channels 可以被認為是更新 DAG 的入口。

在升級過程中，如果 OLM 發(fā)現在可升級的最新版本和當前版本之間還有未安裝的中間版本，系統(tǒng)會自動構建出一條升級路徑并保證路徑上中間版本的安裝。比如當前我們有一個正在運行的 operator，它的運行版本是 0.1.1，此時 OLM 在收到更新請求后通過訂閱的 channel 找到了 0.1.3 的最新可升級版本，同時還找到了 0.1.2 這個中間版本，此時 OLM 會首先安裝 0.1.2 版本 CSV 中對應的 operator 替換當前版本，并最終安裝 0.1.3 替換安裝成功后的 0.1.2 版本。

當然在某些狀況下，比如我們遇到了一個存在嚴重安全漏洞的中間版本時，這樣迭代升級每個版本的方式并不是一種合理和安全的方式。此時我們可以通過 skips 字段定制化安裝路徑以跳過指定的中間版本，如下所示：

apiVersion:?operators.coreos.com/v1alpha1
kind:?ClusterServiceVersion
metadata:
??name:?etcdoperator.v0.9.2
??namespace:?placeholder
??annotations:
spec:
????displayName:?etcd
????description:?Etcd?Operator
????replaces:?etcdoperator.v0.9.0
????skips:
????-?etcdoperator.v0.9.1

如果需要忽略多個版本的安裝，我們可以在 CSV 中使用如下定義：

olm.skipRange:?<semver?range>

其中版本范圍的定義可參考semver，一個 skipRange 的 CSV 示例如下：

apiVersion:?operators.coreos.com/v1alpha1
kind:?ClusterServiceVersion
metadata:
????name:?elasticsearch-operator.v4.1.2
????namespace:?placeholder
????annotations:
????????olm.skipRange:?'>=4.1.0?<4.1.2'

在 OLM 中，我們可以通過對 CatalogSource 模型來定義 InstallPlan 從哪里完成安裝包的自動下載和依賴解析，同時 Subscription 通過對 channel 的訂閱也可以從 CatalogSource 來拉取最新版本的安裝包。本小節(jié)中我們以官方社區(qū)的 operator-registry 為例介紹一下 CatalogSource 的安裝和基本使用方法。

operator-registry 主要由下列三部分組成：

• initializer：負責接收用戶上傳的以目錄為結構的 operator manifests，同時將數據導入到數據庫中；

?

• registry-server：包含存取 operator manifests 相關的 sqlite 數據庫服務，同時對外暴露 gRPC 協(xié)議接口的服務；

?

• configmap-server：負責向 registry-server 提供解析好的 operator manifest 相關 configmap（包含 operator bundle 相關的標簽或 CRD 和 CSV 等配置元數據），并存入 sqlite 數據庫中。

關于 operator manifes 的格式定義，在 operator-registry 中把在上傳目錄中包含的每一個 CSV 定義單元稱為一個“bundle”，每個典型的 bundle 由單個 CSV(ClusterServiceVersion)和包含其相關接口定義的單個或多個 CRD 組成，如下所示：

?#?bundle示例
?0.6.1
?├──?etcdcluster.crd.yaml
?└──?etcdoperator.clusterserviceversion.yaml

當導入 manifests 到數據庫時會包含如下的格式校驗：

• 每個 package 安裝包都需要至少定義一個 channel；

• 每一個 CSV 需要關聯一個安裝包中存在的 channel；

• 每一個 bundle 目錄中有且僅有一個對應的 CSV 定義；

• 如果 CSV 中包含相關 CRD 定義，該 CRD 必須也存在于 bundle 所在目錄中；

• 如果一個 CSV 在 replaces 定義中被其他 CSV 取代，則對應的新舊 CSV 均需要存在于 package 中。

對于 manifests 中不同軟件包對應的 bundle 目錄格式，原則上最好要保持一個清晰的目錄結構，這里我們來看官方的一個 manifest 示例，其他 manifest 示例請見：

manifests
├──?etcd
│???├──?0.6.1
│???│???├──?etcdcluster.crd.yaml
│???│???└──?etcdoperator.clusterserviceversion.yaml
│???├──?0.9.0
│???│???├──?etcdbackup.crd.yaml
│???│???├──?etcdcluster.crd.yaml
│???│???├──?etcdoperator.v0.9.0.clusterserviceversion.yaml
│???│???└──?etcdrestore.crd.yaml
│???├──?0.9.2
│???│???├──?etcdbackup.crd.yaml
│???│???├──?etcdcluster.crd.yaml
│???│???├──?etcdoperator.v0.9.2.clusterserviceversion.yaml
│???│???└──?etcdrestore.crd.yaml
│???└──?etcd.package.yaml
└──?prometheus
????├──?0.14.0
????│???├──?alertmanager.crd.yaml
????│???├──?prometheus.crd.yaml
????│???├──?prometheusoperator.0.14.0.clusterserviceversion.yaml
????│???├──?prometheusrule.crd.yaml
????│???└──?servicemonitor.crd.yaml
????├──?0.15.0
????│???├──?alertmanager.crd.yaml
????│???├──?prometheus.crd.yaml
????│???├──?prometheusoperator.0.15.0.clusterserviceversion.yaml
????│???├──?prometheusrule.crd.yaml
????│???└──?servicemonitor.crd.yaml
????├──?0.22.2
????│???├──?alertmanager.crd.yaml
????│???├──?prometheus.crd.yaml
????│???├──?prometheusoperator.0.22.2.clusterserviceversion.yaml
????│???├──?prometheusrule.crd.yaml
????│???└──?servicemonitor.crd.yaml
????└──?prometheus.package.yaml

通過官方提供的Dockerfile 我們可以構建出一個包含了 initializer 和 registry-server 的最小集 operator-registry 鏡像。

下面我們來看下 operator-registry 與 OLM 的集成，這里我們需要創(chuàng)建一個 CatalogSource 對象并指定使用我們 operator-registry 對應鏡像，如下所示：

apiVersion:?operators.coreos.com/v1alpha1
kind:?CatalogSource
metadata:
??name:?example-manifests
??namespace:?default
spec:
??sourceType:?grpc
??image:?example-registry:latest

當上面的 example-manifest 完成啟動后，我們可以通過 pod 日志查看相應的 gRPC 后端服務是否已建立：

$?kubectl?logs?example-manifests-wfh5h?-n?default

time="2019-03-18T10:20:14Z"?level=info?msg="serving?registry"?database=bundles.db?port=50051

同時一旦 catalog 完成加載，OLM 中 package-server 組件就會開始讀取目錄中定義好的 Operators 軟件包，通過下面的命令我們可以 Watch 當前可用的 Operator package：

$?watch?kubectl?get?packagemanifests

[...]

NAME?????????????????????AGE
prometheus???????????????13m
etcd?????????????????????27m

同時我們可以使用下面的命令查看一個指定 Operator package 使用的默認 channel：

$?kubectl?get?packagemanifests?etcd?-o?jsonpath='{.status.defaultChannel}'

alpha

通過上面獲取到的 Operator 軟件包名稱，channel 和運行 catalog 的命名空間等信息，我們可以通過創(chuàng)建上文介紹過的 OLM 訂閱對象（Subscription）啟動從指定 catalog 源中安裝或升級 Operator，一個 Subscription 示例如下所示：

apiVersion:?operators.coreos.com/v1alpha1
kind:?Subscription
metadata:
??name:?etcd-subscription
??namespace:?default?
spec:
??channel:?alpha
??name:?etcd
??source:?example-manifests
??sourceNamespace:?default

另外通過支持 gRPC 協(xié)議的命令行通訊工具gRPCurl，我們可以在本地向指定的 catalog 服務端發(fā)送請求，從而方便地進行軟件包目錄信息的查看。

本章我們介紹了 Operator Lifecycle Manager 的基本架構和使用方法，通過本章的學習，我們對 OLM 的工作原理、架構設計都有了較為清晰的認識。同時通過一些示例代碼，加深了讀者對 OLM 應用實踐的認識，為工作實戰(zhàn)中通過 Operator Framework 實現產品能力擴展提供了指導基礎。