Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

5.3. 更新路径

在决定更新路径（也称为升级路径或升级限制）时，对于已安装的集群扩展，Operator Lifecycle Manager (OLM) v1 支持从 OpenShift Container Platform 4.16 开始的 OLM (Classic) 语义。这个支持遵循 OLM (Classic) 的行为（包括 replaces, skips, 和 skipRange 指令），但有以下一些区别。

通过支持 OLM (Classic) 语义，OLM v1 会准确反映目录中的更新图表。

与原始 OLM (Classic) 实现的不同

  • 如果有多个可能的后续者，OLM v1 行为有所不同：

    • 在 OLM (Classic) 中，选择与频道头最接近的后续者。
    • 在 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
    Copy to Clipboard Toggle word wrap

    如果安装了 1.0.0，OLM v1 行为如下：

    • OLM (Classic) 不会检测到 v2.0.0 的更新路径，因为 v2.0.0 被跳过，而不是在 replaces 的链中。
    • OLM v1 将检测更新路径，因为 OLM v1 没有 replaces 链的概念。OLM v1 找到所有带有 replace、skip 或 skipRange 值的条目，它们涵盖当前安装的版本。

5.3.1. 支持版本范围
复制链接

在 Operator Lifecycle Manager (OLM) v1 中，您可以使用 Operator 或扩展的自定义资源(CR)中的比较字符串来指定版本范围。如果您在 CR 中指定版本范围，OLM v1 会安装或升级到可以在版本范围内解析的 Operator 的最新版本。

解析的版本工作流

  • 解析的版本是满足 Operator 和环境限制的 Operator 的最新版本。
  • 如果成功解决，则会自动安装指定范围内的 Operator 更新。
  • 当更新在指定的范围之外，或者无法成功解决，则不会安装更新。

5.3.2. 版本比较字符串
复制链接

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

Expand
表 5.4. 基本比较
比较运算符定义

=

等于

!=

不等于

>

大于

<

小于

>=

大于或等于

<=

小于或等于

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

版本范围比较示例

apiVersion: olm.operatorframework.io/v1
  kind: ClusterExtension
  metadata:
    name: <clusterextension_name>
  spec:
    namespace: <installed_namespace>
    serviceAccount:
      name: <service_account_installer_name>
    source:
      sourceType: Catalog
      catalog:
        packageName: <package_name>
        version: ">=1.11, <1.13"
Copy to Clipboard Toggle word wrap

您可以在所有类型的比较字符串中使用通配符字符。OLM v1 接受 x、X 和星号 (*) 作为通配符字符。您可以在等号 (=) 比较运算符中使用通配符，代表在补丁或次版本级别上定义比较。

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

1.11.x

>=1.11.0, <1.12.0

>=1.12.X

>=1.12.0

<=2.x

<3

*

>=0.0.0

您可以使用波形符 (~) 比较运算符进行补丁版本比较。补丁版本比较指定最高为下一个主版本的次版本。

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

~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

您可以使用 caret (^) 比较运算符来比较主版本。如果您在第一个稳定版本发布前进行主发行版本比较，次版本定义了 API 的稳定性级别。在语义版本 (semver) 规格中，第一个稳定版本被发布为 1.0.0 版本。

Expand
表 5.7. 主发行版本比较示例
主发行版本比较匹配字符串

^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

5.3.3. 指定目标版本的自定义资源(CR)示例
复制链接

在 Operator Lifecycle Manager (OLM) v1 中，集群管理员可以在自定义资源(CR)中声明性地设置 Operator 或扩展的目标版本。

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

  • Channel
  • 版本号
  • 版本范围

如果您在 CR 中指定频道，OLM v1 会安装可在指定频道中解析的 Operator 或扩展的最新版本。当向指定的频道发布更新时，OLM v1 会自动更新至可以从频道解析的最新发行版本。

带有指定频道的 CR 示例

apiVersion: olm.operatorframework.io/v1
  kind: ClusterExtension
  metadata:
    name: <clusterextension_name>
  spec:
    namespace: <installed_namespace>
    serviceAccount:
      name: <service_account_installer_name>
    source:
      sourceType: Catalog
      catalog:
        packageName: <package_name>
        channels:
          - latest
1
Copy to Clipboard Toggle word wrap

1
可选：安装可从指定频道解析的最新版本。对频道的更新会自动安装。指定 channels 参数的值（数组）。

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

如果要更新集群中安装的 Operator 版本，您必须手动编辑 Operator 的 CR。指定 Operator 的目标版本将 Operator 的版本固定到指定的发行版本。

指定了目标版本的 CR 示例

apiVersion: olm.operatorframework.io/v1
  kind: ClusterExtension
  metadata:
    name: <clusterextension_name>
  spec:
    namespace: <installed_namespace>
    serviceAccount:
      name: <service_account_installer_name>
    source:
      sourceType: Catalog
      catalog:
        packageName: <package_name>
        version: "1.11.1"
1
Copy to Clipboard Toggle word wrap

1
可选：指定目标版本。如果要更新安装的 Operator 或扩展版本，您必须手动将 CR 更新至所需的目标版本。

如果要为 Operator 或扩展定义可接受的版本范围，您可以使用比较字符串指定版本范围。当您指定版本范围时，OLM v1 会安装可由 Operator Controller 解析的 Operator 或扩展的最新版本。

指定了版本范围的 CR 示例

apiVersion: olm.operatorframework.io/v1
  kind: ClusterExtension
  metadata:
    name: <clusterextension_name>
  spec:
    namespace: <installed_namespace>
    serviceAccount:
      name: <service_account_installer_name>
    source:
      sourceType: Catalog
      catalog:
        packageName: <package_name>
        version: ">1.11.1"
1
Copy to Clipboard Toggle word wrap

1
可选：指定所需版本范围是否大于 1.11.1。如需更多信息，请参阅"支持版本范围"。

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

命令语法

$ oc apply -f <extension_name>.yaml
Copy to Clipboard Toggle word wrap

5.3.4. 强制更新或回滚
复制链接

OLM v1 不支持对下一个主版本的自动更新，或回滚到较早的版本。如果要执行主版本更新或回滚，您必须验证并强制更新。

警告

您必须验证强制进行手动更新或回滚的结果。验证强制更新或回滚失败可能会产生灾难性后果，如数据丢失。

先决条件

  • 已安装目录。
  • 已安装 Operator 或扩展。
  • 您已创建了服务帐户，并分配了足够的基于角色的访问控制 (RBAC) 来安装、更新和管理您要安装的扩展。如需更多信息，请参阅创建服务帐户。

流程

  1. 编辑 Operator 或扩展的自定义资源 (CR)，如下例所示：

    CR 示例

    apiVersion: olm.operatorframework.io/v1
  kind: ClusterExtension
  metadata:
    name: <clusterextension_name>
  spec:
    namespace: <installed_namespace>
    1 
    
    serviceAccount:
      name: <service_account_installer_name>
    2 
    
    source:
      sourceType: Catalog
      catalog:
        packageName: <package_name>
        channels:
          - <channel_name>
    3 
    
        version: <version_or_version_range>
    4 
    
        upgradeConstraintPolicy: SelfCertified
    5
    Copy to Clipboard Toggle word wrap

    1
    指定您要安装捆绑包的命名空间，如 pipelines 或 my-extension。扩展仍然是集群范围的，可能包含在不同命名空间中安装的资源。
    2
    指定您为安装、更新和管理扩展创建的服务帐户的名称。
    3
    可选：将频道名称指定为数组，如 pipelines-1.14 或 latest。
    4
    可选：指定您要安装的软件包的版本或版本范围，如 1.14.0、1.14.x 或 >=1.16。如需更多信息，请参阅"示例自定义资源(CR)指定目标版本"和"支持版本范围"。
    5
    可选：指定升级约束策略。要强制更新或回滚，请将字段设置为 SelfCertified。如果未指定，则默认设置为 CatalogProvided。只有在新版本满足软件包作者设置的升级限制时，CatalogProvided 设置才会更新。

  2. 运行以下命令，对 Operator 或 extensions CR 应用更改： 

    $ oc apply -f <extension_name>.yaml
    Copy to Clipboard Toggle word wrap

5.3.5. 与 OpenShift Container Platform 版本的兼容性
复制链接

在集群管理员将其 OpenShift Container Platform 集群更新至其下一个次版本前，它们必须确保所有安装的 Operator 更新至与集群下一个次版本(4.y+1)兼容的捆绑包版本。

例如，Kubernetes 定期弃用后续版本中删除的某些 API。如果使用已弃用的 API，则在 OpenShift Container Platform 集群更新至删除 API 的 Kubernetes 版本后，它可能无法正常工作。

如果 Operator 作者知道不支持特定的捆绑包版本，且出于某种原因，在 OpenShift Container Platform 上比特定集群次版本稍后无法正常工作，他们可以配置其 Operator 兼容的最大 OpenShift Container Platform 版本。

在 Operator 项目的集群服务版本(CSV)中，作者可以设置 olm.maxOpenShiftVersion 注解，以防止管理员在将已安装的 Operator 更新至兼容版本前更新集群。

带有 olm.maxOpenShiftVersion 注解的 CSV 示例

apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
  annotations:
    "olm.properties": '[{"type": "olm.maxOpenShiftVersion", "value": "<cluster_version>"}]'
1
Copy to Clipboard Toggle word wrap

1
指定 Operator 兼容的最新 OpenShift Container Platform (4.y)次要版本。例如，在集群中安装此捆绑包时，将 value 设为 4.19 可防止集群升级到 4.19 之后的次版本。

如果省略 olm.maxOpenShiftVersion 字段，则此 Operator 不会阻断集群更新。

注意

在决定集群的下一个次版本(4.y+1)时，OLM v1 只考虑主版本和次版本(x 和 y)进行比较。它会忽略任何 z-stream 版本(4.y.z)，也称为补丁版本或预发布版本。

例如，如果集群的当前版本是 4.19.0，则下一个次版本为 4.20。如果当前版本为 4.19.0-rc1，则下一个次版本仍为 4.20。

5.3.5.1. olm cluster Operator 阻止的集群更新
复制链接

如果设置了已安装的 Operator olm.maxOpenShiftVersion 字段，并且集群管理员尝试将其集群更新至 Operator 没有提供有效更新路径的版本，则集群更新会失败，并且 olm cluster Operator 的 Upgradeable 设置为 False。

要解决这个问题，集群管理员必须将已安装的 Operator 更新至具有有效更新路径的版本（如果可用），或者必须卸载 Operator。然后，他们可以尝试集群更新。

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat