Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

2.4. Operator Lifecycle Manager (OLM)

2.4.1. Operator Lifecycle Manager 概念和资源
复制链接

本指南概述了 OpenShift Container Platform 中 Operator Lifecycle Manager (OLM) 背后的概念。

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

图 2.2. OLM (Classic) 工作流

OLM 工作流

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

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

2.4.1.2. OLM 资源
复制链接

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

Expand
表 2.2. 由 OLM 和 Catalog Operator 管理的 CRD
资源短名称描述

ClusterServiceVersion (CSV)

csv

应用程序元数据。例如：名称、版本、图标、所需资源。

CatalogSource

catsrc

定义应用程序的 CSV、CRD 和软件包存储库。

Subscription

sub

通过跟踪软件包中的频道来保持 CSV 最新。

InstallPlan

ip

为自动安装或升级 CSV 而需创建的资源的计算列表。

OperatorGroup

og

将部署在同一命名空间中的所有 Operator 配置为 OperatorGroup 对象，以便在一系列命名空间或集群范围内监视其自定义资源 ( CR)。

OperatorConditions

-

在 OLM 和它管理的 Operator 之间创建通信频道。操作员可以写入 Status.Conditions 数组，以向 OLM 通报复杂状态。

2.4.1.2.1. 集群服务版本
复制链接

集群服务版本 (CSV) 代表 OpenShift Container Platform 集群中运行的 Operator 的特定版本。它是一个利用 Operator 元数据创建的 YAML 清单，可辅助 Operator Lifecycle Manager (OLM) 在集群中运行 Operator。

OLM 需要与 Operator 相关的元数据，以确保它可以在集群中安全运行，并在发布新版 Operator 时提供有关如何应用更新的信息。这和传统的操作系统的打包软件相似；可将 OLM 的打包步骤认为是制作 rpm、deb 或 apk 捆绑包的阶段。

CSV 中包含 Operator 容器镜像附带的元数据，用于在用户界面填充名称、版本、描述、标签、存储库链接和徽标等信息。

此外，CSV 还是运行 Operator 所需的技术信息来源，例如其管理或依赖的自定义资源 (CR)、RBAC 规则、集群要求和安装策略。此信息告诉 OLM 如何创建所需资源并将 Operator 设置为部署。

2.4.1.2.2. 目录源
复制链接

catalog source 代表元数据存储，通常通过引用存储在容器 registry 中的 index image。Operator Lifecycle Manager (OLM) 查询目录源来发现和安装 Operator 及其依赖项。OpenShift Container Platform Web 控制台中的软件目录也会显示由目录源提供的 Operator。

提示

集群管理员可以使用 web 控制台中的 Administration Cluster Settings Configuration OperatorHub 页面查看集群中已启用的目录源提供的 Operator 的完整列表。

CatalogSource 的 spec 指明了如何构造 pod，以及如何与服务于 Operator Registry gRPC API 的服务进行通信。

CatalogSource 对象示例

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

1
CatalogSource 对象的名称。此值也用作在请求的命名空间中创建相关 pod 的名称的一部分。
2
要创建目录的命名空间。要使目录在所有命名空间中都可用，请将此值设置为 openshift-marketplace。默认红帽提供的目录源也使用 openshift-marketplace 命名空间。否则，将值设置为特定命名空间，使 Operator 仅在该命名空间中可用。
3
可选：为避免集群升级可能会使 Operator 安装处于不受支持的状态或没有持续更新路径，您可以启用自动更改 Operator 目录的索引镜像版本作为集群升级的一部分。

将 olm.catalogImageTemplate 注解设置为索引镜像名称，并使用一个或多个 Kubernetes 集群版本变量，如为镜像标签构建模板时所示。该注解会在运行时覆盖 spec.image 字段。如需了解更多详细信息，请参阅"用于自定义目录源的镜像模板"。

4
在 Web 控制台和 CLI 中显示目录的名称。
5
目录的索引镜像。在使用 olm.catalogImageTemplate 注解时，也可以省略，该注解会在运行时设置 pull spec。
6
目录源的权重。OLM 在依赖项解析过程中使用权重进行优先级排序。权重越高，表示目录优先于轻量级目录。
7
源类型包括以下内容：
  • 带有镜像引用的 grpc：OLM 拉取镜像并运行 pod，为兼容的 API 服务。
  • 带有地址字段的 grpc：OLM 会尝试联系给定地址的 gRPC API。在大多数情况下不应该使用这种类型。
  • configmap：OLM 解析配置映射数据，并运行一个可以为其提供 gRPC API 的 pod。
8
指定 legacy 或 restricted 的值。如果没有设置该字段，则默认值为 legacy。在以后的 OpenShift Container Platform 发行版本中，计划默认值为 restricted。
注意

如果您的目录无法使用 restricted 权限运行，建议您手动将此字段设置为 legacy。

9
可选： 对于 grpc 类型目录源，请覆盖在 spec.image 中提供内容的 pod 的默认节点选择器（如果定义）。
10
可选： 对于 grpc 类型目录源，请覆盖在 spec.image 中提供内容的 pod 的默认优先级类名称（如果定义）。Kubernetes 默认提供 system-cluster-critical 和 system-node-critical 优先级类。将字段设置为空 ("") 可为 pod 分配默认优先级。可以手动定义其他优先级类。
11
可选： 对于 grpc 类型目录源，请覆盖 spec.image 中提供内容的 pod 的默认容限（如果定义）。
12
在指定的时间段内自动检查新版本以保持最新。
13
目录连接的最后观察到状态。例如：
  • READY ：成功建立连接。
  • CONNECTING ：连接正在尝试建立。
  • TRANSIENT_FAILURE ：尝试建立连接（如超时）时发生了临时问题。该状态最终将切回到 CONNECTING，然后重试。

如需了解更多详细信息，请参阅 gRPC 文档中的连接状态。

14
存储目录镜像的容器注册表最近轮询的时间，以确保镜像为最新版本。
15
目录的 Operator Registry 服务的状态信息。

在订阅中引用 CatalogSource 对象的名称会指示 OLM 搜索查找请求的 Operator 的位置：

引用目录源的 Subscription 对象示例

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

2.4.1.2.2.1. 自定义目录源的镜像模板
复制链接

与底层集群的 Operator 兼容性可以通过目录源以各种方式表示。其中一种用于红帽默认提供的目录源的方法是识别为特定平台发行版本（如 OpenShift Container Platform 4.20）特别创建的索引镜像的镜像标签。

在集群升级过程中，默认红帽提供的目录源的索引镜像标签由 Cluster Version Operator (CVO) 自动更新，以便 Operator Lifecycle Manager (OLM) 拉取目录的更新版本。例如，在从 OpenShift Container Platform 4.19 升级到 4.20 的过程中，redhat-operators 目录的 CatalogSource 对象中的 spec.image 字段被更新： 

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

改为： 

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

但是，CVO 不会自动更新自定义目录的镜像标签。为确保用户在集群升级后仍然安装兼容并受支持的 Operator，还应更新自定义目录以引用更新的索引镜像。

从 OpenShift Container Platform 4.9 开始，集群管理员可以在自定义目录的 CatalogSource 对象中添加 olm.catalogImageTemplate 注解到包含模板的镜像引用。模板中支持使用以下 Kubernetes 版本变量：

  • kube_major_version
  • kube_minor_version
  • kube_patch_version
注意

您必须指定 Kubernetes 集群版本，而不是 OpenShift Container Platform 集群版本，因为后者目前不适用于模板。

如果您已创建并推送了带有指定更新 Kubernetes 版本标签的索引镜像，设置此注解可使自定义目录中的索引镜像版本在集群升级后自动更改。注解值用于设置或更新 CatalogSource 对象的 spec.image 字段中的镜像引用。这有助于避免集群升级，从而避免在不受支持的状态或没有持续更新路径的情况下安装 Operator。

重要

您必须确保集群可在集群升级时访问带有更新标签的索引镜像（无论存储在哪一 registry 中）。

例 2.9. 带有镜像模板的目录源示例

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.33
  priority: -400
  publisher: Example Org
注意

如果设置了 spec.image 字段和 olm.catalogImageTemplate 注解，则 spec.image 字段会被注解中的解析值覆盖。如果注解没有解析为可用的 pull spec，目录源会回退到设置的 spec.image 值。

如果没有设置 spec.image 字段，且注解没有解析为可用的 pull spec，OLM 会停止目录源的协调，并将其设置为人类可读的错误条件。

对于使用 Kubernetes 1.33 的 OpenShift Container Platform 4.20 集群，上例中的 olm.catalogImageTemplate 注解会解析为以下镜像引用： 

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

对于将来的 OpenShift Container Platform 版本，您可以为自定义目录创建更新的索引镜像，该镜像以更新的 Kubernetes 版本为目标，供以后的 OpenShift Container Platform 版本使用。升级前设置了 olm.catalogImageTemplate 注解，将集群升级到更新的 OpenShift Container Platform 版本也会自动更新目录的索引镜像。

2.4.1.2.2.2. 目录健康要求
复制链接

集群上的 Operator 目录可从安装解析视角进行交换； Subscription 对象可能会引用特定目录，但依赖项会根据集群中的所有目录解决。

例如，如果 Catalog A 不健康，则引用 Catalog A 的订阅可能会解析 Catalog B 中的依赖项，集群管理员可能还没有预期，因为 B 通常具有比 A 更低的目录优先级。

因此，OLM 要求所有具有给定全局命名空间的目录（例如，默认的 openshift-marketplace 命名空间或自定义全局命名空间）都健康。当目录不健康时，其共享全局命名空间中的所有 Operator 或更新操作都将因为 CatalogSourcesUnhealthy 条件而失败。如果这些操作处于不健康状态，OLM 可能会做出对集群管理员意外的解析和安装决策。

作为集群管理员，如果您观察一个不健康的目录，并希望将目录视为无效并恢复 Operator 安装，请参阅"删除自定义目录"或"禁用默认软件目录源"部分，以了解有关删除不健康目录的信息。

2.4.1.2.3. 订阅
复制链接

订阅 （由一个 Subscription 对象定义）代表安装 Operator 的意图。它是将 Operator 与目录源关联的自定义资源。

Subscription 描述了要订阅 Operator 软件包的哪个频道，以及是自动还是手动执行更新。如果设置为自动，订阅可确保 Operator Lifecycle Manager（OLM）自动管理并升级 Operator，以确保集群中始终运行最新版本。

Subscription 对象示例

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

此 Subscription 对象定义了 Operator 的名称和命名空间，以及从中查找 Operator 数据的目录。频道（如 alpha、beta 或 stable ）可帮助确定应从目录源安装哪些 Operator 流。

订阅中的频道名称可能会因 Operator 而异，但应遵守给定 Operator 中的常规约定。例如，频道名称可能会遵循 Operator 提供的应用程序的次发行版本更新流（1.2、1.3）或发行的频率（stable、fast）。

除了可从 OpenShift Container Platform Web 控制台轻松查看外，还可以通过检查相关订阅的状态来识别是否有较新版本的 Operator 可用。与 currentCSV 字段关联的值是 OLM 已知的最新版本，而 installedCSV 是集群中安装的版本。

2.4.1.2.4. 安装计划
复制链接

安装计划（由一个 InstallPlan 对象定义） 描述了 Operator Lifecycle Manager (OLM) 为安装或升级到 Operator 的特定版本而创建的一组资源。该版本由集群服务版本 (CSV) 定义。

要安装 Operator、集群管理员或被授予 Operator 安装权限的用户，必须首先创建一个 Subscription 对象。订阅代表了从目录源订阅 Operator 可用版本流的意图。然后，订阅会创建一个 InstallPlan 对象来方便为 Operator 安装资源。

然后，根据以下批准策略之一批准安装计划：

  • 如果订阅的 spec.installPlanApproval 字段被设置为 Automatic，则会自动批准安装计划。
  • 如果订阅的 spec.installPlanApproval 字段被设置为 Manual，则安装计划必须由集群管理员或具有适当权限的用户手动批准。

批准安装计划后，OLM 会创建指定的资源，并在订阅指定的命名空间中安装 Operator。

例 2.10. InstallPlan 对象示例

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
      ...
2.4.1.2.5. operator 组
复制链接

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

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

其他资源

2.4.1.2.6. Operator 条件
复制链接

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

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

注意

默认情况下，OperatorCondition 对象中没有 Spec.Conditions 数组，直到由用户添加或使用自定义 Operator 逻辑的结果为止。

Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

Legal Notice

Theme

© 2026 Red Hat返回顶部