运算符生命周期管理器 (OLM) 帮助用户安装、更新和管理 Kubernetes 原生应用程序(运算符)及其在 OpenShift Container Platform 集群中运行的关联服务的生命周期。它是 Operator Framework 的一部分,这是一个开源工具包,旨在以有效、自动化和可扩展的方式管理运算符。
OLM 在 OpenShift Container Platform 4.17 中默认运行,这有助于集群管理员安装、升级和授予在其集群上运行的运算符的访问权限。OpenShift Container Platform Web 控制台为集群管理员提供了管理屏幕,以便安装运算符以及授予特定项目访问其集群上可用运算符目录的权限。
对于开发人员,自助服务体验允许配置和配置数据库、监控和大数据服务的实例,而无需成为主题专家,因为运算符已将这些知识集成到其中。
以下自定义资源定义 (CRD) 由运算符生命周期管理器 (OLM) 定义和管理
资源 | 简称 | 描述 |
---|---|---|
|
|
应用程序元数据。例如:名称、版本、图标、所需资源。 |
|
|
CSV、CRD 和定义应用程序的包的存储库。 |
|
|
通过跟踪包中的通道来保持 CSV 最新。 |
|
|
要创建的资源的计算列表,用于自动安装或升级 CSV。 |
|
|
配置部署在与 |
|
- |
在OLM与其管理的操作符之间创建一个通信通道。操作符可以写入 |
集群服务版本 (CSV) 代表在OpenShift Container Platform集群上运行的特定版本的操作符。它是由操作符元数据创建的YAML清单,可以帮助操作符生命周期管理器 (OLM) 在集群中运行操作符。
OLM需要操作符的这些元数据,以确保其能够安全地持续在集群上运行,并提供有关如何在发布新版本的操作符时应用更新的信息。这类似于为传统操作系统打包软件;可以将OLM的打包步骤视为创建rpm
、deb
或apk
包的阶段。
CSV包含与操作符容器镜像一起的元数据,用于填充用户界面信息,例如其名称、版本、描述、标签、存储库链接和徽标。
CSV也是运行操作符所需的技术信息的来源,例如它管理或依赖的自定义资源 (CR)、RBAC规则、集群要求和安装策略。这些信息告诉OLM如何创建所需资源并设置操作符作为部署。
目录源代表元数据的存储,通常通过引用存储在容器注册表中的索引镜像来实现。操作符生命周期管理器 (OLM) 查询目录源以发现和安装操作符及其依赖项。OpenShift Container Platform Web控制台中的OperatorHub也显示目录源提供的操作符。
集群管理员可以通过Web控制台中的**管理** → **集群设置** → **配置** → **OperatorHub**页面查看集群中已启用的目录源提供的操作符完整列表。 |
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 命名空间。否则,请将值设置为特定命名空间,以使操作符仅在该命名空间中可用。 |
3 | 可选:为避免集群升级可能导致操作符安装处于不受支持的状态或没有持续更新路径,您可以启用在集群升级过程中自动更改操作符目录的索引镜像版本。 将 |
4 | Web控制台和CLI中目录的显示名称。 |
5 | 目录的索引镜像。可选,在使用olm.catalogImageTemplate 注释时可以省略,该注释在运行时设置拉取规范。 |
6 | 目录源的权重。OLM在依赖项解析期间使用权重进行优先级排序。较高的权重表示该目录优于较低权重的目录。 |
7 | 源类型包括以下内容
|
8 | 指定legacy 或restricted 的值。如果未设置该字段,则默认值为legacy 。在未来的OpenShift Container Platform版本中,计划将默认值设置为restricted 。如果您的目录无法使用restricted 权限运行,建议您手动将此字段设置为legacy 。 |
9 | 可选:对于grpc 类型目录源,如果已定义,则覆盖为spec.image 中提供内容的pod的默认节点选择器。 |
10 | 可选:对于grpc 类型目录源,如果已定义,则覆盖为spec.image 中提供内容的pod的默认优先级类名称。Kubernetes默认情况下提供system-cluster-critical 和system-node-critical 优先级类。将字段设置为empty ("" ) 会为pod分配默认优先级。其他优先级类可以手动定义。 |
11 | 可选:对于grpc 类型目录源,如果已定义,则覆盖为spec.image 中提供内容的pod的默认容忍度。 |
12 | 以给定的间隔自动检查新版本以保持最新。 |
13 | 目录连接的最后观察到的状态。例如
有关更多详细信息,请参阅gRPC文档中的连接状态。 |
14 | 最后一次轮询存储目录镜像的容器注册表的时间,以确保镜像是最新的。 |
15 | 目录的Operator Registry服务的状况信息。 |
在订阅中引用CatalogSource
对象的name
会指示OLM在哪里搜索以查找请求的操作符。
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
操作符与底层集群的兼容性可以通过目录源以多种方式表达。一种方法(用于默认的Red Hat提供的目录源)是识别专为特定平台版本(例如OpenShift Container Platform 4.17)创建的索引镜像的镜像标签。
在集群升级期间,默认Red Hat提供的目录源的索引镜像标签会由集群版本操作符 (CVO) 自动更新,以便操作符生命周期管理器 (OLM) 拉取更新版本的目录。例如,在从OpenShift Container Platform 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不会自动更新自定义目录的镜像标签。为了确保用户在集群升级后仍拥有兼容且受支持的操作符安装,自定义目录也应保持更新以引用更新的索引镜像。
从OpenShift Container Platform 4.9开始,集群管理员可以在自定义目录的CatalogSource
对象中添加olm.catalogImageTemplate
注释到包含模板的镜像引用。支持在模板中使用以下Kubernetes版本变量
kube_major_version
kube_minor_version
kube_patch_version
必须指定Kubernetes集群版本,而不是OpenShift Container Platform集群版本,因为后者目前不可用于模板化。 |
假设您已创建并推送了一个包含指定更新 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 Container Platform 4.17 集群,上述示例中的 `olm.catalogImageTemplate` 注释解析为以下镜像引用
quay.io/example-org/example-catalog:v1.30
对于 OpenShift Container Platform 的未来版本,您可以为自定义目录创建针对更高 Kubernetes 版本(由更高 OpenShift Container Platform 版本使用)的更新索引镜像。在升级之前设置 `olm.catalogImageTemplate` 注释后,将集群升级到更高版本的 OpenShift Container Platform 将自动更新目录的索引镜像。
从安装解析的角度来看,集群上的 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 Container Platform 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 实例,并投影到它们的部署中。
作为运营商生命周期管理器 (OLM) 管理运营商生命周期角色的一部分,它会根据定义运营商的 Kubernetes 资源状态来推断运营商的状态。虽然这种方法在一定程度上确保了运营商处于特定状态,但在许多情况下,运营商可能需要向 OLM 传达无法通过其他方式推断的信息。然后,OLM 可以使用此信息更好地管理运营商的生命周期。
OLM 提供了一个名为OperatorCondition
的自定义资源定义 (CRD),允许运营商向 OLM 传达条件。当OperatorCondition
资源的Spec.Conditions
数组中存在一组受支持的条件时,这些条件会影响 OLM 对运营商的管理。
默认情况下,除非用户添加或自定义运营商逻辑导致添加,否则 |