OpenShift 文档正在迁移，不久之后将只能在 docs.redhat.com（所有 Red Hat 产品文档的中心）访问。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

无服务器升级

无服务器 Operator 维护版本升级

最新版本和维护版本

从 OpenShift Serverless 1.29 开始，不同的产品版本可通过以下方式获取：

  • 最新版本可通过 `stable` 通道获取。

  • 维护版本可通过其基于版本的通道获取，例如 `stable-1.29`。

    维护版本是最新版本之前的版本。例如，如果 `stable` 通道包含 1.30 版本，则维护版本将在 `stable-1.29` 通道中可用。

使用基于版本的通道允许您停留在特定的 `x.y` 流中。此外，它可以防止升级到产品的最新版本，因为最新版本可能包含重大更改。

要切换到维护版本，请将订阅对象 YAML 文件中的通道参数从 `stable` 更新到相应的基于版本的通道，例如 `stable-1.29`。

维护版本的补丁和修补程序

与稳定版本一样，维护版本也需要补丁和修补程序，这有助于使您的部署保持最新，并包含关键的错误和安全修复。

  • 补丁是作为 z 版本发布的更新，例如，OpenShift Serverless 1.29.1 是自 1.29.0 版本以来提供的更新的补丁。

  • 修补程序是无需停机的修复程序，可直接用于生产环境。它们与通常的更新不同，因为它们升级客户已部署的版本，而不是最新发布的版本。

    修补程序可能并非所有客户都能立即获得。但是，修补程序引入的更改通常会在未来的版本中提供给所有客户。

    如果您的部署有可用的修补程序，系统会为您提供修补程序 CatalogSource 以更新您的订阅并获取修补程序。

    提供新的运算符版本后，也可以升级带有修补程序的已部署运算符。要使用最新的 GA 版本，请修改订阅以使用公共 CatalogSource，而不是修补程序 CatalogSource。

下图说明了补丁和修补程序的工作方式

     stable                                       stable-1.28
+--------------+                 +--------------------------------------------+
|              |                 |                                            |
|  +--------+  | corresponds to  |   +--------+    +--------+    +--------+   |
|  | 1.28.0 |----------------------> | 1.28.0 |    | 1.28.1 |    | 1.28.2 |   |
|  +--------+  |                 |   +--------+    +--------+    +--------+   |
|              |                 |     |                   ^            |     |
|              |                 +-----|-------------------|------------|-----+
|  +--------+  |                created|                   |upgrades    |
|  | 1.28.1 |  |                from   |     hotfix_xyz    |to          |
|  +--------+  |                       |   +------------+  |            |
|              |                       +-->|            |--+            |
|              |                           |            |               |
|  +--------+  | upgrades to               +------------+               |
|  | 1.29.0 |<----------------------------------------------------------+
|  +--------+  |
|              |
|              |
|  +--------+  |
|  | 1.30.0 |  |
|  +--------+  |
|              |
+--------------+

维护版本的升级路径

如果您使用基于版本的通道，您可以随时升级到通道中的最新版本或头部版本。例如，您可以在 `stable-1.29` 通道中从 1.29.0 升级到 1.29.2。

此外，从通道的头部版本，您可以升级到下一个 `x.y` 版本。例如，如果 1.29.2 是 `stable-1.29` 通道中的头部版本，您可以从 1.29.2 升级到 1.30。此类跨通道更新不会自动执行，管理员需要通过更新订阅手动切换通道。

升级示例

场景 1

在此场景中，存在以下情况：

  • 通道为 `stable-1.28`

  • 您正在切换到 `stable` 通道

  • 当前安装的版本为 1.28.0

  • 1.29.0 在 1.28.1 之前发布

  • 1.30.0 是stable通道的最新版本

在这种情况下，从stable-1.28通道上的1.28.0升级到stable通道上的1.29.0的路径是：1.28.0 -> 1.28.1 -> 1.29.0。

     stable                    stable-1.28
+--------------+            +--------------+
|              |            |              |
|  +--------+  |            |  +--------+  |
|  | 1.28.0 |  |            |  | 1.28.0 |  |
|  +--------+  |            |  +--------+  |
|              |            |       |      |
|              |            |       |      |
|  +--------+  |            |       |      |
|  | 1.29.0 |<--------      |       v      |
|  +--------+  |     |      |  +--------+  |
|              |     +---------| 1.28.1 |  |
|              |            |  +--------+  |
|  +--------+  |            |              |
|  | 1.30.0 |  |            |              |
|  +--------+  |            |              |
|              |            |              |
+--------------+            +--------------+

场景 2

在此场景中，存在以下情况：

  • 通道为stable-1.29

  • 当前已安装的版本为1.29.0

  • 在1.30.0发布到stable通道之前，1.29.1已发布到stable-1.29和stable通道。

在这种情况下，从stable-1.29通道上的1.29.0升级到stable通道上的1.30.0的路径是：1.29.0 -> 1.29.1 -> 1.30.0。

     stable                   stable-1.29
+--------------+           +--------------+
|              |           |              |
|  +--------+  |           |  +--------+  |
|  | 1.29.0 |  |           |  | 1.29.0 |  |
|  +--------+  |           |  +--------+  |
|              |           |       |      |
|              |           |       v      |
|  +--------+  |           |  +--------+  |
|  | 1.29.1 |  |           |  | 1.29.1 |  |
|  +--------+  |           |  +--------+  |
|              |           |       |      |
|              |           |       |      |
|  +--------+  |           |       |      |
|  | 1.30.0 |<---------------------+      |
|  +--------+  |           |              |
|              |           |              |
+--------------+           +--------------+

场景 3

在此场景中，存在以下情况：

  • 通道为stable-1.29

  • 您正在切换到stable-1.30通道

  • 当前已安装的版本为1.29.1

  • 1.29.1是stable-1.29通道的最新版本

在这种情况下，从stable-1.29通道上的1.29.1升级到stable-1.30通道上的1.30.0的路径是：1.29.1 -> 1.30.0。

   stable-1.29              stable-1.30
+--------------+         +--------------+
|              |         |              |
|  +--------+  |         |  +--------+  |
|  | 1.29.0 |  |    ------> | 1.30.0 |  |
|  +--------+  |    |    |  +--------+  |
|              |    |    |              |
|              |    |    |              |
|  +--------+  |    |    |              |
|  | 1.29.1 |-------+    |              |
|  +--------+  |         |              |
|              |         |              |
+--------------+         +--------------+

解决OpenShift Serverless Operator升级失败

升级OpenShift Serverless Operator时可能会遇到错误，例如，在执行手动卸载和重新安装时。如果遇到错误，则必须手动重新安装OpenShift Serverless Operator。

步骤

  1. 通过搜索OpenShift Serverless发行说明来确定最初安装的OpenShift Serverless Operator版本。

    例如，升级尝试期间的错误消息可能包含以下字符串

    The installed KnativeServing version is v1.5.0.

    在此示例中，KnativeServing的MAJOR.MINOR版本为1.5，这在OpenShift Serverless 1.26的发行说明中有所介绍： *OpenShift Serverless现在使用Knative Serving 1.5*。

  2. 卸载OpenShift Serverless Operator及其所有安装计划。

  3. 手动安装在第一步中发现的OpenShift Serverless Operator版本。要安装，首先创建一个serverless-subscription.yaml文件，如下例所示

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: serverless-operator
  namespace: openshift-serverless
spec:
  channel: stable
  name: serverless-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
  startingCSV: serverless-operator.v1.26.0

  4. 然后，运行以下命令安装订阅

    $ oc apply -f serverless-subscription.yaml

  5. 通过手动批准出现的升级安装计划来进行升级。

更多资源