Operator 生命周期管理器 (OLM) 帮助用户安装、更新和管理 Kubernetes 原生应用程序 (Operators) 及其在 OpenShift Dedicated 集群中运行的相关服务的生命周期。它是 Operator Framework 的一部分,这是一个开源工具包,旨在以有效、自动化和可扩展的方式管理 Operators。
OLM 在 OpenShift Dedicated 中默认运行,这有助于具有 `dedicated-admin` 角色的管理员安装、升级和授予对在其集群上运行的 Operators 的访问权限。OpenShift Dedicated Web 控制台为 `dedicated-admin` 管理员提供管理屏幕,以便安装 Operators,以及授予特定项目访问集群上可用 Operators 目录的权限。
对于开发人员而言,自助服务体验允许配置和配置数据库、监控和大型数据服务的实例,而无需成为主题专家,因为 Operator 已将这些知识集成到其中。
以下自定义资源定义 (CRD) 由 Operator 生命周期管理器 (OLM) 定义和管理
资源 | 简称 | 描述 |
---|---|---|
|
|
应用程序元数据。例如:名称、版本、图标、所需资源。 |
|
|
CSV、CRD 和定义应用程序的包的存储库。 |
|
|
通过跟踪包中的通道来保持 CSV 最新。 |
|
|
要创建的资源的计算列表,以自动安装或升级 CSV。 |
|
|
配置部署在与 `OperatorGroup` 对象相同命名空间中的所有 Operators,以监视其自定义资源 (CR) 在命名空间列表中或集群范围内。 |
|
- |
在 OLM 和其管理的 Operator 之间创建通信通道。Operators 可以写入 `Status.Conditions` 数组以向 OLM 传达复杂状态。 |
集群服务版本 (CSV) 代表 OpenShift Dedicated 集群上运行的 Operator 的特定版本。它是根据 Operator 元数据创建的 YAML 清单,可帮助 Operator 生命周期管理器 (OLM) 在集群中运行 Operator。
OLM 需要这些关于 Operator 的元数据,以确保它可以在集群上安全地运行,并提供有关如何在发布新版本的 Operator 时应用更新的信息。这类似于为传统操作系统打包软件;可以将 OLM 的打包步骤视为创建 rpm
、deb
或 apk
包的阶段。
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 目录的索引镜像版本。 将 |
4 | Web 控制台和 CLI 中目录的显示名称。 |
5 | 目录的索引镜像。可选,在使用 olm.catalogImageTemplate 注解时可以省略,该注解在运行时设置拉取规范。 |
6 | 目录源的权重。OLM 使用权重在依赖项解析期间进行优先级排序。权重越高,表示该目录比权重较低的目录更受青睐。 |
7 | 源类型包括:
|
8 | 指定 legacy 或 restricted 的值。如果未设置该字段,则默认值为 legacy 。在未来的 OpenShift Dedicated 版本中,计划将默认值设置为 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 | 目录连接的最后观察到的状态。例如:
有关更多详细信息,请参阅 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,以确保始终在集群中运行最新版本。
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。
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 组(由`OperatorGroup`资源定义)为 OLM 安装的 Operator 提供多租户配置。Operator 组选择要为其成员 Operator 生成所需 RBAC 访问权限的目标命名空间。
目标命名空间集由存储在集群服务版本 (CSV) 的`olm.targetNamespaces`注释中的逗号分隔的字符串提供。此注释应用于成员 Operator 的 CSV 实例,并投影到其部署中。
作为管理 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`数组。 |