2.4. Operator Lifecycle Manager (OLM)

Operator Lifecycle Manager（OLM）可帮助用户安装、更新和管理所有 Kubernetes 原生应用程序（Operator）以及在 OpenShift Container Platform 集群中运行的关联服务的生命周期。它是 Operator Framework 的一部分，后者是一个开源工具包，用于以有效、自动化且可扩展的方式管理 Operator。

图 2.2. Operator Lifecycle Manager 工作流

OLM 默认在 OpenShift Container Platform 4.12 中运行，辅助集群管理员对集群上运行的 Operator 进行安装、升级和授予访问权。OpenShift Container Platform Web 控制台提供一些管理界面，供集群管理员安装 Operator，以及为特定项目授权以便使用集群上的可用 Operator 目录。

开发人员通过自助服务体验，无需成为相关问题的专家也可自由置备和配置数据库、监控和大数据服务的实例，因为 Operator 已将相关知识融入其中。

以下自定义资源定义 (CRD) 由 Operator Lifecycle Manager (OLM) 定义和管理：

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  generation: 1
  name: example-catalog 1
  namespace: openshift-marketplace 2
  annotations:
    olm.catalogImageTemplate: 3
      "quay.io/example-org/example-catalog:v{kube_major_version}.{kube_minor_version}.{kube_patch_version}"
spec:
  displayName: Example Catalog 4
  image: quay.io/example-org/example-catalog:v1 5
  priority: -400 6
  publisher: Example Org
  sourceType: grpc 7
  grpcPodConfig:
    securityContextConfig: <security_mode> 8
    nodeSelector: 9
      custom_label: <label>
    priorityClassName: system-cluster-critical 10
    tolerations: 11
      - key: "key1"
        operator: "Equal"
        value: "value1"
        effect: "NoSchedule"
  updateStrategy:
    registryPoll: 12
      interval: 30m0s
status:
  connectionState:
    address: example-catalog.openshift-marketplace.svc:50051
    lastConnect: 2021-08-26T18:14:31Z
    lastObservedState: READY 13
  latestImageRegistryPoll: 2021-08-26T18:46:25Z 14
  registryService: 15
    createdAt: 2021-08-26T16:16:37Z
    port: 50051
    protocol: grpc
    serviceName: example-catalog
    serviceNamespace: openshift-marketplace

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: example-operator
  namespace: example-namespace
spec:
  channel: stable
  name: example-operator
  source: example-catalog
  sourceNamespace: openshift-marketplace

registry.redhat.io/redhat/redhat-operator-index:v4.11

registry.redhat.io/redhat/redhat-operator-index:v4.12

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  generation: 1
  name: example-catalog
  namespace: openshift-marketplace
  annotations:
    olm.catalogImageTemplate:
      "quay.io/example-org/example-catalog:v{kube_major_version}.{kube_minor_version}"
spec:
  displayName: Example Catalog
  image: quay.io/example-org/example-catalog:v1.25
  priority: -400
  publisher: Example Org

quay.io/example-org/example-catalog:v1.25

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: example-operator
  namespace: example-namespace
spec:
  channel: stable
  name: example-operator
  source: example-catalog
  sourceNamespace: openshift-marketplace

apiVersion: operators.coreos.com/v1alpha1
kind: InstallPlan
metadata:
  name: install-abcde
  namespace: operators
spec:
  approval: Automatic
  approved: true
  clusterServiceVersionNames:
    - my-operator.v1.0.1
  generation: 1
status:
  ...
  catalogSources: []
  conditions:
    - lastTransitionTime: '2021-01-01T20:17:27Z'
      lastUpdateTime: '2021-01-01T20:17:27Z'
      status: 'True'
      type: Installed
  phase: Complete
  plan:
    - resolving: my-operator.v1.0.1
      resource:
        group: operators.coreos.com
        kind: ClusterServiceVersion
        manifest: >-
        ...
        name: my-operator.v1.0.1
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1alpha1
      status: Created
    - resolving: my-operator.v1.0.1
      resource:
        group: apiextensions.k8s.io
        kind: CustomResourceDefinition
        manifest: >-
        ...
        name: webservers.web.servers.org
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1beta1
      status: Created
    - resolving: my-operator.v1.0.1
      resource:
        group: ''
        kind: ServiceAccount
        manifest: >-
        ...
        name: my-operator
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1
      status: Created
    - resolving: my-operator.v1.0.1
      resource:
        group: rbac.authorization.k8s.io
        kind: Role
        manifest: >-
        ...
        name: my-operator.v1.0.1-my-operator-6d7cbc6f57
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1
      status: Created
    - resolving: my-operator.v1.0.1
      resource:
        group: rbac.authorization.k8s.io
        kind: RoleBinding
        manifest: >-
        ...
        name: my-operator.v1.0.1-my-operator-6d7cbc6f57
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1
      status: Created
      ...

Operator Lifecycle Manager (OLM) 由两个 Operator 组成，分别为：OLM Operator 和 Catalog Operator。

每个 Operator 均负责管理 CRD，而 CRD 是 OLM 的框架基础：

每个 Operator 还负责创建以下资源：

集群中存在 CSV 中指定需要的资源后，OLM Operator 将负责部署由 CSV 资源定义的应用程序。

OLM Operator 不负责创建所需资源；用户可选择使用 CLI 手动创建这些资源，也可选择使用 Catalog Operator 来创建这些资源。这种关注点分离的机制可以使得用户逐渐增加他们选择用于其应用程序的 OLM 框架量。

OLM Operator 使用以下工作流：

Catalog Operator 负责解析和安装集群服务版本（CSV）以及它们指定的所需资源。另外还负责监视频道中的目录源中是否有软件包更新，并将其升级（可选择自动）至最新可用版本。

要跟踪频道中的软件包，您可以创建一个 Subscription 对象来配置所需的软件包、频道和 CatalogSource 对象，以便拉取更新。在找到更新后，便会代表用户将一个适当的 InstallPlan 对象写入命名空间。

Catalog Operator 使用以下工作流：

Catalog Registry 存储 CSV 和 CRD 以便在集群中创建，并存储有关软件包和频道的元数据。

package manifest 是 Catalog Registry 中的一个条目，用于将软件包标识与 CSV 集相关联。在软件包中，频道指向特定 CSV。因为 CSV 明确引用了所替换的 CSV，软件包清单向 Catalog Operator 提供了将 CSV 更新至频道中最新版本所需的信息，逐步安装和替换每个中间版本。

在 Operator Lifecycle Manager (OLM) 生态系统中，以下资源用于解决 Operator 的安装和升级问题：

CSV 中定义的 Operator 元数据可保存在一个称为目录源的集合中。目录源使用 Operator Registry API，OLM 又使用目录源来查询是否有可用的 Operator 及已安装 Operator 是否有升级版本。

图 2.3. 目录源概述

在目录源中，Operator 被整合为更新软件包和更新流，我们称为频道，这应是 OpenShift Container Platform 或其他软件（如 Web 浏览器）在持续发行周期中的常见更新模式。

图 2.4. 目录源中的软件包和频道

用户在订阅中的特定目录源中指示特定软件包和频道，如 etcd 包及其 alpha 频道。如果订阅了命名空间中尚未安装的软件包，则会安装该软件包的最新 Operator。

每个 CSV 均有一个 replaces 参数，指明所替换的是哪个 Operator。这样便构建了一个可通过 OLM 查询的 CSV 图，且不同频道之间可共享更新。可将频道视为更新图表的入口点：

图 2.5. OLM 的可用频道更新图表

packageName: example
channels:
- name: alpha
  currentCSV: example.v0.1.2
- name: beta
  currentCSV: example.v0.1.3
defaultChannel: alpha

为了让 OLM 成功查询更新、给定一个目录源、软件包、频道和 CSV，目录必须能够明确无误地返回替换输入 CSV 的单个 CSV。

2.4.3.1.2. 跳过升级

OLM 中升级的基本路径是：

• 通过对 Operator 的一个或多个更新来更新目录源。
• OLM 会遍历 Operator 的所有版本，直到到达目录源包含的最新版本。

但有时这不是一种安全操作。某些情况下，已发布但尚未就绪的 Operator 版本不可安装至集群中，如版本中存在严重漏洞。

这种情况下，OLM 必须考虑两个集群状态，并提供支持这两个状态的更新图：

• 集群发现并安装了“不良”中间 Operator。
• “不良”中间 Operator 尚未安装至集群中。

通过发送新目录并添加跳过的发行版本，可保证无论集群状态如何以及是否发现了不良更新，OLM 总能获得单个唯一更新。

带有跳过发行版本的 CSV 示例

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

考虑以下 Old CatalogSource 和 New CatalogSource 示例。

图 2.6. 跳过更新

该图表明：

• Old CatalogSource 中的任何 Operator 在 New CatalogSource 中均有单一替换项。
• New CatalogSource 中的任何 Operator 在 New CatalogSource 中均有单一替换项。
• 如果未曾安装不良更新，将来也绝不会安装。

olm.skipRange: <semver_range>

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

2.4.3.1.4. Z-stream 支持

对于相同从版本，z-stream 或补丁版本必须取代所有先前 z-stream 版本。OLM 不考虑主版本、次版本或补丁版本，只需要在目录中构建正确的图表。

换句话说，OLM 必须能够像在 Old CatalogSource 中一样获取一个图表，像在 New CatalogSource 中一样生成一个图表：

图 2.7. 替换多个 Operator

该图表明：

• Old CatalogSource 中的任何 Operator 在 New CatalogSource 中均有单一替换项。
• New CatalogSource 中的任何 Operator 在 New CatalogSource 中均有单一替换项。
• Old CatalogSource 中的所有 z-stream 版本均会更新至 New CatalogSource 中最新 z-stream 版本。
• 不可用版本可被视为“虚拟”图表节点；它们的内容无需存在，注册表只需像图表看上去这样响应即可。

Operator Lifecycle Manager(OLM)管理运行 Operator 的依赖项解析和升级生命周期。在很多方面，OLM 的问题与其他系统或语言软件包管理器类似，如 yum 和 rpm。

但其中有一个限制是相似系统一般不存在而 OLM 存在的，那就是：因为 Operator 始终在运行，所以 OLM 会努力确保您所接触的 Operator 组始终相互兼容。

因此，OLM 不得创建以下情况：

这可以通过两种类型的数据：

OLM 将这些属性和约束转换为布尔值公式系统，并将其传递给 SAT solver，SAT solver 是一个处理布尔值的程序，用于确定应该安装哪些 Operator。

目录中的所有 Operator 均具有以下属性：

Operator 作者也可以在 Operator 捆绑包的 metadata/ 目录中包括 properties.yaml 文件来直接声明其他属性。

properties:
- type: olm.kubeversion
  value:
    version: "1.16.0"

properties:
  - property:
      type: color
      value: red
  - property:
      type: shape
      value: square
  - property:
      type: olm.gvk
      value:
        group: olm.coreos.io
        version: v1alpha1
        kind: myresource

Operator 的依赖项列在捆绑包的 metadata/ 目录中的 dependencies.yaml 文件中。此文件是可选的，目前仅用于指明 Operator-version 依赖项。

依赖项列表中，每个项目包含一个 type 字段，用于指定这一依赖项的类型。支持以下 Operator 依赖项：

在以下示例中，为 Prometheus Operator 和 etcd CRD 指定依赖项：

dependencies:
  - type: olm.package
    value:
      packageName: prometheus
      version: ">0.27.0"
  - type: olm.gvk
    value:
      group: etcd.database.coreos.com
      kind: EtcdCluster
      version: v1beta2

olm.constraint 属性声明特定类型的依赖项约束，区分非约束和约束属性。其 value 字段是一个包含 failureMessage 字段的对象，其中包含约束消息的字符串表。如果约束在运行时不满意，则这一消息被作为信息性提供给用户使用。

以下键表示可用的约束类型：

type: olm.constraint
value:
  failureMessage: 'require to have "certified"'
  cel:
    rule: 'properties.exists(p, p.type == "certified")'

type: olm.constraint
value:
  failureMessage: 'require to have "certified" and "stable" properties'
  cel:
    rule: 'properties.exists(p, p.type == "certified") && properties.exists(p, p.type == "stable")'

schema: olm.bundle
name: red.v1.0.0
properties:
- type: olm.constraint
  value:
    failureMessage: All are required for Red because...
    all:
      constraints:
      - failureMessage: Package blue is needed for...
        package:
          name: blue
          versionRange: '>=1.0.0'
      - failureMessage: GVK Green/v1 is needed for...
        gvk:
          group: greens.example.com
          version: v1
          kind: Green

schema: olm.bundle
name: red.v1.0.0
properties:
- type: olm.constraint
  value:
    failureMessage: Any are required for Red because...
    any:
      constraints:
      - gvk:
          group: blues.example.com
          version: v1beta1
          kind: Blue
      - gvk:
          group: blues.example.com
          version: v1beta2
          kind: Blue
      - gvk:
          group: blues.example.com
          version: v1
          kind: Blue

schema: olm.bundle
name: red.v1.0.0
properties:
- type: olm.constraint
  value:
  all:
    constraints:
    - failureMessage: Package blue is needed for...
      package:
        name: blue
        versionRange: '>=1.0.0'
    - failureMessage: Cannot be required for Red because...
      not:
        constraints:
        - gvk:
            group: greens.example.com
            version: v1alpha1
            kind: greens

schema: olm.bundle
name: red.v1.0.0
properties:
- type: olm.constraint
  value:
    failureMessage: Required for Red because...
    any:
      constraints:
      - all:
          constraints:
          - package:
              name: blue
              versionRange: '>=1.0.0'
          - gvk:
              group: blues.example.com
              version: v1
              kind: Blue
      - all:
          constraints:
          - package:
              name: blue
              versionRange: '<1.0.0'
          - gvk:
              group: blues.example.com
              version: v1beta1
              kind: Blue

有很多选项同样可以满足 Operator 的依赖性。Operator Lifecycle Manager（OLM）中的依赖项解析器决定哪个选项最适合所请求 Operator 的要求。作为 Operator 作者或用户，了解这些选择非常重要，以便明确依赖项解析。

apiVersion: "operators.coreos.com/v1alpha1"
kind: "CatalogSource"
metadata:
  name: "my-operators"
  namespace: "operators"
spec:
  sourceType: grpc
  grpcPodConfig:
    securityContextConfig: <security_mode> 1
  image: example.com/my/operator-index:v1
  displayName: "My Operators"
  priority: 100

如果自定义资源定义（CRD）属于单一集群服务版本（CSV），OLM 会立即对其升级。如果某个 CRD 被多个 CSV 拥有，则当该 CRD 满足以下所有向后兼容条件时才会升级：

在指定依赖项时应该考虑的最佳实践。

当指定依赖项时，需要考虑一些注意事项。

在以下示例中，provider（供应商） 是指"拥有" CRD 或 API 服务的 Operator。

示例：弃用从属 API

A 和 B 是 API（CRD）：

结果：

这是 OLM 通过升级策略阻止的一个案例。

示例：版本死锁

A 和 B 均为 API：

如果 OLM 试图在更新 A 的同时不更新 B，或更新 B 的同时不更新 A，则无法升级到新版 Operator，即使可找到新的兼容集也无法更新。

这是 OLM 通过升级策略阻止的另一案例。

由 OperatorGroup 资源定义的 Operator 组，为 OLM 安装的 Operator 提供多租户配置。Operator 组选择目标命名空间，在其中为其成员 Operator 生成所需的 RBAC 访问权限。

这一组目标命名空间通过存储在 CSV 的 olm.targetNamespaces 注解中的以逗号分隔的字符串来提供。该注解应用于成员 Operator 的 CSV 实例，并注入它们的部署中。

满足以下任一条件，Operator 即可被视为 Operator 组的 member：

CSV 中的安装模式由 InstallModeType 字段和 Supported 的布尔值字段组成。CSV 的 spec 可以包含一组由四个不同 InstallModeTypes 组成的安装模式：

您可以使用 spec.targetNamespaces 参数为 Operator 组显式命名目标命名空间：

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: my-group
  namespace: my-namespace
spec:
  targetNamespaces:
  - my-namespace

您还可以使用带有 spec.selector 参数的标签选择器指定命名空间：

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: my-group
  namespace: my-namespace
spec:
  selector:
    cool.io/prod: "true"

如果 spec.targetNamespaces 和 spec.selector 均已定义，则会忽略 spec.selector。另外，您可以省略 spec.selector 和 spec.targetNamespaces 来指定一个 全局 Operator 组，该组选择所有命名空间：

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: my-group
  namespace: my-namespace

Opeator 组的 status.namespaces 参数中会显示所选命名空间的解析集合。全局 OperatorGroup 的 status.namespace 包含空字符串 ("")，而该字符串会向正在使用的 Operator 发出信号，要求其监视所有命名空间。

Operator 组的成员 CSV 具有以下注解：

group/version/kind (GVK) 是 Kubernetes API 的唯一标识符。olm.providedAPIs 注解中会显示有关 Operator 组提供哪些 GVK 的信息。该注解值为一个字符串，由用逗号分隔的 <kind>.<version>.<group> 组成。其中包括由 Operator 组的所有活跃成员 CSV 提供的 CRD 和 APIService 的 GVK。

查看以下 OperatorGroup 示例，该 OperatorGroup 带有提供 PackageManifest 资源的单个活跃成员 CSV：

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  annotations:
    olm.providedAPIs: PackageManifest.v1alpha1.packages.apps.redhat.com
  name: olm-operators
  namespace: local
  ...
spec:
  selector: {}
  serviceAccount:
    metadata:
      creationTimestamp: null
  targetNamespaces:
  - local
status:
  lastUpdated: 2019-02-19T16:18:28Z
  namespaces:
  - local

创建 Operator 组时，会生成三个集群角色。每个 ClusterRole 均包含一个聚会规则，后者带有一个选择器以匹配标签，如下所示：

当 CSV 成为 Operator 组的活跃成员时，只要该 CSV 正在使用 AllNamespaces 安装模式来监视所有命名空间，且没有因 InterOperatorGroupOwnerConflict 原因处于故障状态，便会生成以下 RBAC 资源：

OLM 会在 Operator 组的每个目标命名空间中创建 Operator 组的所有活跃成员 CSV 的副本。复制 CSV 的目的在于告诉目标命名空间的用户，特定 Operator 已配置为监视在此创建的资源。

复制的 CSV 会复制状态原因，并会更新以匹配其源 CSV 的状态。在集群上创建复制的 CSV 之前，会从这些 CSV 中分离 olm.targetNamespaces 注解。省略目标命名空间选择可避免租户之间存在目标命名空间重复的现象。

当所复制的 CSV 的源 CSV 不存在或其源 CSV 所属的 Operator 组不再指向复制 CSV 的命名空间时，会删除复制的 CSV。

如果 Operator 组的 spec.staticProvidedAPIs 字段被设置为 true，则 Operator 组为静态。因此，OLM 不会修改 Operator 组的 olm.providedAPIs 注解，这意味着可以提前设置它。如果一组命名空间没有活跃的成员 CSV 来为资源提供 API，而用户想使用 Operator 组来防止命名空间集中发生资源争用，则这一操作十分有用。

以下是一个 Operator 组示例，它使用 something.cool.io/cluster-monitoring: "true" 注解来保护所有命名空间中的 Prometheus 资源：

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: cluster-monitoring
  namespace: cluster-monitoring
  annotations:
    olm.providedAPIs: Alertmanager.v1.monitoring.coreos.com,Prometheus.v1.monitoring.coreos.com,PrometheusRule.v1.monitoring.coreos.com,ServiceMonitor.v1.monitoring.coreos.com
spec:
  staticProvidedAPIs: true
  selector:
    matchLabels:
      something.cool.io/cluster-monitoring: "true"

如果两个 Operator 组的目标命名空间集的交集不是空集，且根据 olm.providedAPIs 注解的定义，所提供的 API 集的交集也不是空集，则称这两个 OperatorGroup 的提供的 API 有交集。

一个潜在问题是，提供的 API 有交集的 Operator 组可能在命名空间交集中竞争相同资源。

交集规则

每次活跃成员 CSV 同步时，OLM 均会查询集群，以获取 CSV 组和其他所有 CSV 组之间提供的 API 交集。然后 OLM 会检查该交集是否为空集：

每次 Operator 组同步时都会执行以下操作：

OpenShift Container Platform 支持在同一集群中安装不同版本的 Operator。Operator Lifecycle Manager (OLM) 会在不同的命名空间中多次安装 Operator。其中一个限制是 Operator 的 API 版本必须相同。

Operator 是控制平面的扩展，因为它们使用了 CustomResourceDefinition 对象 (CRD)，它们是 Kubernetes 中的全局资源。一个 Operator 的不同主版本通常具有不兼容的 CRD。这使得它们不兼容，可以在集群中的不同命名空间中安装。

所有租户或命名空间共享同一集群的 control plane。因此，多租户集群中的租户也共享全局 CRD，这限制同一集群中可以并行使用同一 Operator 实例的不同 Operator 实例。

支持的场景包括：

不支持所有其他场景，因为如果不同 Operator 版本中的多个竞争或重叠 CRD 在同一集群中协调，则无法保证集群数据的完整性。

成员资格

Operator Lifecycle Manager (OLM) 处理在同一命名空间中安装的 OLM 管理的 Operator，这意味着其 Subscription 资源与相关 Operator 位于同一个命名空间中。即使它们实际不相关，OLM 会在更新其中任何一个时考虑其状态，如它们的版本和更新策略。

这个默认行为清单可以通过两种方式：

这些场景可能会导致以下问题：

这些问题通常是在使用 OpenShift Container Platform Web 控制台安装 Operator 时，默认行为会将支持 All namespaces 安装模式的 Operator 安装到默认的 openshift-operators 全局命名空间中。

作为集群管理员，您可以使用以下工作流手动绕过此默认行为：

如果 Operator 具有依赖项，依赖项会在预先创建的命名空间中自动安装。因此，它对依赖项 Operator 有效，使其具有相同的更新策略和共享安装计划。具体步骤，请参阅“在自定义命名空间中安装全局 Operator"。

作为管理 Operator 生命周期的角色的一部分，Operator Lifecycle Manager（OLM）从定义 Operator 的 Kubernetes 资源状态中推断 Operator 状态。虽然此方法提供了一定程度的保证来确定 Operator 处于给定状态，但在有些情况下，Operator 可能需要直接向 OLM 提供信息，而这些信息不能被推断出来。这些信息可以被 OLM 使用来更好地管理 Operator 的生命周期。

OLM 提供了一个名为 OperatorCondition 的自定义资源定义（CRD），它允许 Operator 与 OLM 相互通信条件信息。当在一个 OperatorCondition 资源的 Spec.Conditions 数组中存在时，则代表存在一组会影响 OLM 管理 Operator 的支持条件。

Operator Lifecycle Manager（OLM）支持以下 Operator 条件。

apiVersion: operators.coreos.com/v1
kind: OperatorCondition
metadata:
  name: my-operator
  namespace: operators
spec:
  conditions:
  - type: Upgradeable 1
    status: "False" 2
    reason: "migration"
    message: "The Operator is performing a migration."
    lastTransitionTime: "2020-08-24T23:15:55Z"

Operator Lifecycle Manager（OLM）会公开某些 OLM 特定资源，供基于 Prometheus 的 OpenShift Container Platform 集群监控堆栈使用。