工作流程 - 理解 Operators | Operators | OpenShift Dedicated

OLM 中的运算符安装和升级工作流程

本指南概述了 OpenShift Dedicated 中运算符生命周期管理器 (OLM) 的工作流程。

OLM 中的运算符安装和升级工作流程

在运算符生命周期管理器 (OLM) 生态系统中，以下资源用于解决运算符安装和升级问题

ClusterServiceVersion (CSV)
CatalogSource
订阅

在 CSV 中定义的运算符元数据可以存储在称为目录源的集合中。OLM 使用目录源（使用 Operator Registry API）来查询可用的运算符以及已安装运算符的升级。

图 1. 目录源概述

在目录源中，运算符被组织成 *包* 和称为 *通道* 的更新流，这应该是 OpenShift Dedicated 或其他具有持续发布周期的软件（如 Web 浏览器）中熟悉的更新模式。

图 2. 目录源中的包和通道

用户在 *订阅* 中指示特定目录源中的特定包和通道，例如 `etcd` 包及其 `alpha` 通道。如果对尚未在命名空间中安装的包进行订阅，则会安装该包的最新运算符。

OLM 故意避免版本比较，因此从给定 *目录* → *通道* → *包* 路径获得的“最新”或“最新”运算符不一定需要是版本号最高的。它应该更多地被认为是通道的 *head* 引用，类似于 Git 仓库。

每个 CSV 都具有一个 `replaces` 参数，该参数指示它替换哪个运算符。这构建了可以由 OLM 查询的 CSV 图，并且更新可以在通道之间共享。通道可以被认为是更新图的入口点。

图 3. OLM 可用通道更新图

包中的通道示例

packageName: example
channels:
- name: alpha
  currentCSV: example.v0.1.2
- name: beta
  currentCSV: example.v0.1.3
defaultChannel: alpha

为了使 OLM 能够成功查询更新，给定目录源、包、通道和 CSV，目录必须能够明确且确定性地返回单个 CSV，该 CSV 替换输入 CSV。

升级路径示例

对于升级场景示例，请考虑与 CSV 版本 `0.1.1` 相对应的已安装运算符。OLM 查询目录源并在订阅的通道中检测到升级，新的 CSV 版本为 `0.1.3`，它替换了较旧但未安装的 CSV 版本 `0.1.2`，而 `0.1.2` 又替换了较旧且已安装的 CSV 版本 `0.1.1`。

OLM 通过 CSV 中指定的 `replaces` 字段从通道 head 向前版本回溯，以确定升级路径 `0.1.3` → `0.1.2` → `0.1.1`；箭头方向表示前者替换后者。OLM 一次升级一个版本，直到到达通道 head。

对于此给定场景，OLM 安装运算符版本 `0.1.2` 以替换现有的运算符版本 `0.1.1`。然后，它安装运算符版本 `0.1.3` 以替换先前安装的运算符版本 `0.1.2`。此时，已安装的运算符版本 `0.1.3` 与通道 head 匹配，并且升级完成。

跳过升级

OLM 中升级的基本路径是

目录源已更新，其中包含对运算符的一个或多个更新。
OLM 会遍历操作符的每个版本，直到到达目录源包含的最新版本。

但是，有时此操作并非安全操作。在某些情况下，如果操作符的已发布版本尚未安装在集群上，则永远不应该安装，例如，因为某个版本引入了严重的漏洞。

在这些情况下，OLM 必须考虑两种集群状态，并提供支持这两种状态的更新图。

集群已看到并安装了“不良”中间操作符。
集群尚未安装“不良”中间操作符。

通过发布新的目录并添加一个 _跳过_ 的版本，可以确保 OLM 始终能够获得唯一的更新，而不管集群状态如何，以及它是否已经看到不良更新。

包含跳过版本的示例 CSV

apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
  name: etcdoperator.v0.9.2
  namespace: placeholder
  annotations:
spec:
    displayName: etcd
    description: Etcd Operator
    replaces: etcdoperator.v0.9.0
    skips:
    - etcdoperator.v0.9.1

考虑以下 **旧目录源** 和 **新目录源** 的示例。

图 4. 跳过更新

此图保持以下状态：

在 **旧目录源** 中找到的任何操作符在 **新目录源** 中都有一个唯一的替换。
在 **新目录源** 中找到的任何操作符在 **新目录源** 中都有一个唯一的替换。
如果尚未安装不良更新，则它将永远不会被安装。

替换多个操作符

如上所述创建 **新目录源** 需要发布替换一个操作符但可以跳过多个操作符的 CSV。这可以使用 `skipRange` 注解来实现。

olm.skipRange: <semver_range>

其中 `` 具有 semver 库支持的版本范围格式。

在搜索目录更新时，如果通道的头部具有 `skipRange` 注解，并且当前已安装的操作符的版本字段落在该范围内，则 OLM 会更新到通道中的最新条目。

优先级顺序为：

订阅上 `sourceName` 指定的源中的通道头部（如果满足跳过的其他条件）。
`sourceName` 指定的源中替换当前操作符的下一个操作符。
订阅可见的另一个源中的通道头部（如果满足跳过的其他条件）。
订阅可见的任何源中替换当前操作符的下一个操作符。

包含 `skipRange` 的示例 CSV

apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
    name: elasticsearch-operator.v4.1.2
    namespace: <namespace>
    annotations:
        olm.skipRange: '>=4.1.0 <4.1.2'

Z 流支持

_Z 流_ 或补丁版本必须替换同一次要版本的先前所有 Z 流版本。OLM 不会考虑主版本、次要版本或补丁版本，它只需要在目录中构建正确的图。

换句话说，OLM 必须能够像在 **旧目录源** 中一样获取图，并且与之前类似，生成像在 **新目录源** 中一样的图。

图 5. 替换多个操作符