×

本指南概述了在 AWS 上的 Red Hat OpenShift Service 中驱动 Operator Lifecycle Manager (OLM) 的概念。

什么是 Operator Lifecycle Manager?

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

olm workflow
图 1. Operator Lifecycle Manager 工作流程

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

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

OLM 资源

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

表 1. OLM 和目录 Operators 管理的 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) 表示在 AWS 上的 Red Hat OpenShift Service 集群上运行的 Operator 的特定版本。它是从 Operator 元数据创建的 YAML 清单,它辅助 Operator Lifecycle Manager (OLM) 在集群中运行 Operator。

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

CSV 包括伴随 Operator 容器映像的元数据,用于使用其名称、版本、描述、标签、存储库链接和徽标等信息填充用户界面。

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

目录源

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

集群管理员可以通过在 Web 控制台中使用**管理** → **集群设置** → **配置** → **OperatorHub** 页面来查看集群上启用的目录源提供的 Operators 的完整列表。

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 解析 config map 数据并运行一个 pod,该 pod 可以通过它提供 gRPC API。

8 指定legacyrestricted的值。如果未设置此字段,则默认值为legacy。在未来的AWS上的Red Hat OpenShift Service版本中,计划将默认值更改为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提供的目录源)是标识专门为特定平台版本(例如AWS上的Red Hat OpenShift Service)创建的索引镜像的镜像标签。

在集群升级期间,集群版本操作符 (CVO) 会自动更新默认Red Hat提供的目录源的索引镜像标签,以便Operator生命周期管理器 (OLM) 拉取更新版本的目录。例如,在将AWS上的Red Hat OpenShift Service从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安装,还应更新自定义目录以引用更新的索引镜像。

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

  • kube_major_version

  • kube_minor_version

  • kube_patch_version

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

假设您已创建并推送了带有指定更新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的AWS上的Red Hat OpenShift Service集群,上述示例中的olm.catalogImageTemplate注释将解析为以下镜像引用

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

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

目录健康要求

从安装解析的角度来看,集群上的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 数据的目录。通道,例如alphabetastable,有助于确定应从目录源安装哪个 Operator 流。

订阅中通道的名称在不同的 Operator 之间可能有所不同,但在给定的 Operator 内,命名方案应遵循通用约定。例如,通道名称可能遵循 Operator 提供的应用程序的次要版本更新流(1.21.3)或发布频率(stablefast)。

除了可以从 AWS Web 控制台上的 Red Hat OpenShift Service 中轻松查看之外,还可以通过检查相关订阅的状态来确定是否有更新版本的 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 的管理。

默认情况下,OperatorCondition对象中不存在Spec.Conditions数组,除非它是由用户添加的,或者是由自定义 Operator 逻辑导致的。

其他资源