工作流程 - 理解 Operators | Operators | Red Hat OpenShift Service on AWS

编辑

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

本指南概述了 AWS 上 Red Hat OpenShift Service 中 Operator Lifecycle Manager (OLM) 的工作流程。

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

在 Operator Lifecycle Manager (OLM) 生态系统中，以下资源用于解决 Operator 安装和升级

ClusterServiceVersion (CSV)
CatalogSource
Subscription

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

图 1. 目录源概述

在目录源中，Operator 被组织成包和称为通道的更新流，这应该是 AWS 上 Red Hat OpenShift Service 或其他持续发布周期软件（如 Web 浏览器）中熟悉的更新模式。

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

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

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

每个 CSV 都有一个replaces参数，指示它替换哪个 Operator。这构建了 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，该 CSVreplaces输入 CSV。

编辑

升级路径示例

对于升级场景示例，请考虑与 CSV 版本0.1.1对应的已安装 Operator。OLM 查询目录源并在订阅的通道中检测到升级，其中新的 CSV 版本0.1.3替换了较旧但未安装的 CSV 版本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多个的 CSV。这可以使用skipRange注释来完成

olm.skipRange: <semver_range>

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

在搜索目录以进行更新时，如果通道的头部具有skipRange注释并且当前安装的 Operator 具有落在范围内的版本字段，则 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 必须能够像在**旧 CatalogSource**中一样获取图形，并且像以前一样生成像**新 CatalogSource**中的图形。

图 5. 替换多个操作符