第 1 章 扩展概述


扩展可让集群管理员在其 OpenShift Container Platform 集群上为用户扩展功能。

自 OpenShift Container Platform 4 初始发行以来,Operator Lifecycle Manager (OLM) 已包含在 OpenShift Container Platform 4 中。OpenShift Container Platform 4.19 包括了一个面向下一代 OLM 操作的组件,作为正式发行 (GA)功能,在此阶段被称为 OLM v1。此更新的框架改变了很多属于以前版本的 OLM 的概念,并添加了新功能。

注意

对于 OpenShift Container Platform 4.19,记录了 OLM v1 的步骤仅基于 CLI。另外,管理员也可以使用普通方法(如 Import YAMLSearch 页面)在 web 控制台中创建和查看相关对象。但是,现有的 OperatorHubInstalled Operators 页还不会显示 OLM v1 组件。

1.1. 亮点

管理员可以探索以下亮点:

支持 GitOps 工作流的全声明性模型

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

  • 新的 ClusterExtension API 简化了已安装的扩展的管理,其中包括通过 registry+v1 捆绑包格式的 Operator,通过将面向用户的 API 整合到单个对象中。此 API 由新的 Operator Controller 组件作为 clusterextension.olm.operatorframework.io 提供。管理员和 SRE 可使用 API 自动进程并使用 GitOps 原则定义所需状态。

    注意

    OLM v1 的早期技术预览阶段引入了一个新的 Operator API;此 API 在 OpenShift Container Platform 4.16 中被重命名为 ClusterExtension,以解决以下改进:

    • 更准确地反映了扩展集群功能的简化功能
    • 准确地代表了一个更灵活的打包格式
    • Cluster 前缀明确表示 ClusterExtension 对象是集群范围的。这与 OLM (Classic) 不同,其中 Operator 可以是命名空间范围的或集群范围的
  • Catalog API 由新 catalogd 组件提供,作为 OLM v1 的基础,为 on-cluster 客户端解包目录,以便用户可以发现可安装的内容,如 Kubernetes 扩展和 Operator。这可让您提高所有可用 Operator 捆绑包版本的可见性,包括它们的详情、频道和更新边缘。

如需更多信息,请参阅 Operator ControllerCatalogd

改进了对扩展更新的控制
通过改进对目录内容的了解,管理员可以指定用于安装和更新的目标版本。这样,管理员可以更好地控制扩展更新的目标版本。如需更多信息,请参阅更新集群扩展
灵活的扩展打包格式

管理员可以使用基于文件的目录来安装和管理扩展,如基于 OLM 的 Operator,与 OLM (Classic) 经验类似。

另外,捆绑包大小不再受 etcd 值大小限制。如需更多信息,请参阅安装扩展

安全目录通信
OLM v1 使用 HTTPS 加密进行目录服务器响应。
代理环境和可信 CA 证书的基本支持
Operator Controller 和 catalogd 可以在代理环境中运行,并包括对可信 CA 证书的基本支持。
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat