×

本指南概述了 OpenShift Dedicated 中 Operator 生命周期管理器 (OLM) 的核心概念。

什么是 Operator 生命周期管理器?

Operator 生命周期管理器 (OLM) 帮助用户安装、更新和管理 Kubernetes 原生应用程序 (Operators) 及其在 OpenShift Dedicated 集群中运行的相关服务的生命周期。它是 Operator Framework 的一部分,这是一个开源工具包,旨在以有效、自动化和可扩展的方式管理 Operators。

olm workflow
图 1. Operator 生命周期管理器工作流程

OLM 在 OpenShift Dedicated 中默认运行,这有助于具有 `dedicated-admin` 角色的管理员安装、升级和授予对在其集群上运行的 Operators 的访问权限。OpenShift Dedicated Web 控制台为 `dedicated-admin` 管理员提供管理屏幕,以便安装 Operators,以及授予特定项目访问集群上可用 Operators 目录的权限。

对于开发人员而言,自助服务体验允许配置和配置数据库、监控和大型数据服务的实例,而无需成为主题专家,因为 Operator 已将这些知识集成到其中。

OLM 资源

以下自定义资源定义 (CRD) 由 Operator 生命周期管理器 (OLM) 定义和管理

表 1. OLM 和目录 Operator 管理的 CRD
资源 简称 描述

ClusterServiceVersion (CSV)

csv

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

CatalogSource

catsrc

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

订阅

sub

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

InstallPlan

ip

要创建的资源的计算列表,以自动安装或升级 CSV。

OperatorGroup

og

配置部署在与 `OperatorGroup` 对象相同命名空间中的所有 Operators,以监视其自定义资源 (CR) 在命名空间列表中或集群范围内。

OperatorConditions

-

在 OLM 和其管理的 Operator 之间创建通信通道。Operators 可以写入 `Status.Conditions` 数组以向 OLM 传达复杂状态。

集群服务版本

集群服务版本 (CSV) 代表 OpenShift Dedicated 集群上运行的 Operator 的特定版本。它是根据 Operator 元数据创建的 YAML 清单,可帮助 Operator 生命周期管理器 (OLM) 在集群中运行 Operator。

OLM 需要这些关于 Operator 的元数据,以确保它可以在集群上安全地运行,并提供有关如何在发布新版本的 Operator 时应用更新的信息。这类似于为传统操作系统打包软件;可以将 OLM 的打包步骤视为创建 rpmdebapk 包的阶段。

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

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

目录源

目录源表示元数据的存储,通常通过引用存储在容器注册表中的索引镜像。Operator Lifecycle Manager (OLM) 查询目录源以发现和安装 Operator 及其依赖项。OpenShift Dedicated Web 控制台中的 OperatorHub 也显示目录源提供的 Operator。

集群管理员可以通过 Web 控制台中的**管理** → **集群设置** → **配置** → **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。默认的 Red Hat 提供的目录源也使用 openshift-marketplace 命名空间。否则,请将值设置为特定命名空间,以使 Operator 仅在该命名空间中可用。
3 可选:为避免集群升级可能导致 Operator 安装处于不受支持的状态或没有持续的更新路径,您可以启用在集群升级过程中自动更改 Operator 目录的索引镜像版本。

olm.catalogImageTemplate 注解设置为您的索引镜像名称,并在构建镜像标签的模板时使用一个或多个 Kubernetes 集群版本变量(如所示)。此注解在运行时会覆盖 spec.image 字段。有关更多详细信息,请参见“自定义目录源的镜像模板”部分。

4 Web 控制台和 CLI 中目录的显示名称。
5 目录的索引镜像。可选,在使用 olm.catalogImageTemplate 注解时可以省略,该注解在运行时设置拉取规范。
6 目录源的权重。OLM 使用权重在依赖项解析期间进行优先级排序。权重越高,表示该目录比权重较低的目录更受青睐。
7 源类型包括:
  • 带有 image 引用的 grpc:OLM 拉取镜像并运行 Pod,该 Pod 预期会提供兼容的 API。

  • 带有 address 字段的 grpc:OLM 尝试联系给定地址上的 gRPC API。在大多数情况下,不应使用此方法。

  • configmap:OLM 解析 configmap 数据并运行一个 Pod,该 Pod 可以通过它提供 gRPC API。

8 指定 legacyrestricted 的值。如果未设置该字段,则默认值为 legacy。在未来的 OpenShift Dedicated 版本中,计划将默认值设置为 restricted。如果您的目录无法使用 restricted 权限运行,建议您手动将此字段设置为 legacy
9 可选:对于 grpc 类型目录源,如果已定义,则会覆盖为 spec.image 中的内容提供服务的 Pod 的默认节点选择器。
10 可选:对于 grpc 类型目录源,如果已定义,则会覆盖为 spec.image 中的内容提供服务的 Pod 的默认优先级类名称。Kubernetes 默认提供 system-cluster-criticalsystem-node-critical 优先级类。将字段设置为为空 ("") 会为 Pod 分配默认优先级。其他优先级类可以手动定义。
11 可选:对于 grpc 类型目录源,如果已定义,则会覆盖为 spec.image 中的内容提供服务的 Pod 的默认容忍度。
12 以给定间隔自动检查新版本,以保持最新状态。
13 目录连接的最后观察到的状态。例如:
  • READY:已成功建立连接。

  • CONNECTING:正在尝试建立连接。

  • TRANSIENT_FAILURE:在尝试建立连接时发生临时问题,例如超时。该状态最终将切换回 CONNECTING 并再次尝试。

有关更多详细信息,请参阅 gRPC 文档中的连接状态

14 最后一次轮询存储目录镜像的容器注册表的时间,以确保镜像是最新的。
15 目录的 Operator Registry 服务的状态信息。

在订阅中引用 CatalogSource 对象的 name 会指示 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

自定义目录源的镜像模板

Operator 与底层集群的兼容性可以通过多种方式由目录源表达。一种方法(用于默认的 Red Hat 提供的目录源)是识别专门为特定平台版本(例如 OpenShift Dedicated)创建的索引镜像的镜像标签。

在集群升级期间,默认 Red Hat 提供的目录源的索引镜像标签会由集群版本 Operator (CVO) 自动更新,以便 Operator Lifecycle Manager (OLM) 拉取更新版本的目录。例如,在从 OpenShift Dedicated 4.16 升级到 4.17 期间,redhat-operators 目录的 CatalogSource 对象中的 spec.image 字段将从

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

更新为

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

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

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

  • kube_major_version

  • kube_minor_version

  • kube_patch_version

您必须指定 Kubernetes 集群版本,而不是 OpenShift Dedicated 集群版本,因为后者目前不可用于模板化。

如果您已创建并推送了一个包含指定更新 Kubernetes 版本的标签的索引镜像,则设置此注释可以使自定义目录中的索引镜像版本在集群升级后自动更改。注释值用于设置或更新`CatalogSource`对象的`spec.image`字段中的镜像引用。这有助于避免集群升级导致 Operator 安装处于不受支持的状态或没有持续的更新路径。

您必须确保在集群升级时,集群可以访问具有更新标签的索引镜像(无论存储在哪个注册表中)。

带有镜像模板的示例目录源
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.30
  priority: -400
  publisher: Example Org

如果同时设置了`spec.image`字段和`olm.catalogImageTemplate`注释,则`spec.image`字段将被注释解析后的值覆盖。如果注释无法解析为可用的拉取规范,则目录源将回退到已设置的`spec.image`值。

如果未设置`spec.image`字段并且注释无法解析为可用的拉取规范,则 OLM 将停止目录源的协调,并将其设置为可读的错误状态。

对于使用 Kubernetes 1.30 的 OpenShift Dedicated 集群,上述示例中的`olm.catalogImageTemplate`注释将解析为以下镜像引用

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

对于 OpenShift Dedicated 的未来版本,您可以为您的自定义目录创建针对更高 Kubernetes 版本(由更高版本的 OpenShift Dedicated 使用)的更新索引镜像。在升级之前设置`olm.catalogImageTemplate`注释后,将集群升级到更高版本的 OpenShift Dedicated 将会自动更新目录的索引镜像。

目录健康要求

从安装解析的角度来看,集群上的 Operator 目录是可互换的;`Subscription`对象可能会引用特定目录,但依赖项是使用集群上的所有目录解析的。

例如,如果目录 A 不健康,则引用目录 A 的订阅可能会解析目录 B 中的依赖项,这可能是集群管理员没有预料到的,因为 B 通常比 A 的目录优先级低。

因此,OLM 要求所有具有给定全局命名空间的目录(例如,默认的`openshift-marketplace`命名空间或自定义全局命名空间)都是健康的。当目录不健康时,其共享全局命名空间内的所有 Operator 安装或更新操作都将失败,并显示`CatalogSourcesUnhealthy`状态。如果在不健康的状态下允许这些操作,OLM 可能会做出集群管理员意想不到的解析和安装决策。

作为集群管理员,如果您观察到一个不健康的目录,并且想将该目录视为无效并恢复 Operator 安装,请参阅“删除自定义目录”或“禁用默认 OperatorHub 目录源”部分,了解有关删除不健康目录的信息。

订阅

订阅(由`Subscription`对象定义)表示安装 Operator 的意图。它是将 Operator 与目录源关联的自定义资源。

订阅描述了要订阅哪个 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 Dedicated Web 控制台轻松查看之外,还可以通过检查相关订阅的状态来确定是否有更新版本的 Operator 可用。与`currentCSV`字段关联的值是 OLM 已知的最新版本,而`installedCSV`是安装在集群上的版本。

安装计划

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

要安装 Operator,集群管理员或已获得 Operator 安装权限的用户必须首先创建一个`Subscription`对象。订阅表示打算从目录源订阅可用 Operator 版本的流。然后,订阅创建`InstallPlan`对象以促进 Operator 资源的安装。

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

  • 如果订阅的`spec.installPlanApproval`字段设置为`Automatic`,则会自动批准安装计划。

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

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

示例`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
      ...

Operator 组

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

目标命名空间集由存储在集群服务版本 (CSV) 的`olm.targetNamespaces`注释中的逗号分隔的字符串提供。此注释应用于成员 Operator 的 CSV 实例,并投影到其部署中。

附加资源

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 逻辑的结果之前,`OperatorCondition`对象中不存在`Spec.Conditions`数组。

附加资源