×

运营商生命周期管理器 (OLM) v1 仅为技术预览功能。技术预览功能不受 Red Hat 生产服务级别协议 (SLA) 支持,并且可能功能不完整。Red Hat 不建议在生产环境中使用它们。这些功能可让客户提前访问即将推出的产品功能,从而能够在开发过程中测试功能并提供反馈。

有关 Red Hat 技术预览功能的支持范围的更多信息,请参见 技术预览功能支持范围

在确定已安装集群扩展的升级边缘(也称为升级路径或升级约束)时,运营商生命周期管理器 (OLM) v1 从 OpenShift Container Platform 4.16 开始支持现有的 OLM 语义。此支持遵循现有 OLM 的行为,包括replacesskipsskipRange 指令,但有一些区别。

通过支持现有的 OLM 语义,OLM v1 现在可以准确地遵守来自目录的升级图。

目前,运营商生命周期管理器 (OLM) v1 无法验证私有注册表,例如 Red Hat 提供的 Operator 目录。这是一个已知问题。因此,依赖于安装 Red Hat Operators 目录的 OLM v1 流程无法正常工作。(OCPBUGS-36364

与原始现有 OLM 实现的差异
  • 如果存在多个可能的后续版本,OLM v1 的行为会有所不同

    • 在现有的 OLM 中,选择最接近通道头的后续版本。

    • 在 OLM v1 中,选择语义版本 (semver) 最高的后续版本。

  • 考虑以下基于文件的目录 (FBC) 通道条目集

    # ...
    - name: example.v3.0.0
      skips: ["example.v2.0.0"]
    - name: example.v2.0.0
      skipRange: >=1.0.0 <2.0.0

    如果安装了1.0.0,则 OLM v1 的行为会有所不同

    • 现有的 OLM 无法检测到到v2.0.0 的升级边缘,因为v2.0.0 被跳过并且不在replaces 链上。

    • OLM v1 将检测到升级边缘,因为 OLM v1 没有replaces 链的概念。OLM v1 查找所有具有replaceskipskipRange 值的条目,这些值涵盖当前安装的版本。

版本范围的支持

在运营商生命周期管理器 (OLM) v1 中,您可以使用 Operator 或扩展的自定义资源 (CR) 中的比较字符串来指定版本范围。如果在 CR 中指定版本范围,OLM v1 将安装或更新到可在版本范围内解析的 Operator 的最新版本。

已解析版本的工作流程
  • 已解析版本是满足 Operator 和环境约束的 Operator 的最新版本。

  • 如果成功解析,则会自动安装指定范围内的 Operator 更新。

  • 如果更新位于指定范围之外或无法成功解析,则不会安装更新。

版本比较字符串

您可以通过向 Operator 或扩展的自定义资源 (CR) 中的spec.version 字段添加比较字符串来定义版本范围。比较字符串是用双引号 (")括起来的一系列空格或逗号分隔的值和一个或多个比较运算符。您可以通过在字符串之间包含OR 或双竖线 (||) 比较运算符来添加另一个比较字符串。

表 1. 基本比较
比较运算符 定义

=

等于

!=

不等于

>

大于

<

小于

>=

大于或等于

<=

小于或等于

您可以使用类似于以下示例的范围比较来在 Operator 或扩展的 CR 中指定版本范围

示例版本范围比较
apiVersion: olm.operatorframework.io/v1alpha1
kind: ClusterExtension
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  installNamespace: <namespace_name>
  version: ">=1.11, <1.13"

您可以在所有类型的比较字符串中使用通配符。OLM v1 接受xX 和星号 (*) 作为通配符。当您将通配符与等号 (=) 比较运算符一起使用时,您将在补丁或次要版本级别定义比较。

表 2. 比较字符串中的示例通配符
通配符比较 匹配字符串

1.11.x

>=1.11.0, <1.12.0

>=1.12.X

>=1.12.0

<=2.x

<3

*

>=0.0.0

您可以使用波浪号 (~) 比较运算符进行补丁版本比较。补丁版本比较指定次要版本到下一个主要版本。

表 3. 示例补丁版本比较
补丁版本比较 匹配字符串

~1.11.0

>=1.11.0, <1.12.0

~1

>=1, <2

~1.12

>=1.12, <1.13

~1.12.x

>=1.12.0, <1.13.0

~1.x

>=1, <2

您可以使用插入符 (^) 比较运算符进行主要版本的比较。如果您在发布第一个稳定版本之前进行主要版本比较,则次要版本定义 API 的稳定性级别。在语义版本控制 (semver) 规范中,第一个稳定版本发布为1.0.0 版本。

表 4. 示例主要版本比较
主要版本比较 匹配字符串

^0

>=0.0.0, <1.0.0

^0.0

>=0.0.0, <0.1.0

^0.0.3

>=0.0.3, <0.0.4

^0.2

>=0.2.0, <0.3.0

^0.2.3

>=0.2.3, <0.3.0

^1.2.x

>= 1.2.0, < 2.0.0

^1.2.3

>= 1.2.3, < 2.0.0

^2.x

>= 2.0.0, < 3

^2.3

>= 2.3, < 3

指定目标版本的示例自定义资源 (CR)

在运营商生命周期管理器 (OLM) v1 中,集群管理员可以在自定义资源 (CR) 中声明性地设置 Operator 或扩展的目标版本。

您可以通过指定以下任何字段来定义目标版本

  • 通道

  • 版本号

  • 版本范围

如果在 CR 中指定通道,OLM v1 将安装可在指定通道中解析的 Operator 或扩展的最新版本。当更新发布到指定的通道时,OLM v1 会自动更新到可从通道解析的最新版本。

带有指定通道的示例 CR
apiVersion: olm.operatorframework.io/v1alpha1
kind: ClusterExtension
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  installNamespace: <namespace_name>
  serviceAccount:
    name: <service_account>
  channel: latest (1)
1 安装可从指定通道解析的最新版本。通道更新会自动安装。

如果在 CR 中指定 Operator 或扩展的目标版本,OLM v1 将安装指定的版本。当在 CR 中指定目标版本时,OLM v1 不会在将更新发布到目录时更改目标版本。

如果要更新安装在集群上的 Operator 的版本,则必须手动编辑 Operator 的 CR。指定 Operator 的目标版本会将 Operator 的版本固定到指定的版本。

指定目标版本的示例 CR
apiVersion: olm.operatorframework.io/v1alpha1
kind: ClusterExtension
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  installNamespace: <namespace_name>
  serviceAccount:
    name: <service_account>
  version: "1.11.1" (1)
1 指定目标版本。如果要更新安装的 Operator 或扩展的版本,则必须手动将 CR 中的此字段更新为所需的目标版本。

如果要为 Operator 或扩展定义一系列可接受的版本,则可以使用比较字符串来指定版本范围。当您指定版本范围时,OLM v1 将安装 Operator 控制器可以解析的 Operator 或扩展的最新版本。

指定版本范围的示例 CR
apiVersion: olm.operatorframework.io/v1alpha1
kind: ClusterExtension
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  installNamespace: <namespace_name>
  serviceAccount:
    name: <service_account>
  version: ">1.11.1" (1)
1 指定所需版本范围大于版本1.11.1。有关更多信息,请参见“版本范围的支持”。

创建或更新 CR 后,请运行以下命令来应用配置文件

命令语法
$ oc apply -f <extension_name>.yaml

强制更新或回滚

OLM v1 不支持自动更新到下一个主要版本或回滚到早期版本。如果要执行主要版本更新或回滚,必须手动验证和强制更新。

必须验证强制手动更新或回滚的后果。未能验证强制更新或回滚可能会导致灾难性后果,例如数据丢失。

先决条件
  • 您已安装了一个目录。

  • 您已安装了一个 Operator 或扩展。

  • 您已创建了一个服务帐户,并分配了足够的基于角色的访问控制 (RBAC) 来安装、更新和管理您想要安装的扩展。有关更多信息,请参见《创建服务帐户》。

步骤
  1. 按照以下示例编辑您的 Operator 或扩展的自定义资源 (CR)

    示例 CR
    apiVersion: olm.operatorframework.io/v1alpha1
    kind: Operator
    metadata:
      name: <operator_name> (1)
    spec:
      packageName: <package_name> (2)
      installNamespace: <namespace_name>
      serviceAccount:
        name: <service_account>
      version: <version> (3)
      upgradeConstraintPolicy: Ignore (4)
    1 指定 Operator 或扩展的名称,例如 pipelines-operator
    2 指定包名,例如 openshift-pipelines-operator-rh
    3 指定被阻止的更新或回滚版本。
    4 可选:指定升级约束策略。要强制更新或回滚,请将字段设置为 Ignore。如果未指定,则默认设置为 Enforce
  2. 通过运行以下命令将更改应用于您的 Operator 或扩展 CR

    $ oc apply -f <extension_name>.yaml