Menu Close

1.4. Operator Lifecycle Manager (OLM)

1.4.1. Operator Lifecycle Manager 概念和资源

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

1.4.1.1. Operator Lifecycle Manager 是什么?

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

图 1.2. Operator Lifecycle Manager 工作流

OLM 工作流

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

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

1.4.1.2. OLM 资源

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

表 1.1. 由 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 通报复杂状态。

1.4.1.2.1. 集群服务版本

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

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

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

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

1.4.1.2.2. 目录源

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

提示

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

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

例 1.1. CatalogSource 对象示例

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  generation: 1
  name: example-catalog 1
  namespace: openshift-marketplace 2
spec:
  displayName: Example Catalog 3
  image: quay.io/example-org/example-catalog:v1 4
  priority: -400 5
  publisher: Example Org
  sourceType: grpc 6
  updateStrategy:
    registryPoll: 7
      interval: 30m0s
status:
  connectionState:
    address: example-catalog.openshift-marketplace.svc:50051
    lastConnect: 2021-08-26T18:14:31Z
    lastObservedState: READY 8
  latestImageRegistryPoll: 2021-08-26T18:46:25Z 9
  registryService: 10
    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
在 Web 控制台和 CLI 中显示目录的名称。
4
目录的索引镜像。
5
目录源的权重。OLM 在依赖项解析过程中使用权重进行优先级排序。权重越高,表示目录优先于轻量级目录。
6
源类型包括以下内容:
  • 带有镜像引用的 grpc:OLM 拉取镜像并运行 pod,为兼容的 API 服务。
  • 带有地址字段的 grpc:OLM 会尝试联系给定地址的 gRPC API。在大多数情况下不应该使用这种类型。
  • configmap:OLM 解析配置映射数据,并运行一个可以为其提供 gRPC API 的 pod。
7
在指定的时间段内自动检查新版本以保持最新。
8
目录连接的最后观察到状态。例如:
  • READY :成功建立连接。
  • CONNECTING :连接正在尝试建立。
  • TRANSIENT_FAILURE :尝试建立连接(如超时)时发生了临时问题。该状态最终将切回到 CONNECTING,然后重试。

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

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

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

例 1.2. 引用目录源的 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
1.4.1.2.3. Subscription

订阅 (由一个 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 数据的目录。频道(如 alphabetastable )可帮助确定应从目录源安装哪些 Operator 流。

订阅中的频道名称可能会因 Operator 而异,但应遵守给定 Operator 中的常规约定。例如,频道名称可能会遵循 Operator 提供的应用程序的次发行版本更新流(1.21.3)或发行的频率(stablefast)。

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

1.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。

例 1.3. 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
      ...
1.4.1.2.5. operator 组

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

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

其他资源

1.4.1.2.6. Operator 条件

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

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

其他资源