第 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 YAML 和 Search 页面)在 web 控制台中创建和查看相关对象。但是,现有的 OperatorHub 和 Installed 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 Controller 和 Catalogd。
- 改进了对扩展更新的控制
- 通过改进对目录内容的了解,管理员可以指定用于安装和更新的目标版本。这样,管理员可以更好地控制扩展更新的目标版本。如需更多信息,请参阅更新集群扩展。
- 灵活的扩展打包格式
管理员可以使用基于文件的目录来安装和管理扩展,如基于 OLM 的 Operator,与 OLM (Classic) 经验类似。
另外,捆绑包大小不再受 etcd 值大小限制。如需更多信息,请参阅安装扩展。
- 安全目录通信
- OLM v1 使用 HTTPS 加密进行目录服务器响应。
- 代理环境和可信 CA 证书的基本支持
- Operator Controller 和 catalogd 可以在代理环境中运行,并包括对可信 CA 证书的基本支持。