简介： OLM(Operator Lifecycle Manager) 作为 Operator Framework 的一部分，能够帮忙用户进行 Operator 的主动装置，降级及其生命周期的治理。同时 OLM 本身也是以 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

1. 如果你的 CSV 中须要应用新版本的 CRD，咱们须要保障 CSV 中的 owned 字段所援用的 CRD 版本是新的，如下所示：

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

1. 推送更新后的 CRD 和 CSV 到指定的仓库目录中。

当咱们须要弃用或是删除一个 CRD 版本时，OLM 不容许立刻删除一个正在应用中的 CRD 版本，而是须要首先通过将 CRD 中的 serverd 字段置为 false 来弃用该版本，而后这个不被应用的版本才会在接下来的 CRD 降级过程中被删除。官网举荐的删除或弃用一个 CRD 指定版本的步骤如下：

1. 将过期的弃用 CRD 版本对应的 serverd 字段标记为 false，示意不再应用该版本同时会在下次降级时删除此版本，如：

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

1. 如果以后行将过期的 CRD 版本中 storage 字段为 true，须要将其置为 false 同时将新版本的 storage 对应字段置为 true，比方：

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

1. 基于上述批改更新 CRD 模型；
2. 在随后的降级过程中，不在服务的过期版本将会从 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 我的项目的外围维护者。

原文链接
本文为阿里云原创内容，未经容许不得转载。