2.4.3. Operator Lifecycle Manager 工作流
本指南概述了 OpenShift Container Platform 中 Operator Lifecycle Manager (OLM) 的工作流。
2.4.3.1. OLM 中的 Operator 安装和升级工作流
在 Operator Lifecycle Manager (OLM) 生态系统中，以下资源用于解决 Operator 的安装和升级问题：
-
ClusterServiceVersion(CSV) -
CatalogSource -
Subscription
CSV 中定义的 Operator 元数据可保存在一个称为目录源的集合中。目录源使用 Operator Registry API，OLM 又使用目录源来查询是否有可用的 Operator 及已安装 Operator 是否有升级版本。
图 2.3. 目录源概述
在目录源中，Operator 被整合为更新软件包和更新流，我们称为频道，这应是 OpenShift Container Platform 或其他软件（如 Web 浏览器）在持续发行周期中的常见更新模式。
图 2.4. 目录源中的软件包和频道
用户在订阅中的特定目录源中指示特定软件包和频道，如 etcd 包及其 alpha 频道。如果订阅了命名空间中尚未安装的软件包，则会安装该软件包的最新 Operator。
OLM 会刻意避免版本比较，因此给定 catalog
每个 CSV 均有一个 replaces 参数，指明所替换的是哪个 Operator。这样便构建了一个可通过 OLM 查询的 CSV 图，且不同频道之间可共享更新。可将频道视为更新图表的入口点：
图 2.5. OLM 的可用频道更新图表
软件包中的频道示例
packageName: example channels: - name: alpha currentCSV: example.v0.1.2 - name: beta currentCSV: example.v0.1.3 defaultChannel: alpha
为了让 OLM 成功查询更新、给定一个目录源、软件包、频道和 CSV，目录必须能够明确无误地返回替换输入 CSV 的单个 CSV。
2.4.3.1.1. 升级路径示例
对于示例升级场景，假设安装的 Operator 对应于 0.1.1 版 CSV。OLM 查询目录源，并在订阅的频道中检测升级，新的 0.1.3 版 CSV 替换了旧的但未安装的 0.1.2 版 CSV，后者又取代了较早且已安装的 0.1.1 版 CSV。
OLM 通过 CSV 中指定的 replaces 字段从频道头倒退至之前的版本，以确定升级路径为 0.1.3 0.1.2 0.1.1，其中箭头代表前者取代后者。OLM 一次仅升级一个 Operator 版本，直至到达频道头。
对于该给定场景，OLM 会安装 0.1.2 版 Operator 来取代现有的 0.1.1 版 Operator。然后再安装 0.1.3 版 Operator 来取代之前安装的 0.1.2 版 Operator。至此，所安装的 0.1.3 版 Operator 与频道头相匹配，意味着升级已完成。
2.4.3.1.2. 跳过升级
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
考虑以下 Old CatalogSource 和 New CatalogSource 示例。
图 2.6. 跳过更新
该图表明：
- Old CatalogSource 中的任何 Operator 在 New CatalogSource 中均有单一替换项。
- New CatalogSource 中的任何 Operator 在 New CatalogSource 中均有单一替换项。
- 如果未曾安装不良更新，将来也绝不会安装。
2.4.3.1.3. 替换多个 Operator
按照描述创建 New CatalogSource 需要发布 CSV 来替换单个 Operator，但可跳过多个。该操作可通过 skipRange 注解来完成：
olm.skipRange: <semver_range>
其中 <semver_range> 具有 semver library 所支持的版本范围格式。
当在目录中搜索更新时，如果某个频道头提供一个 skipRange 注解，且当前安装的 Operator 的版本字段在该范围内，则 OLM 会更新至该频道中的最新条目。
先后顺序：
-
Subscription 上由
sourceName指定的源中的频道头（满足其他跳过条件的情况下）。 -
在
sourceName指定的源中替换当前 Operator 的下一 Operator。 - 对 Subscription 可见的另一个源中的频道头（满足其他跳过条件的情况下）。
- 在对 Subscription 可见的任何源中替换当前 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'
2.4.3.1.4. Z-stream 支持
对于相同从版本，z-stream 或补丁版本必须取代所有先前 z-stream 版本。OLM 不考虑主版本、次版本或补丁版本，只需要在目录中构建正确的图表。
换句话说，OLM 必须能够像在 Old CatalogSource 中一样获取一个图表，像在 New CatalogSource 中一样生成一个图表：
图 2.7. 替换多个 Operator
该图表明：
- Old CatalogSource 中的任何 Operator 在 New CatalogSource 中均有单一替换项。
- New CatalogSource 中的任何 Operator 在 New CatalogSource 中均有单一替换项。
- Old CatalogSource 中的所有 z-stream 版本均会更新至 New CatalogSource 中最新 z-stream 版本。
- 不可用版本可被视为“虚拟”图表节点；它们的内容无需存在，注册表只需像图表看上去这样响应即可。
