扩展概述 | 扩展 | OpenShift Container Platform 4.17

重点
目的

运算符生命周期管理器 (OLM) v1 仅为技术预览功能。技术预览功能不受 Red Hat 生产服务级别协议 (SLA) 的支持，并且可能功能不完整。Red Hat 不建议在生产环境中使用它们。这些功能可让客户提前访问即将推出的产品功能，从而能够在开发过程中测试功能并提供反馈。

有关 Red Hat 技术预览功能的支持范围的更多信息，请参阅技术预览功能支持范围。

扩展允许集群管理员为 OpenShift Container Platform 集群上的用户扩展功能。

从最初发布以来，运算符生命周期管理器 (OLM) 就已包含在 OpenShift Container Platform 4 中。OpenShift Container Platform 4.17 包含下一代 OLM 迭代的组件，作为一项正式可用 (GA) 功能，在此阶段称为 *OLM v1*。此更新的框架发展了先前 OLM 版本中包含的许多概念，并增加了新功能。

重点

管理员可以探索以下重点内容

完全声明式模型，支持 GitOps 工作流程

OLM v1 通过两个关键 API 简化了扩展管理

新的 `ClusterExtension` API 通过将面向用户的 API 整合到单个对象中，简化了已安装扩展（包括通过 `registry+v1` 包格式的运算符）的管理。此 API 由新的运算符控制器组件提供，为 `clusterextension.olm.operatorframework.io`。管理员和 SRE 可以使用此 API 自动化流程并使用 GitOps 原则定义所需状态。

OLM v1 早期技术预览版引入了新的Operator API；在 OpenShift Container Platform 4.16 中，此 API 已重命名为ClusterExtension，以实现以下改进

更准确地反映了扩展集群功能的简化功能
更好地体现了更灵活的打包格式
Cluster 前缀明确指示ClusterExtension 对象是集群范围的，这与现有的 OLM 不同，在现有的 OLM 中，Operator 可以是命名空间范围的或集群范围的

新的 catalogd 组件提供的Catalog API 是 OLM v1 的基础，它为集群内客户端解包目录，以便用户可以发现可安装的内容，例如 Kubernetes 扩展和 Operator。这提高了对所有可用 Operator bundle 版本的可见性，包括其详细信息、渠道和更新边缘。

目前，Operator Lifecycle Manager (OLM) v1 无法验证私有注册表，例如 Red Hat 提供的 Operator 目录。这是一个已知问题。因此，依赖于已安装 Red Hat Operators 目录的 OLM v1 过程无法正常工作。（OCPBUGS-36364)

更多信息，请参见 Operator Controller 和 Catalogd。

改进的扩展更新控制

通过改进对目录内容的洞察，管理员可以指定安装和更新的目标版本。这使管理员能够更好地控制扩展更新的目标版本。更多信息，请参见更新集群扩展。

灵活的扩展打包格式

管理员可以使用基于文件的目录来安装和管理扩展，例如基于 OLM 的 Operator，类似于现有的 OLM 体验。

此外，bundle 大小不再受 etcd 值大小限制的约束。更多信息，请参见安装扩展。

安全的目录通信

OLM v1 使用 HTTPS 加密 catalogd 服务器响应。

目的

Operator Lifecycle Manager (OLM) 的使命是在 Kubernetes 集群上集中式和声明式地管理集群扩展的生命周期。其目的始终是使集群和平台即服务 (PaaS) 管理员在底层集群的整个生命周期中轻松、安全和可重复地安装、运行和更新集群的功能扩展。

OLM 的初始版本随 OpenShift Container Platform 4 一起发布，并默认包含在内，专注于为特定类型的集群扩展（称为 Operator）提供独特的支持。Operator 分类为一个或多个 Kubernetes 控制器，包含一个或多个 API 扩展，作为CustomResourceDefinition (CRD) 对象，以向集群提供附加功能。

在生产集群中运行了多个版本之后，下一代 OLM 旨在涵盖不仅仅是 Operator 的集群扩展的生命周期。