工作流 - 理解 Operators | Operators | OpenShift Container Platform 4.17

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

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

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

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

ClusterServiceVersion (CSV)
CatalogSource
Subscription

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

图 1. 目录源概述

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

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

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

OLM 故意避免版本比较，因此从给定 *目录* → *通道* → *包* 路径获得的“最新”或“最新”操作符不一定是最高的版本号。它应该被认为更像是通道的 *头部* 引用，类似于 Git 存储库。

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

图 3. 可用通道更新的 OLM 图

包中的示例通道

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

为了让 OLM 成功查询更新（给定目录源、包、通道和 CSV），目录必须能够明确且确定性地返回单个replaces输入 CSV 的 CSV 文件。

示例升级路径

对于示例升级场景，考虑一个与 CSV 版本0.1.1对应的已安装 Operator。OLM 查询目录源，并在已订阅的通道中检测到一个升级，其中新的 CSV 版本0.1.3替换了旧的但未安装的 CSV 版本0.1.2，而0.1.2又替换了旧的已安装 CSV 版本0.1.1。

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

对于此给定场景，OLM 安装 Operator 版本0.1.2以替换现有的 Operator 版本0.1.1。然后，它安装 Operator 版本0.1.3以替换先前安装的 Operator 版本0.1.2。此时，已安装的 Operator 版本0.1.3与通道头部匹配，升级完成。

跳过升级

OLM 升级的基本路径是：

目录源更新了 Operator 的一个或多个更新。
OLM 遍历 Operator 的每个版本，直到到达目录源包含的最新版本。

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

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

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

通过发布新的目录并添加跳过的版本，可以确保 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. 跳过更新

此图保持：

在旧目录源中找到的任何 Operator 在新目录源中都有一个唯一的替代者。
在新目录源中找到的任何 Operator 在新目录源中都有一个唯一的替代者。
如果尚未安装不良更新，则永远不会安装。

替换多个 Operator

创建如上所述的新目录源需要发布replace一个 Operator 但可以skip多个 Operator 的 CSV 文件。这可以使用skipRange注释来实现：

olm.skipRange: <semver_range>

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

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

优先级顺序为：

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

包含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. 替换多个 Operator