Operator Lifecycle Manager (OLM) 帮助用户安装、更新和管理 Kubernetes 原生应用程序 (Operators) 及其在 AWS 上的 Red Hat OpenShift Service 集群中运行的相关服务的生命周期。它是 Operator Framework 的一部分,这是一个开源工具包,旨在以有效、自动化和可扩展的方式管理 Operators。
OLM 在 AWS 上的 Red Hat OpenShift Service 中默认运行,这有助于拥有 `dedicated-admin` 角色的管理员安装、升级和授予在其集群上运行的 Operators 的访问权限。AWS 上的 Red Hat OpenShift Service Web 控制台为 `dedicated-admin` 管理员提供管理屏幕,用于安装 Operators,以及授予特定项目访问集群上可用 Operators 目录的权限。
对于开发人员而言,自助服务体验允许配置数据库、监控和大型数据服务的实例,而无需成为主题专家,因为 Operator 已将这些知识嵌入其中。
以下自定义资源定义 (CRD) 由 Operator Lifecycle Manager (OLM) 定义和管理
资源 | 简称 | 描述 |
---|---|---|
|
|
应用程序元数据。例如:名称、版本、图标、所需资源。 |
|
|
CSV、CRD 和定义应用程序的包的存储库。 |
|
|
通过跟踪包中的通道来保持 CSV 最新。 |
|
|
要创建的资源的计算列表,用于自动安装或升级 CSV。 |
|
|
配置部署在与 |
|
- |
在 OLM 及其管理的 Operator 之间创建通信通道。Operators 可以写入 |
集群服务版本 (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 目录的索引映像版本。 将 |
4 | Web 控制台和 CLI 中目录的显示名称。 |
5 | 目录的索引映像。可选,在使用olm.catalogImageTemplate 注解时可以省略,该注解在运行时设置拉取规范。 |
6 | 目录源的权重。OLM 在依赖项解析期间使用权重进行优先级排序。较高的权重表示该目录比权重较低的目录更受青睐。 |
7 | 源类型包括:
|
8 | 指定legacy 或restricted 的值。如果未设置此字段,则默认值为legacy 。在未来的AWS上的Red Hat OpenShift Service版本中,计划将默认值更改为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提供的目录源)是标识专门为特定平台版本(例如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
如果同时设置了 如果未设置 |
对于使用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 数据的目录。通道,例如alpha
、beta
或stable
,有助于确定应从目录源安装哪个 Operator 流。
订阅中通道的名称在不同的 Operator 之间可能有所不同,但在给定的 Operator 内,命名方案应遵循通用约定。例如,通道名称可能遵循 Operator 提供的应用程序的次要版本更新流(1.2
、1.3
)或发布频率(stable
、fast
)。
除了可以从 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 组,由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 的管理。
默认情况下, |