第 2 章 了解 Operator Lifecycle Manager (OLM)

对于示例升级场景，假设安装的 Operator 对应于 0.1.1 版 CSV。OLM 查询 CatalogSource，并在订阅的频道中检测升级包，新的 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 与频道头相匹配，意味着升级已完成。

OLM 的基本升级路径如下：

但有时这不是一种安全操作。某些情况下，已发布但尚未就绪的 Operator 版本不可安装至集群中，如版本中存在严重漏洞。

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

通过发送新目录并添加跳过的发行版本，可保证无论集群状态如何以及是否发现了不良更新，OLM 总能获得单个唯一更新。

例如：

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.5. 跳过更新

该图表明：

按照描述创建 New CatalogSource 需要发布 CSV 来替换单个 Operator，但可跳过多个。该操作可通过 skipRange 注解来完成：

olm.skipRange: <semver_range>

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

当在目录中搜索更新时，如果某个频道头提供一个 skipRange 注解，且当前安装的 Operator 的版本字段在该范围内，则 OLM 会更新至该频道中的最新条目。

先后顺序：

例如：

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-stream 或补丁版本必须取代所有先前 z-stream 版本。OLM 不关注主版本、从版本或补丁版本，只需要在目录中构建正确图表。

换句话说，OLM 必须能够像在 Old CatalogSource 中一样获取一个图表，像在 New CatalogSource 中一样生成一个图表：

图 2.6. 替换多个 Operator

该图表明：

集群中存在 CSV 中指定需要的资源后，OLM Operator 将负责部署由 CSV 资源定义的应用程序。

OLM Operator 不负责创建所需资源；用户可选择使用 CLI 手动创建这些资源，也可选择使用 Catalog Operator 来创建这些资源。这种关注点分离的机制可以使得用户逐渐增加他们选择用于其应用程序的 OLM 框架量。

虽然 OLM Operator 通常被配置为监视所有命名空间，但也可与其他 OLM Operator 一同使用，只要所管理的命名空间不同即可。

Catalog Operator 负责解析和安装 CSV 及其指定的所需资源。另外还负责监视频道中的 CatalogSource 中是否有软件包更新，并将其升级（可选择自动）至最新可用版本。

希望跟踪频道中软件包的用户可创建 Subscription 资源，该资源将配置所需软件包、频道和 CatalogSource，以便从中拉取更新。找到更新后，便会代表用户将适当 InstallPlan 写入命名空间。

用户也可直接创建 InstallPlan 资源，其中包含所需 CSV 和批准策略的名称，而 Catalog Operator 会为创建所有所需资源创建一个执行计划。批准后，Catalog Operator 将在 InstallPlan 中创建所有资源；然后单独满足 OLM Operator 的要求，从而继续安装 CSV。

Catalog Registry 存储 CSV 和 CRD 以便在集群中创建，并存储有关软件包和频道的元数据。

package manifest 是 Catalog Registry 中的一个条目，用于将软件包标识与 CSV 集相关联。在软件包中，频道指向特定 CSV。因为 CSV 明确引用了所替换的 CSV，软件包清单向 Catalog Operator 提供了将 CSV 更新至频道中最新版本所需的信息，逐步安装和替换每个中间版本。