如何管理越來越多的 operator？OLM 給你答案

作者 | 匡大虎、闞俊寶

導讀：OLM(Operator Lifecycle Manager) 作為 Operator Framework 的一部分，可以幫助用戶進行 Operator 的自動安裝，升級及其生命周期的管理。同時 OLM 自身也是以 Operator 的形式進行安裝部署，可以說它的工作方式是以 Operators 來管理 Operators，而它面向 Operator 提供了聲明式 (declarative) 的自動化管理能力也完全符合 Kubernetes 交互的設計理念。本文我們將來了解一下 OLM 的基本架構和安裝使用。

OLM 組件模型定義

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

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

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

• 打包能力：提供一種標准模式用於 operator 以及依賴組件的分發，安裝和升級；

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

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

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

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

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

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

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

• 支持標簽和資源發現。

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

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

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

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

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

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

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

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

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

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

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

OLM 結構介紹

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

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

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

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

• 監聽用戶創建的未解析 InstallPlans:

  • 尋找滿足依賴條件的 CSV 模型並將其加入到已解析資源中；
  • 將所有被目標 Operator 管理或依賴的 CRD 模型加入到解析資源中；
  • 尋找並管理每種依賴 CRD 對應 CSV 模型；

• 監聽所有被解析的 InstallPlan，在用戶審批或自動審批完成后創建所有對應的依賴資源；

• 監聽 CataologSources 和 Subscriptions 模型並基於其變更創建對應的 InstallPlans。

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

OLM 的安裝

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

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

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

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 代碼倉庫到本地后，用戶可以執行 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

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

• 創建名稱如 my-values.yaml 的配置模板，用戶可以參考上述模板配置所需參數；
• 基於上述配置好的 my-values.yaml 模板，使用 package_release.sh 生成指定部署模板；

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

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

最后，用戶可以通過環境變量 GLOBAL_CATALOG_NAMESPACE 定義 catalog operator 監聽全局 catalogs 的指定 namespace，默認情況下安裝過程會創建 olm 命名空間並部署 catalog operator。

依賴解析和升級管理

如同 apt/dkpg 和 yum/rpm 對於系統組件包的管理一樣，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 的版本終態為:

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

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

下面我們來看一下兩個會引發升級失敗的示例以及 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，即使系統可以找到適用的升級版本，也無法完成對應 Operator 的版本升級。

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

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

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

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

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

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

在了解了 OLM 的依賴解析和升級管理的基本原理后，我們來看下 OLM 升級相關的工作流程。首先從上文中我們已經有所了解，ClusterServiceVersion（CSV），CatalogSource 和 Subscription 是 OLM 框架中和升級緊密相關的三種擴展模型。在 OLM 的生態系統中，我們通過 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（有向無環圖），在這個過程中 channels 可以被認為是更新 DAG 的入口。在升級過程中，如果 OLM 發現在可升級的最新版本和當前版本之間還有未安裝的中間版本，系統會自動構建出一條升級路徑並保證路徑上中間版本的安裝。比如當前我們有一個正在運行的 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'

operator-registry

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

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

• initializer：負責接收用戶上傳的以目錄為結構的 operator manifests，同時將數據導入到數據庫中；
• registry-server：包含存取 operator manifests 相關的 sqlite 數據庫服務，同時對外暴露 gRPC 協議接口的服務；
• 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 的集成，這里我們需要創建一個 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 的命名空間等信息，我們可以通過創建上文介紹過的 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 協議的命令行通訊工具 gRPCurl，我們可以在本地向指定的 catalog 服務端發送請求，從而方便地進行軟件包目錄信息的查看。

小結

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

作者簡介

匡大虎 阿里雲高級技術專家，從事 Kubernetes 和容器相關產品的開發。尤其關注雲原生安全，是阿里雲容器服務雲原生安全核心成員。

闞俊寶 阿里雲容器服務技術專家，專注 Kubernetes、Docker、雲存儲領域，是阿里雲 CSI 項目的核心維護者。

贈書福利

9 月 11 日 17：00 前在阿里巴巴公眾號留言區歡迎大家一起探討交流，精選留言點贊前 3 名各送出《雲原生應用管理：原理與實踐》一書！

“阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”