2.4. Operator Lifecycle Manager (OLM)
2.4.1. Operator Lifecycle Manager 概念和资源
本指南概述了 OpenShift Container Platform 中 Operator Lifecycle Manager (OLM) 背后的概念。
2.4.1.1. Operator Lifecycle Manager 是什么?
Operator Lifecycle Manager(OLM)可帮助用户安装、更新和管理所有 Kubernetes 原生应用程序(Operator)以及在 OpenShift Container Platform 集群中运行的关联服务的生命周期。它是 Operator Framework 的一部分,后者是一个开源工具包,用于以有效、自动化且可扩展的方式管理 Operator。
图 2.2. Operator Lifecycle Manager 工作流
OLM 默认在 OpenShift Container Platform 4.7 中运行,辅助集群管理员对集群上运行的 Operator 进行安装、升级和授予访问权。OpenShift Container Platform Web 控制台提供一些管理界面,供集群管理员安装 Operator,以及为特定项目授权以便使用集群上的可用 Operator 目录。
开发人员通过自助服务体验,无需成为相关问题的专家也可自由置备和配置数据库、监控和大数据服务的实例,因为 Operator 已将相关知识融入其中。
2.4.1.2. OLM 资源
以下自定义资源定义 (CRD) 由 Operator Lifecycle Manager (OLM) 定义和管理:
资源 | 短名称 | 描述 |
---|---|---|
|
| 应用程序元数据。例如:名称、版本、图标、所需资源。 |
|
| 定义应用程序的 CSV、CRD 和软件包存储库。 |
|
| 通过跟踪软件包中的频道来保持 CSV 最新 |
|
| 为自动安装或升级 CSV 而需创建的资源的计算列表。 |
|
|
将部署在同一命名空间中的所有 Operator 配置为 |
| - |
在 OLM 和它管理的 Operator 之间创建通信频道。操作员可以写入 |
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 控制台中的 OperatorHub 也会显示由目录源提供的 Operator。
集群管理员可以使用 web 控制台中的 Administration
CatalogSource
的 spec
指明了如何构造 pod,以及如何与服务于 Operator Registry gRPC API 的服务进行通信。
例 2.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 的位置:
例 2.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
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.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 ...
其它资源
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
资源的 Status.Conditions
数组中存在时,则代表存在一组会影响 OLM 管理 Operator 的支持条件。
其它资源