红帽全球峰会This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.Operator
在 OpenShift Container Platform 中使用 Operator
摘要
第 1 章 Operator 概述
Operator 是 OpenShift Container Platform 中最重要的组件。Operator 是 control plane 上打包、部署和管理服务的首选方法。它们还可以为用户运行的应用程序提供优势。
Operator 与 Kubernetes API 和 CLI 工具（如 kubectl 和 oc 命令）集成。它们提供了监控应用程序、执行健康检查、管理无线(OTA)更新的方法，并确保应用程序保持在指定的状态。
虽然这两个操作都遵循类似的 Operator 概念和目标，但 OpenShift Container Platform 中的 Operator 由两个不同的系统管理，具体取决于其用途：
- 由 Cluster Version Operator(CVO)管理的 Cluster Operator 被默认安装来执行集群功能。
- 可选的附加组件 Operator 由 Operator Lifecycle Manager(OLM)管理，供用户在其应用程序中运行。
使用 Operator，您可以创建应用程序来监控集群中运行的服务。Operator 是专为您的应用程序而设计的。Operator 实施并自动执行常见的第 1 天操作，如安装和配置以及第 2 天操作，如自动缩放和缩减并创建备份。所有这些活动均位于集群中运行的一个软件中。
1.1. 对于开发人员
作为开发人员，您可以执行以下 Operator 任务：
1.2. 对于管理员
作为集群管理员，您可以执行以下 Operator 任务：
要了解红帽提供的集群 Operator 的信息，请参阅 Cluster Operators 参考。
1.3. 后续步骤
要了解更多有关 Operator 的信息，请参阅 Operator 是什么？
第 2 章 了解 Operator
2.1. 什么是 Operator?
从概念上讲，Operator 会收集人类操作知识，并将其编码成更容易分享给消费者的软件。
Operator 是一组软件，可用于降低运行其他软件的操作复杂程度。它可以被看作是软件厂商的工程团队的扩展，可以在 Kubernetes 环境中（如 OpenShift Container Platform）监控软件的运行情况，并根据软件的当前状态实时做出决策。Advanced Operator 被设计为用来无缝地处理升级过程，并对出现的错误自动进行响应，而且不会采取“捷径”（如跳过软件备份过程来节省时间）。
从技术上讲，Operator 是一种打包、部署和管理 Kubernetes 应用程序的方法。
Kubernetes 应用程序是一款 app，可在 Kubernetes 上部署，也可使用 Kubernetes API 和 kubectl 或 oc 工具进行管理。要想充分利用 Kubernetes，您需要一组统一的 API 进行扩展，以便服务和管理 Kubernetes 上运行的应用程序。可将 Operator 看成管理 Kubernetes 中这类应用程序的运行时。
2.1.1. 为什么要使用 Operator？
Operator 可以：
- 重复安装和升级。
- 持续对每个系统组件执行运行状况检查。
- 无线 (OTA) 更新 OpenShift 组件和 ISV 内容。
- 汇总现场工程师了解的情况并将其传输给所有用户，而非一两个用户。
- 为什么在 Kubernetes 上部署？
- Kubernetes（通过扩展），OpenShift Container Platform 包含构建复杂分布式系统所需的所有原语 - secret 处理、负载均衡、服务发现、自动扩展 - 在内部和云供应商中工作。
- 为什么使用 Kubernetes API 和
kubectl工具来管理您的应用程序？ -
这些 API 功能丰富，所有平台均有对应的客户端，并可插入到集群的访问控制/审核中。Operator 会使用 Kubernetes 的扩展机制“自定义资源定义 (CRD)”支持您的自定义对象，如
MongoDB，它类似于内置的原生 Kubernetes 对象。 - Operator 与 Service Broker 的比较？
- 服务代理（service broker）是实现应用程序的编程发现和部署的一个步骤。但它并非一个长时间运行的进程，所以无法执行第 2 天操作，如升级、故障转移或扩展。它在安装时提供对可调参数的自定义和参数化，而 Operator 则可持续监控集群的当前状态。非集群服务仍非常适合于 Service Broker，但也存在合适于这些服务的 Operator。
2.1.2. Operator Framework
Operator Framework 是基于上述客户体验提供的一系列工具和功能。不仅仅是编写代码；测试、交付和更新 Operator 也同样重要。Operator Framework 组件包含用于解决这些问题的开源工具：
- Operator SDK
- Operator SDK 辅助 Operator 作者根据自身专业知识，引导、构建、测试和包装其 Operator，而无需了解 Kubernetes API 的复杂性。
- Operator Lifecycle Manager
- Operator Lifecycle Manager (OLM) 能够控制集群中 Operator 的安装、升级和基于角色的访问控制 (RBAC)。在 OpenShift Container Platform 4.7 中默认部署。
- Operator Registry
- Operator Registry 存储 ClusterServiceVersions (CSV) 和自定义资源定义 (CRD) 以便在集群中创建，并存储有关软件包和频道的 Operator 元数据。它运行在 Kubernetes 或 OpenShift 集群中，向 OLM 提供这些 Operator 目录数据。
- OperatorHub
- OperatorHub 是一个 web 控制台，供集群管理员用来发现并选择要在其集群上安装的 Operator。它在 OpenShift Container Platform 中默认部署。
这些工具可组合使用，因此您可自由选择对您有用的工具。
2.1.3. Operator 成熟度模型
Operator 内部封装的管理逻辑的复杂程度各有不同。该逻辑通常还高度依赖于 Operator 所代表的服务类型。
对于大部分 Operator 可能包含的特定功能集来说，可以大致推断出 Operator 封装操作的成熟度等级。就此而言，以下 Operator 成熟度模型针对 Operator 的第 2 天通用操作定义了五个成熟度阶段。
图 2.1. Operator 成熟度模型
以上模型还显示了如何通过 Operator SDK 的 Helm、Go 和 Ansible 功能更好地开发这些功能。
2.2. Operator Framework 打包格式
本指南概述了 OpenShift Container Platform 中 Operator Lifecycle Manager (OLM) 所支持的 Operator 打包格式。
2.2.1. Bundle Format
Operator 的 Bundle Format 是 Operator Framework 引入的新打包格式。为提高可伸缩性并为自行托管目录的上游用户提供更好地支持，Bundle Format 规格简化了 Operator 元数据的发布。
Operator 捆绑包代表 Operator 的单一版本。磁盘上的捆绑包清单是容器化的，并作为捆绑包镜像提供，该镜像是一个不可运行的容器镜像，其中存储了 Kubernetes 清单和 Operator 元数据。然后，使用现有容器工具（如 podman 和 docker）和容器 registry（如 Quay）来管理捆绑包镜像的存储和发布。
Operator 元数据可以包括：
- 标识 Operator 的信息，如名称和版本。
- 驱动 UI 的额外信息，例如其图标和一些示例自定义资源 (CR)。
- 所需的和所提供的 API。
- 相关镜像。
将清单加载到 Operator Registry 数据库中时，会验证以下要求：
- 该捆绑包必须在注解中至少定义一个频道。
- 每个捆绑包都只有一个集群服务版本（CSV）。
- 如果 CSV 拥有自定义资源定义（CRD），则该 CRD 必须存在于捆绑包中。
2.2.1.1. 清单
捆绑包清单指的是一组 Kubernetes 清单，用于定义 Operator 的部署和 RBAC 模型。
捆绑包包括每个目录的一个 CSV，一般情况下，用来定义 CRD 所拥有的 API 的 CRD 位于 /manifest 目录中。
Bundle Format 布局示例
额外支持的对象
以下对象类型也可以包括在捆绑包的 /manifests 目录中：
支持的可选对象类型
-
ClusterRole -
ClusterRoleBinding -
ConfigMap -
ConsoleYamlSample -
PodDisruptionBudget -
PriorityClass -
PrometheusRule -
角色 -
RoleBinding -
Secret -
服务 -
ServiceAccount -
ServiceMonitor -
VerticalPodAutoscaler
当捆绑包中包含这些可选对象时，Operator Lifecycle Manager（OLM）可以从捆绑包创建对象，并随 CSV 一起管理其生命周期：
可选对象的生命周期
- 删除 CSV 后，OLM 会删除可选对象。
当 CSV 被升级时：
- 如果可选对象的名称相同，OLM 会更新它。
- 如果可选对象的名称在版本间有所变化，OLM 会删除并重新创建它。
2.2.1.2. 注解
捆绑包还在其 /metadata 文件夹中包含 annotations.yaml 文件。此文件定义了更高级别的聚合数据，以帮助描述有关如何将捆绑包添加到捆绑包索引中的格式和软件包信息：
annotations.yaml 示例
- 1
- Operator 捆绑包的介质类型或格式。
registry+v1格式表示它包含 CSV 及其关联的 Kubernetes 对象。 - 2
- 镜像中的该路径指向含有 Operator 清单的目录。该标签保留给以后使用，当前默认为
manifests/。manifests.v1值表示捆绑包包含 Operator 清单。 - 3
- 镜像中的该路径指向包含捆绑包元数据文件的目录。该标签保留给以后使用，当前默认为
metadata/。metadata.v1值表示这个捆绑包包含 Operator 元数据。 - 4
- 捆绑包的软件包名称。
- 5
- 捆绑包添加到 Operator Registry 时订阅的频道列表。
- 6
- 从 registry 安装时，Operator 应该订阅到的默认频道。
如果出现不匹配的情况，则以 annotations.yaml 文件为准，因为依赖这些注解的集群 Operator Registry 只能访问此文件。
2.2.1.3. 依赖项文件
Operator 的依赖项列在捆绑包的 metadata/ 目录中的 dependencies.yaml 文件中。此文件是可选的，目前仅用于指明 Operator-version 依赖项。
依赖项列表中，每个项目包含一个 type 字段，用于指定这一依赖项的类型。受支持的 Operator 依赖项有两种：
-
olm.package：此类型表示特定 Operator 版本的依赖项。依赖项信息必须包含软件包名称以及软件包的版本，格式为 semver。例如，您可以指定具体版本，如0.5.2，也可指定一系列版本，如>0.5.1。 -
olm.gvk：使用gvk类型，作者可以使用 group/version/kind（GVK）信息指定依赖项，类似于 CSV 中现有 CRD 和基于 API 的使用。该路径使 Operator 作者可以合并所有依赖项、API 或显式版本，使它们处于同一位置。
在以下示例中，为 Prometheus Operator 和 etcd CRD 指定依赖项：
dependencies.yaml 文件示例
2.2.1.4. 关于 opm
opm CLI 工具由 Operator Framework 提供，用于 Operator Bundle Format。您可以通过一个名为 index 的捆绑包列表创建和维护 Operator 目录，类似于软件存储库。其结果是一个名为 index image（索引镜像） 的容器镜像，它可以存储在容器的 registry 中，然后安装到集群中。
索引包含一个指向 Operator 清单内容的指针数据库，可通过在运行容器镜像时提供的已包含 API 进行查询。在 OpenShift Container Platform 中，Operator Lifecycle Manager（OLM）可通过在 CatalogSource 中引用索引镜像来使它作为目录一个（catalog），它会定期轮询镜像，以对集群上安装的 Operator 进行更新。
-
有关安装
opmCLI 的步骤，请参阅 CLI 工具。
2.2.2. Package Manifest Format
Operator 的 Package Manifest Format 是 Operator Framework 中原先引入的旧版打包格式。虽然 OpenShift Container Platform 4.5 中已弃用此格式，但它仍受支持，红帽提供的 Operator 目前仍使用此方法提供。
在这个格式中，Operator 的版本由单个集群服务版本（CSV）代表，自定义资源定义（CRD）用来定义 CSV 所拥有的 API，另外也可能包含其他对象。
Operator 的所有版本都嵌套到单个目录中：
Package Manifest Format 布局示例
它还包含一个 <name>.package.yaml 文件，它是定义软件包名称和频道详情的软件包清单：
软件包清单示例
将软件包清单加载到 Operator Registry 数据库中时，会验证以下要求：
- 每个软件包至少有一个频道。
- 软件包中频道指向的每个 CSV 都存在。
- Operator 的每个版本都只有一个 CSV。
- 如果 CSV 拥有 CRD，则该 CRD 必须存在于 Operator 版本的目录中。
- 如果 CSV 替换了另一个 CSV，则软件包中必须同时存在旧的和新的 CSV。
2.3. Operator Framework 常用术语表
本主题提供了与 Operator Framework 相关的常用术语表，其中包括 Operator Lifecycle Manager (OLM) 和 Operator SDK，适用于两种打包格式： Package Manifest Format 和 Bundle Format。
2.3.1. 常见 Operator Framework 术语
2.3.1.1. 捆绑包（Bundle）
在 Bundle Format 中，捆绑包是 Operator CSV、清单和元数据的集合。它们一起构成了可在集群中安装的 Operator 的唯一版本。
2.3.1.2. 捆绑包镜像
在 Bundle Format 中， 捆绑包镜像是一个从 Operator 清单中构建的容器镜像，其中包含一个捆绑包。捆绑包镜像由 Open Container Initiative (OCI) spec 容器 registry 存储和发布，如 Quay.io 或 DockerHub。
2.3.1.3. 目录源
目录源（catalog source） 是定义应用程序的 CSV、CRD 和软件包的仓库。
2.3.1.4. 目录镜像
在 Package Manifest Format 中， 目录镜像是一个容器化数据存储，用于描述一组可使用 OLM 在集群中安装的 Operator 元数据和更新元数据。
2.3.1.5. 频道
频道为 Operator 定义更新流，用于为订阅者推出更新。频道头指向该频道的最新版本。例如，stable 频道中会包含 Operator 的所有稳定版本，按由旧到新的顺序排列。
Operator 可以有几个频道，与特定频道绑定的订阅只会在该频道中查找更新。
2.3.1.6. 频道头
频道头是指特定频道中最新已知的更新。
2.3.1.7. 集群服务版本
集群服务版本（cluster service version，简称 CSV 是一个利用 Operator 元数据创建的 YAML 清单，可辅助 OLM 在集群中运行 Operator。它是 Operator 容器镜像附带的元数据，用于在用户界面填充徽标、描述和版本等信息。
此外，CSV 还是运行 Operator 所需的技术信息来源，类似于其需要的 RBAC 规则及其管理或依赖的自定义资源 (CR)。
2.3.1.8. 依赖项
Operator 可能会依赖于集群中存在的另一个 Operator。例如，Vault Operator 依赖于 etcd Operator 的数据持久性层。
OLM 通过确保在安装过程中在集群中安装 Operator 和 CRD 的所有指定版本来解决依赖关系。通过在目录中查找并安装满足所需 CRD API 且与软件包或捆绑包不相关的 Operator，解决这个依赖关系。
2.3.1.9. 索引镜像
在 Bundle Format 中， 索引镜像是一种数据库（数据库快照）镜像，其中包含关于 Operator 捆绑包（包括所有版本的 CSV 和 CRD）的信息。此索引可以托管集群中 Operator 的历史记录，并可使用 opm CLI 工具添加或删除 Operator 来加以维护。
2.3.1.10. 安装计划
安装计划（install plan）是一个列出了为自动安装或升级 CSV 而需创建的资源的计算列表。
2.3.1.11. operator 组
Operator 组将部署在同一命名空间中的所有 Operator 配置为 OperatorGroup 对象，以便在一系列命名空间或集群范围内监视其 CR。
2.3.1.12. 软件包
在 Bundle Format 中，软件包是一个目录，其中包含每个版本的 Operator 的发布历史记录。CSV 清单中描述了发布的 Operator 版本和 CRD。
2.3.1.13. 容器镜像仓库（Registry）
Registry 是一个存储了 Operator 捆绑包镜像的数据库，每个都包含所有频道的最新和历史版本。
2.3.1.14. Subscription
订阅（subscription） 通过跟踪软件包中的频道来保持 CSV 最新。
2.3.1.15. 更新图表
更新图表将 CSV 的版本关联到一起，与其他打包软件的更新图表类似。可以依次安装 Operator，也可以跳过某些版本。只有在添加新版本时，更新图表才会在频道头上扩大。
2.4. Operator Lifecycle Manager (OLM)
2.4.1. Operator Lifecycle Manager 概念和资源
本指南概述了 OpenShift Container Platform 中 Operator Lifecycle Manager (OLM) 背后的概念。
2.4.1.1. Operator Lifecycle Manager 是什么？
Operator Lifecycle Manager（OLM）可帮助用户安装、更新和管理所有 Kubernetes 原生应用程序（Operator）以及在 OpenShift Container Platform 集群中运行的关联服务的生命周期。它是 Operator Framework 的一部分，后者是一个开源工具包，用于以有效、自动化且可扩展的方式管理 Operator。
图 2.2. Operator Lifecycle Manager 工作流
OLM 默认在 OpenShift Container Platform 4.7 中运行，辅助集群管理员对集群上运行的 Operator 进行安装、升级和授予访问权。OpenShift Container Platform Web 控制台提供一些管理界面，供集群管理员安装 Operator，以及为特定项目授权以便使用集群上的可用 Operator 目录。
开发人员通过自助服务体验，无需成为相关问题的专家也可自由置备和配置数据库、监控和大数据服务的实例，因为 Operator 已将相关知识融入其中。
2.4.1.2. OLM 资源
以下自定义资源定义 (CRD) 由 Operator Lifecycle Manager (OLM) 定义和管理：
| 资源 | 短名称 | 描述 |
|---|---|---|
|
|
| 应用程序元数据。例如：名称、版本、图标、所需资源。 |
|
|
| 定义应用程序的 CSV、CRD 和软件包存储库。 |
|
|
| 通过跟踪软件包中的频道来保持 CSV 最新 |
|
|
| 为自动安装或升级 CSV 而需创建的资源的计算列表。 |
|
|
|
将部署在同一命名空间中的所有 Operator 配置为 |
|
| - |
在 OLM 和它管理的 Operator 之间创建通信频道。操作员可以写入 |
2.4.1.2.1. 集群服务版本
集群服务版本 (CSV) 代表 OpenShift Container Platform 集群中运行的 Operator 的特定版本。它是一个利用 Operator 元数据创建的 YAML 清单，可辅助 Operator Lifecycle Manager (OLM) 在集群中运行 Operator。
OLM 需要与 Operator 相关的元数据，以确保它可以在集群中安全运行，并在发布新版 Operator 时提供有关如何应用更新的信息。这和传统的操作系统的打包软件相似；可将 OLM 的打包步骤认为是制作 rpm、deb 或 apk 捆绑包的阶段。
CSV 中包含 Operator 容器镜像附带的元数据，用于在用户界面填充名称、版本、描述、标签、存储库链接和徽标等信息。
此外，CSV 还是运行 Operator 所需的技术信息来源，例如其管理或依赖的自定义资源 (CR)、RBAC 规则、集群要求和安装策略。此信息告诉 OLM 如何创建所需资源并将 Operator 设置为部署。
2.4.1.2.2. 目录源
catalog source 代表元数据存储，通常通过引用存储在容器 registry 中的 index image。Operator Lifecycle Manager (OLM) 查询目录源来发现和安装 Operator 及其依赖项。OpenShift Container Platform Web 控制台中的 OperatorHub 也会显示由目录源提供的 Operator。
集群管理员可以使用 web 控制台中的 Administration → Cluster Settings → Global Configuration → OperatorHub 页面查看集群中已启用的目录源提供的 Operator 的完整列表。
CatalogSource 的 spec 指明了如何构造 pod，以及如何与服务于 Operator Registry gRPC API 的服务进行通信。
例 2.1. CatalogSource 对象示例
- 1
CatalogSource对象的名称。此值也用作在请求的命名空间中创建相关 pod 的名称的一部分。- 2
- 创建可用目录的命名空间。要使目录在所有命名空间中都可用，请将此值设置为
openshift-marketplace。默认红帽提供的目录源也使用openshift-marketplace命名空间。否则，将值设置为特定命名空间，使 Operator 仅在该命名空间中可用。 - 3
- 在 Web 控制台和 CLI 中显示目录的名称。
- 4
- 目录的索引镜像。
- 5
- 目录源的权重。OLM 在依赖项解析过程中使用权重进行优先级排序。权重越高，表示目录优先于轻量级目录。
- 6
- 源类型包括以下内容：
-
带有
镜像引用的grpc：OLM 拉取镜像并运行 pod，为兼容的 API 服务。 -
带有
地址字段的grpc：OLM 会尝试联系给定地址的 gRPC API。在大多数情况下不应该使用这种类型。 -
configmap：OLM 解析配置映射数据，并运行一个可以为其提供 gRPC API 的 pod。
-
带有
- 7
- 在指定的时间段内自动检查新版本以保持最新。
- 8
- 目录连接的最后观察到状态。例如：
-
READY：成功建立连接。 -
CONNECTING：连接正在尝试建立。 -
TRANSIENT_FAILURE：尝试建立连接（如超时）时发生了临时问题。该状态最终将切回到CONNECTING，然后重试。
如需了解更多详细信息，请参阅 gRPC 文档中的连接状态。
-
- 9
- 存储目录镜像的容器注册表最近轮询的时间，以确保镜像为最新版本。
- 10
- 目录的 Operator Registry 服务的状态信息。
在订阅中引用 CatalogSource 对象的名称会指示 OLM 搜索查找请求的 Operator 的位置：
例 2.2. 引用目录源的 Subscription 对象示例
2.4.1.2.3. 订阅
订阅 （由一个 Subscription 对象定义）代表安装 Operator 的意图。它是将 Operator 与目录源关联的自定义资源。
Subscription 描述了要订阅 Operator 软件包的哪个频道，以及是自动还是手动执行更新。如果设置为自动，订阅可确保 Operator Lifecycle Manager（OLM）自动管理并升级 Operator，以确保集群中始终运行最新版本。
Subscription 对象示例
此 Subscription 对象定义了 Operator 的名称和命名空间，以及从中查找 Operator 数据的目录。频道（如 alpha、beta 或 stable ）可帮助确定应从目录源安装哪些 Operator 流。
订阅中的频道名称可能会因 Operator 而异，但应遵守给定 Operator 中的常规约定。例如，频道名称可能会遵循 Operator 提供的应用程序的次发行版本更新流（1.2、1.3）或发行的频率（stable、fast）。
除了可从 OpenShift Container Platform Web 控制台轻松查看外，还可以通过检查相关订阅的状态来识别是否有较新版本的 Operator 可用。与 currentCSV 字段关联的值是 OLM 已知的最新版本，而 installedCSV 是集群中安装的版本。
2.4.1.2.4. 安装计划
安装计划（由一个 InstallPlan 对象定义） 描述了 Operator Lifecycle Manager (OLM) 为安装或升级到 Operator 的特定版本而创建的一组资源。该版本由集群服务版本 (CSV) 定义。
要安装 Operator、集群管理员或被授予 Operator 安装权限的用户，必须首先创建一个 Subscription 对象。订阅代表了从目录源订阅 Operator 可用版本流的意图。然后，订阅会创建一个 InstallPlan 对象来方便为 Operator 安装资源。
然后，根据以下批准策略之一批准安装计划：
-
如果订阅的
spec.installPlanApproval字段被设置为Automatic，则会自动批准安装计划。 -
如果订阅的
spec.installPlanApproval字段被设置为Manual，则安装计划必须由集群管理员或具有适当权限的用户手动批准。
批准安装计划后，OLM 会创建指定的资源，并在订阅指定的命名空间中安装 Operator。
例 2.3. InstallPlan 对象示例
2.4.1.2.5. operator 组
由 OperatorGroup 资源定义的 Operator 组，为 OLM 安装的 Operator 提供多租户配置。Operator 组选择目标命名空间，在其中为其成员 Operator 生成所需的 RBAC 访问权限。
这一组目标命名空间通过存储在 CSV 的 olm.targetNamespaces 注解中的以逗号分隔的字符串来提供。该注解应用于成员 Operator 的 CSV 实例，并注入它们的部署中。
2.4.1.2.6. Operator 条件
作为管理 Operator 生命周期的角色的一部分，Operator Lifecycle Manager（OLM）从定义 Operator 的 Kubernetes 资源状态中推断 Operator 状态。虽然此方法提供了一定程度的保证来确定 Operator 处于给定状态，但在有些情况下，Operator 可能需要直接向 OLM 提供信息，而这些信息不能被推断出来。这些信息可以被 OLM 使用来更好地管理 Operator 的生命周期。
OLM 提供了一个名为 OperatorCondition 的自定义资源定义（CRD），它允许 Operator 与 OLM 相互通信条件信息。当在一个 OperatorCondition 资源的 Status.Conditions 数组中存在时，则代表存在一组会影响 OLM 管理 Operator 的支持条件。
2.4.2. Operator Lifecycle Manager 架构
本指南概述了 OpenShift Container Platform 中 Operator Lifecycle Manager (OLM) 的组件架构。
2.4.2.1. 组件职责
Operator Lifecycle Manager (OLM) 由两个 Operator 组成，分别为：OLM Operator 和 Catalog Operator。
每个 Operator 均负责管理 CRD，而 CRD 是 OLM 的框架基础：
| 资源 | 短名称 | 所有者 | 描述 |
|---|---|---|---|
|
|
| OLM | 应用程序元数据：名称、版本、图标、所需资源、安装等。 |
|
|
| Catalog | 为自动安装或升级 CSV 而需创建的资源的计算列表。 |
|
|
| Catalog | 定义应用程序的 CSV、CRD 和软件包存储库。 |
|
|
| Catalog | 用于通过跟踪软件包中的频道来保持 CSV 最新。 |
|
|
| OLM |
将部署在同一命名空间中的所有 Operator 配置为 |
每个 Operator 还负责创建以下资源：
| 资源 | 所有者 |
|---|---|
|
| OLM |
|
| |
|
| |
|
| |
|
| Catalog |
|
|
2.4.2.2. OLM Operator
集群中存在 CSV 中指定需要的资源后，OLM Operator 将负责部署由 CSV 资源定义的应用程序。
OLM Operator 不负责创建所需资源；用户可选择使用 CLI 手动创建这些资源，也可选择使用 Catalog Operator 来创建这些资源。这种关注点分离的机制可以使得用户逐渐增加他们选择用于其应用程序的 OLM 框架量。
OLM Operator 使用以下工作流：
- 观察命名空间中的集群服务版本（CSV），并检查是否满足要求。
如果满足要求，请运行 CSV 的安装策略。
注意CSV 必须是 Operator 组的活跃成员，才可运行该安装策略。
2.4.2.3. Catalog Operator
Catalog Operator 负责解析和安装集群服务版本（CSV）以及它们指定的所需资源。另外还负责监视频道中的目录源中是否有软件包更新，并将其升级（可选择自动）至最新可用版本。
要跟踪频道中的软件包，您可以创建一个 Subscription 对象来配置所需的软件包、频道和 CatalogSource 对象，以便拉取更新。在找到更新后，便会代表用户将一个适当的 InstallPlan 对象写入命名空间。
Catalog Operator 使用以下工作流：
- 连接到集群中的每个目录源。
监视是否有用户创建的未解析安装计划，如果有：
- 查找与请求名称相匹配的 CSV，并将此 CSC 添加为已解析的资源。
- 对于每个受管或所需 CRD，将其添加为已解析的资源。
- 对于每个所需 CRD，找到管理相应 CRD 的 CSV。
- 监视是否有已解析的安装计划并为其创建已发现的所有资源（用户批准或自动）。
- 观察目录源和订阅并根据它们创建安装计划。
2.4.2.4. Catalog Registry
Catalog Registry 存储 CSV 和 CRD 以便在集群中创建，并存储有关软件包和频道的元数据。
package manifest 是 Catalog Registry 中的一个条目，用于将软件包标识与 CSV 集相关联。在软件包中，频道指向特定 CSV。因为 CSV 明确引用了所替换的 CSV，软件包清单向 Catalog Operator 提供了将 CSV 更新至频道中最新版本所需的信息，逐步安装和替换每个中间版本。
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 → channel → package 路径提供的“latest”或“newest”Operator 不一定是最高版本号。更应将其视为频道的 head 引用，类似 Git 存储库。
每个 CSV 均有一个 replaces 参数，指明所替换的是哪个 Operator。这样便构建了一个可通过 OLM 查询的 CSV 图，且不同频道之间可共享更新。可将频道视为更新图表的入口点：
图 2.5. OLM 的可用频道更新图表
软件包中的频道示例
为了让 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 示例
考虑以下 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>
olm.skipRange: <semver_range>
其中 <semver_range> 具有 semver library 所支持的版本范围格式。
当在目录中搜索更新时，如果某个频道头提供一个 skipRange 注解，且当前安装的 Operator 的版本字段在该范围内，则 OLM 会更新至该频道中的最新条目。
先后顺序：
-
Subscription 上由
sourceName指定的源中的频道头（满足其他跳过条件的情况下）。 -
在
sourceName指定的源中替换当前 Operator 的下一 Operator。 - 对 Subscription 可见的另一个源中的频道头（满足其他跳过条件的情况下）。
- 在对 Subscription 可见的任何源中替换当前 Operator 的下一 Operator。
带有 skipRange 的 CSV 示例
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 版本。
- 不可用版本可被视为“虚拟”图表节点；它们的内容无需存在，注册表只需像图表看上去这样响应即可。
2.4.4. Operator Lifecycle Manager 依赖项解析
本指南概述了 OpenShift Container Platform 中 Operator Lifecycle Manager (OLM) 内的依赖项解析和自定义资源定义 (CRD) 升级生命周期。
2.4.4.1. 关于依赖项解析
OLM 管理运行 Operator 的依赖项解析和升级生命周期。在很多方面，OLM 的问题与其他操作系统软件包管理程序类似，比如 yum 和 rpm。
但其中有一个限制是相似系统一般不存在而 OLM 存在的，那就是：因为 Operator 始终在运行，所以 OLM 会努力确保您所接触的 Operator 组始终相互兼容。
这意味着 OLM 不得执行以下操作：
- 安装一组需要无法提供的 API 的 Operator。
- 更新某个 Operator 之时导致依赖该 Operator 的另一 Operator 中断。
2.4.4.2. 依赖项文件
Operator 的依赖项列在捆绑包的 metadata/ 目录中的 dependencies.yaml 文件中。此文件是可选的，目前仅用于指明 Operator-version 依赖项。
依赖项列表中，每个项目包含一个 type 字段，用于指定这一依赖项的类型。受支持的 Operator 依赖项有两种：
-
olm.package：此类型表示特定 Operator 版本的依赖项。依赖项信息必须包含软件包名称以及软件包的版本，格式为 semver。例如，您可以指定具体版本，如0.5.2，也可指定一系列版本，如>0.5.1。 -
olm.gvk：使用gvk类型，作者可以使用 group/version/kind（GVK）信息指定依赖项，类似于 CSV 中现有 CRD 和基于 API 的使用。该路径使 Operator 作者可以合并所有依赖项、API 或显式版本，使它们处于同一位置。
在以下示例中，为 Prometheus Operator 和 etcd CRD 指定依赖项：
dependencies.yaml 文件示例
2.4.4.3. 依赖项首选项
有很多选项同样可以满足 Operator 的依赖性。Operator Lifecycle Manager（OLM）中的依赖项解析器决定哪个选项最适合所请求 Operator 的要求。作为 Operator 作者或用户，了解这些选择非常重要，以便明确依赖项解析。
2.4.4.3.1. 目录优先级
在 OpenShift Container Platform 集群中，OLM 会读取目录源以了解哪些 Operator 可用于安装。
CatalogSource 对象示例
CatalogSource 有一个 priority 字段，解析器使用它来知道如何为依赖关系设置首选选项。
目录首选项有两个规则：
- 优先级较高目录中的选项优先于较低优先级目录的选项。
- 与依赖项相同的目录里的选项优先于其它目录。
2.4.4.3.2. 频道排序
目录中的 Operator 软件包是用户可在 OpenShift Container Platform 集群中订阅的更新频道集合。可使用频道为次发行版本（1.2, 1.3）或者发行的频率（stable, fast）提供特定的更新流。
同一软件包中的 Operator 可能会满足依赖项，但可能会在不同的频道。例如，Operator 版本 1.2 可能存在于 stable 和 fast 频道中。
每个软件包都有一个默认频道，该频道总是首选非默认频道。如果默认频道中没有选项可以满足依赖关系，则会在剩余的频道中按频道名称的字母顺序考虑这些选项。
2.4.4.3.3. 频道中的顺序
一般情况下，总会有多个选项来满足单一频道中的依赖关系。例如，一个软件包和频道中的 Operator 提供了相同的 API 集。
当用户创建订阅时，它们会指示要从哪个频道接收更新。这会立即把搜索范围限制在那个频道。但是在频道中，可以会有许多 Operator 可以满足依赖项。
在频道中，应该首选考虑使用更新图中位置较高的较新的 Operator。如果某个频道的头满足依赖关系，它将会被首先尝试。
2.4.4.3.4. 其他限制
除了软件包依赖关系的限制外，OLM 还添加了其他限制来代表所需用户状态和强制实施解析变量。
2.4.4.3.4.1. 订阅约束
一个订阅（Subscription）约束会过滤可满足订阅的 Operator 集合。订阅是对依赖项解析程序用户提供的限制。它们会声明安装一个新的 Operator（如果还没有在集群中安装），或对现有 Operator 进行更新。
2.4.4.3.4.2. 软件包约束
在命名空间中，不同的两个 Operator 不能来自于同一软件包。
2.4.4.4. CRD 升级
如果自定义资源定义（CRD）属于单一集群服务版本（CSV），OLM 会立即对其升级。如果某个 CRD 被多个 CSV 拥有，则当该 CRD 满足以下所有向后兼容条件时才会升级：
- 所有已存在于当前 CRD 中的服务版本都包括在新 CRD 中。
- 在根据新 CRD 的验证模式（schema）进行验证后，与 CRD 的服务版本关联的所有现有实例或自定义资源均有效。
2.4.4.5. 依赖项最佳实践
在指定依赖项时应该考虑的最佳实践。
- 依赖于 API 或 Operator 的特定版本范围
-
操作员可以随时添加或删除 API ; 始终针对 Operator 所需的任何 API 指定
olm.gvk依赖项。例外情况是，指定olm.package约束来替代。 - 设置最小版本
Kubernetes 文档中与 API 的改变相关的部分描述了 Kubernetes 风格的 Operator 允许进行哪些更改。只要 API 向后兼容，Operator 就允许 Operator 对 API 进行更新，而不需要更改 API 的版本。
对于 Operator 依赖项，这意味着了解依赖的 API 版本可能不足以确保依赖的 Operator 正常工作。
例如：
-
TestOperator v1.0.0 提供
MyObject资源的 v1alpha1 API 版本。 -
TestOperator v1.0.1 为
MyObject添加了一个新的spec.newfield字段，但仍是 v1alpha1。
您的 Operator 可能需要将
spec.newfield写入MyObject资源。仅使用olm.gvk约束还不足以让 OLM 决定您需要 TestOperator v1.0.1 而不是 TestOperator v1.0.0。如果事先知道提供 API 的特定 Operator，则指定额外的
olm.package约束来设置最小值。-
TestOperator v1.0.0 提供
- 省略一个最大版本，或允许一个广泛的范围
因为 Operator 提供了集群范围的资源，如 API 服务和 CRD，所以如果一个 Operator 为依赖项指定了一个小的窗口，则可能会对依赖项的其他用户的更新产生不必要的约束。
在可能的情况下，尽量不要设置最大版本。或者，设置一个非常宽松的语义范围，以防止与其他 Operator 冲突。例如：
>1.0.0 <2.0.0。与传统的软件包管理器不同，Operator 作者显性地对更新通过 OLM 中的频道进行编码。如果现有订阅有可用更新，则假定 Operator 作者表示它可以从上一版本更新。为依赖项设置最大版本会绕过作者的更新流，即不必要的将它截断到特定的上限。
注意集群管理员无法覆盖 Operator 作者设置的依赖项。
但是，如果已知有需要避免的不兼容问题，就应该设置最大版本。通过使用版本范围语法，可以省略特定的版本，如
> 1.0.0 !1.2.1。
2.4.4.6. 依赖项注意事项
当指定依赖项时，需要考虑一些注意事项。
- 没有捆绑包约束（AND）
目前还没有方法指定约束间的 AND 关系。换句话说，无法指定一个 Operator，它依赖于另外一个 Operator，它提供一个给定的 API 且版本是
>1.1.0。这意味着，在指定依赖项时，如：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OLM 可以通过两个 Operator 来满足这个要求：一个提供 EtcdCluster，另一个有版本
>3.1.0。是否发生了这种情况，或者选择某个 Operator 是否满足这两个限制，这取决于是否准备了潜在的选项。依赖项偏好和排序选项被明确定义并可以指定原因，但为了谨慎起见，Operator 应该遵循一种机制或其他机制。- 跨命名空间兼容性
- OLM 在命名空间范围内执行依赖项解析。如果更新某个命名空间中的 Operator 会对另一个命名空间中的 Operator 造成问题，则可能会造成更新死锁。
2.4.4.7. 依赖项解析方案示例
在以下示例中，provider（供应商） 是指"拥有" CRD 或 API 服务的 Operator。
示例：弃用从属 API
A 和 B 是 API（CRD）：
- A 的供应商依赖 B。
- B 的供应商有一个订阅。
- B 更新供应商提供 C，但弃用 B。
结果：
- B 不再有供应商。
- A 不再工作。
这是 OLM 通过升级策略阻止的一个案例。
示例：版本死锁
A 和 B 均为 API：
- A 的供应商需要 B。
- B 的供应商需要 A。
- A 更新的供应商到（提供 A2，需要 B2）并弃用 A。
- B 更新的供应商到（提供 B2,需要 A2）并弃用 B。
如果 OLM 试图在更新 A 的同时不更新 B，或更新 B 的同时不更新 A，则无法升级到新版 Operator，即使可找到新的兼容集也无法更新。
这是 OLM 通过升级策略阻止的另一案例。
2.4.5. operator 组
本指南概述了 OpenShift Container Platform 中 Operator Lifecycle Manager（OLM）的 Operator 组使用情况。
2.4.5.1. 关于 Operator 组
由 OperatorGroup 资源定义的 Operator 组，为 OLM 安装的 Operator 提供多租户配置。Operator 组选择目标命名空间，在其中为其成员 Operator 生成所需的 RBAC 访问权限。
这一组目标命名空间通过存储在 CSV 的 olm.targetNamespaces 注解中的以逗号分隔的字符串来提供。该注解应用于成员 Operator 的 CSV 实例，并注入它们的部署中。
2.4.5.2. Operator 组成员
满足以下任一条件，Operator 即可被视为 Operator 组的 member：
- Operator 的 CSV 与 Operator 组位于同一命名空间中。
- Operator CSV 中的安装模式支持 Operator 组的目标命名空间集。
CSV 中的安装模式由 InstallModeType 字段和 Supported 的布尔值字段组成。CSV 的 spec 可以包含一组由四个不同 InstallModeTypes 组成的安装模式：
| InstallModeType | 描述 |
|---|---|
|
| Operator 可以是选择其自有命名空间的 Operator 组的成员。 |
|
| Operator 可以是选择一个命名空间的 Operator 组的成员。 |
|
| Operator 可以是选择多个命名空间的 Operator 组的成员。 |
|
|
Operator 可以是选择所有命名空间的 Operator 组的成员（目标命名空间集为空字符串 |
如果 CSV 的 spec 省略 InstallModeType 条目，则该类型将被视为不受支持，除非可通过隐式支持的现有条目推断出支持。
2.4.5.3. 目标命名空间选择
您可以使用 spec.targetNamespaces 参数为 Operator 组显式命名目标命名空间：
您还可以使用带有 spec.selector 参数的标签选择器指定命名空间：
不建议通过 spec.targetNamespaces 列出多个命名空间，或通过 spec.selector 使用标签选择器，因为在以后的版本中可能会删除对 Operator 组中多个目标命名空间的支持。
如果 spec.targetNamespaces 和 spec.selector 均已定义，则会忽略 spec.selector。另外，您可以省略 spec.selector 和 spec.targetNamespaces 来指定一个 全局 Operator 组，该组选择所有命名空间：
apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: my-group namespace: my-namespace
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: my-group
namespace: my-namespace
Opeator 组的 status.namespaces 参数中会显示所选命名空间的解析集合。全局 OperatorGroup 的 status.namespace 包含空字符串 ("")，而该字符串会向正在使用的 Operator 发出信号，要求其监视所有命名空间。
2.4.5.4. operator 组 CSV 注解
Operator 组的成员 CSV 具有以下注解：
| 注解 | 描述 |
|---|---|
|
| 包含 Operator 组的名称。 |
|
| 包含 Operator 组的命名空间。 |
|
| 包含以逗号分隔的字符串，列出 Operator 组的目标命名空间选择。 |
除 olm.targetNamespaces 以外的所有注解均包含在复制的 CSV 中。在复制的 CSV 上省略 olm.targetNamespaces 注解可防止租户之间目标命名空间出现重复。
2.4.5.5. 所提供的 API 注解
group/version/kind (GVK) 是 Kubernetes API 的唯一标识符。olm.providedAPIs 注解中会显示有关 Operator 组提供哪些 GVK 的信息。该注解值为一个字符串，由用逗号分隔的 <kind>.<version>.<group> 组成。其中包括由 Operator 组的所有活跃成员 CSV 提供的 CRD 和 APIService 的 GVK。
查看以下 OperatorGroup 示例，该 OperatorGroup 带有提供 PackageManifest 资源的单个活跃成员 CSV：
2.4.5.6. 基于角色的访问控制
创建 Operator 组时，会生成三个集群角色。每个 ClusterRole 均包含一个聚会规则，后者带有一个选择器以匹配标签，如下所示：
| 集群角色 | 要匹配的标签 |
|---|---|
|
|
|
|
|
|
|
|
|
当 CSV 成为 Operator 组的活跃成员时，只要该 CSV 正在使用 AllNamespaces 安装模式来监视所有命名空间，且没有因 InterOperatorGroupOwnerConflict 原因处于故障状态，便会生成以下 RBAC 资源。
- 来自 CRD 的每个 API 资源的集群角色
- 来自 API 服务的每个 API 资源的集群角色
- 其他角色和角色绑定
| 集群角色 | 设置 |
|---|---|
|
|
聚合标签：
|
|
|
聚合标签：
|
|
|
聚合标签：
|
|
|
聚合标签：
|
| 集群角色 | 设置 |
|---|---|
|
|
聚合标签：
|
|
|
聚合标签：
|
|
|
聚合标签：
|
其他角色和角色绑定
-
如果 CSV 定义了一个目标命名空间，其中包括
*，则会针对 CSV 权限字段中定义的每个permissions生成集群角色和对应集群角色绑定。所有生成的资源均会标上olm.owner: <csv_name>和olm.owner.namespace: <csv_namespace>标签。 -
如果 CSV 没有定义一个包含
*的目标命名空间，则 Operator 命名空间中的所有角色和角色绑定都使用olm.owner: <csv_name>和olm.owner.namespace: <csv_namespace>标签复制到目标命名空间中。
2.4.5.7. 复制的 CSV
OLM 会在 Operator 组的每个目标命名空间中创建 Operator 组的所有活跃成员 CSV 的副本。复制 CSV 的目的在于告诉目标命名空间的用户，特定 Operator 已配置为监视在此创建的资源。
复制的 CSV 会复制状态原因，并会更新以匹配其源 CSV 的状态。在集群上创建复制的 CSV 之前，会从这些 CSV 中分离 olm.targetNamespaces 注解。省略目标命名空间选择可避免租户之间存在目标命名空间重复的现象。
当所复制的 CSV 的源 CSV 不存在或其源 CSV 所属的 Operator 组不再指向复制 CSV 的命名空间时，会删除复制的 CSV。
2.4.5.8. 静态 Operator 组
如果 Operator 组的 spec.staticProvidedAPIs 字段被设置为 true，则 Operator 组为静态。因此，OLM 不会修改 Operator 组的 olm.providedAPIs 注解，这意味着可以提前设置它。如果一组命名空间没有活跃的成员 CSV 来为资源提供 API，而用户想使用 Operator 组来防止命名空间集中发生资源争用，则这一操作十分有用。
以下是一个 Operator 组示例，它使用 something.cool.io/cluster-monitoring: "true" 注解来保护所有命名空间中的 Prometheus 资源：
2.4.5.9. operator 组交集
如果两个 Operator 组的目标命名空间集的交集不是空集，且根据 olm.providedAPIs 注解的定义，所提供的 API 集的交集也不是空集，则称这两个 OperatorGroup 的提供的 API 有交集。
一个潜在问题是，提供的 API 有交集的 Operator 组可能在命名空间交集中竞争相同资源。
在检查交集规则时，Operator 组的命名空间始终包含在其所选目标命名空间中。
交集规则
每次活跃成员 CSV 同步时，OLM 均会查询集群，以获取 CSV 组和其他所有 CSV 组之间提供的 API 交集。然后 OLM 会检查该交集是否为空集：
如果结果为
true，且 CSV 提供的 API 是 Operator 组提供的 API 的子集：- 继续转变。
如果结果为
true，且 CSV 提供的 API 不是 Operator 组提供的 API 的子集：如果 Operator 组是静态的：
- 则清理属于 CSV 的所有部署。
-
将 CSV 转变为故障状态，状态原因为：
CannotModifyStaticOperatorGroupProvidedAPIs。
如果 Operator 组不是静态的：
-
将 Operator 组的
olm.providedAPIs注解替换为其本身与 CSV 提供的 API 的并集。
-
将 Operator 组的
如果结果为
false，且 CSV 提供的 API 不是 Operator 组提供的 API 的子集：- 则清理属于 CSV 的所有部署。
-
将 CSV 转变为故障状态，状态原因为：
InterOperatorGroupOwnerConflict。
如果结果为
false，且 CSV 提供的 API 是 Operator 组提供的 API 的子集：如果 Operator 组是静态的：
- 则清理属于 CSV 的所有部署。
-
将 CSV 转变为故障状态，状态原因为：
CannotModifyStaticOperatorGroupProvidedAPIs。
如果 Operator 组不是静态的：
-
将 Operator 组的
olm.providedAPIs注解替换为其本身与 CSV 提供的 API 的差集。
-
将 Operator 组的
Operator 组所造成的故障状态不是终端状态。
每次 Operator 组同步时都会执行以下操作：
- 来自活跃成员 CSV 的提供的 API 集是通过集群计算出来的。注意，复制的 CSV 会被忽略。
-
将集群集与
olm.providedAPIs进行比较，如果olm.providedAPIs包含任何额外 API，则将删除这些 API。 - 在所有命名空间中提供相同 API 的所有 CSV 均会重新排序。这样可向交集组中的冲突 CSV 发送通知，表明可能已通过调整大小或删除冲突的 CSV 解决了冲突。
2.4.5.10. 多租户 Operator 管理的限制
OpenShift Container Platform 对在集群中同时安装不同 Operator 版本提供有限支持。Operator 是 control plane 扩展。所有租户或命名空间共享同一集群的 control plane。因此，多租户环境中的租户也必须共享 Operator。
Operator Lifecycle Manager (OLM) 会在不同的命名空间中多次安装 Operator。其中一个限制是 Operator 的 API 版本必须相同。
Operator 的不同主要版本通常具有不兼容的自定义资源定义 (CRD)。这使得无法快速验证 OLM。
2.4.5.11. 对 Operator 组进行故障排除
成员资格
-
如果一个命名空间中存在多个 Operator 组，则在该命名空间中创建的所有 CSV 均会变成故障状态，故障原因为：
TooManyOperatorGroups。处于故障状态的 CSV 会在命名空间中的 Operator 组达到 1 后转变为等待处理状态。 -
如果 CSV 的安装模式不支持其命名空间中 Operator 组的目标命名空间选择，CSV 会转变为故障状态，原因为
UnsupportedOperatorGroup。处于故障状态的 CSV 会在 Operator 组的目标命名空间选择变为受支持的配置后转变为待处理，或者 CSV 的安装模式被修改来支持目标命名空间选择。
2.4.6. Operator 条件
本指南概述了 Operator Lifecycle Manager（OLM）如何使用 Operator 条件。
2.4.6.1. 关于 Operator 条件
作为管理 Operator 生命周期的角色的一部分，Operator Lifecycle Manager（OLM）从定义 Operator 的 Kubernetes 资源状态中推断 Operator 状态。虽然此方法提供了一定程度的保证来确定 Operator 处于给定状态，但在有些情况下，Operator 可能需要直接向 OLM 提供信息，而这些信息不能被推断出来。这些信息可以被 OLM 使用来更好地管理 Operator 的生命周期。
OLM 提供了一个名为 OperatorCondition 的自定义资源定义（CRD），它允许 Operator 与 OLM 相互通信条件信息。当在一个 OperatorCondition 资源的 Status.Conditions 数组中存在时，则代表存在一组会影响 OLM 管理 Operator 的支持条件。
2.4.6.2. 支持的条件
Operator Lifecycle Manager（OLM）支持以下 Operator 条件。
2.4.6.2.1. Upgradeable（可升级）条件
Upgradeable Operator 条件可防止现有集群服务版本（CSV）被 CSV 的新版本替换。这一条件在以下情况下很有用：
- Operator 即将启动关键进程，不应在进程完成前升级。
- Operator 正在执行一个自定义资源（CR）迁移，这个迁移必须在 Operator 准备进行升级前完成。
Upgradeable Operator 条件
2.4.7. Operator Lifecycle Manager 指标数据
2.4.7.1. 公开的指标
Operator Lifecycle Manager（OLM）会公开某些 OLM 特定资源，供基于 Prometheus 的 OpenShift Container Platform 集群监控堆栈使用。
| 名称 | 描述 |
|---|---|
|
| 目录源数量。 |
|
|
在协调集群服务版本（CSV）时，每当 CSV 版本处于 |
|
| 成功注册的 CSV 数量。 |
|
|
在协调 CSV 时，代表 CSV 版本处于 |
|
| CSV 升级的 Monotonic 计数。 |
|
| 安装计划的数量。 |
|
| 订阅数。 |
|
|
订阅同步的单调计数。包括 |
2.4.8. Operator Lifecycle Manager 中的 Webhook 管理
Webhook 允许 Operator 作者在资源被保存到对象存储并由 Operator 控制器处理之前，拦截、修改、接受或拒绝资源。当 webhook 与 Operator 一同提供时，Operator Lifecycle Manager（OLM）可以管理这些 webhook 的生命周期。
如需有关 Operator 开发人员如何为其 Operator 定义 webhook，以及 OLM 上运行时的注意事项的详细信息，请参阅定义集群服务版本（CSV）。
2.5. 了解 OperatorHub
2.5.1. 关于 OperatorHub
OperatorHub 是集群管理员用来发现和安装 Operator 的 OpenShift Container Platform 中的 Web 控制台界面。只需单击一次，即可从其非集群源拉取 Operator，并将其安装和订阅至集群中，为工程团队使用 Operator Lifecycle Manager (OLM) 在部署环境中自助管理产品做好准备。
集群管理员可从划分为以下类别的目录进行选择：
| 类别 | 描述 |
|---|---|
| 红帽 Operator | 已由红帽打包并提供的红帽产品。受红帽支持。 |
| 经认证的 Operator | 来自主要独立软件供应商 (ISV) 的产品。红帽与 ISV 合作打包并提供。受 ISV 支持。 |
| Red Hat Marketplace | 可通过 Red Hat Marketplace 购买认证的软件。 |
| 社区 Operator | operator-framework/community-operators GitHub 存储库中由相关代表维护的可选可见软件。无官方支持。 |
| 自定义 Operator | 您自行添加至集群的 Operator。如果您尚未添加任何自定义 Operator，则您的 OperatorHub 上 Web 控制台中便不会出现自定义类别。 |
OperatorHub 上的操作员被打包在 OLM 上运行。这包括一个称为集群服务版本（CSV）的 YAML 文件，其中包含安装和安全运行 Operator 所需的所有 CRD 、RBAC 规则、Deployment 和容器镜像。它还包含用户可见的信息，如功能描述和支持的 Kubernetes 版本。
Operator SDK 可以用来协助开发人员打包 Operators 以用于 OLM 和 OperatorHub。如果您有一个需要方便客户访问的商业应用程序，请使用红帽合作伙伴连接门户（connect.redhat.com）提供的认证工作流来包括这个应用程序。
2.5.2. OperatorHub 架构
OperatorHub UI 组件默认由 openshift-marketplace 命名空间中 OpenShift Container Platform 上的 Marketplace Operator 驱动。
2.5.2.1. OperatorHub 自定义资源
Marketplace Operator 管理名为 cluster 的 OperatorHub 自定义资源（CR），用于管理 OperatorHub 提供的默认 CatalogSource 对象。您可以修改此资源以启用或禁用默认目录，这在受限网络环境中配置 OpenShift Container Platform 时非常有用。
OperatorHub 自定义资源示例
2.6. 红帽提供的 Operator 目录
2.6.1. 关于 Operator 目录
Operator 目录是 Operator Lifecycle Manager（OLM）可以查询的元数据存储库，以在集群中发现和安装 Operator 及其依赖项。OLM 始终从目录的最新版本安装 Operator。从 OpenShift Container Platform 4.6 开始，红帽提供的目录会使用索引镜像进行发布。
基于 Operator Bundle Format 的索引镜像是目录的容器化快照。这是一个不可变的工件，包含指向一组 Operator 清单内容的指针数据库。目录可以引用索引镜像来获取集群中 OLM 的内容。
从 OpenShift Container Platform 4.6 开始，索引镜像由红帽提供来替代 App Registry 目录镜像。App Registry 目录镜像使用已弃用的 Package Manifest Format，它在以前的 OpenShift Container Platform 4 版本中分布。虽然红帽不会为 OpenShift Container Platform 4.6 及之后的版本发布 App Registry 目录镜像，但基于 Package Manifest Format 的自定义目录镜像仍被支持。
随着目录的更新，Operator 的最新版本会发生变化，旧版本可能会被删除或修改。另外，当 OLM 在受限网络环境中的 OpenShift Container Platform 集群上运行时，它无法直接从互联网访问目录来拉取最新内容。
作为集群管理员，您可以根据红帽提供的目录或从头创建自己的自定义索引镜像，该镜像可用于提供集群中的目录内容。创建和更新您自己的索引镜像提供了一种方法来自定义集群上可用的一组 Operator，同时避免了上面提到的受限网络环境中的问题。
在创建自定义目录镜像时，oc adm catalog build 命令需要 OpenShift Container Platform 4 的早期版本，一些版本已弃用。从 OpenShift Container Platform 4.6 开始，红帽提供的索引镜像可用后，目录构建器应该开始切换为使用 opm index 命令来管理索引镜像，oc adm catalog build 命令会在以后的发行版本中被删除。
2.6.2. 关于红帽提供的 Operator 目录
以下 Operator 目录由红帽发布：
| 目录 | 索引镜像 | 描述 |
|---|---|---|
|
|
| 已由红帽打包并提供的红帽产品。受红帽支持。 |
|
|
| 来自主要独立软件供应商 (ISV) 的产品。红帽与 ISV 合作打包并提供。受 ISV 支持。 |
|
|
| 可通过 Red Hat Marketplace 购买认证的软件。 |
|
|
| 软件由 operator-framework/community-operators GitHub 仓库中相关方来维护。无官方支持。 |
2.7. CRD
2.7.1. 使用自定义资源定义来扩展 Kubernetes API
Operator 使用 Kubernetes 扩展机制（自定义资源定义（CRD）），以便使由 Operator 管理的自定义类似于内置的原生 Kubernetes 对象。本指南介绍了集群管理员如何通过创建和管理 CRD 来扩展其 OpenShift Container Platform 集群。
2.7.1.1. 自定义资源定义
在 Kubernetes API 中，resource（资源）是存储某一类 API 对象集的端点。例如，内置 Pod 资源包含一组 Pod 对象。
自定义资源定义（CRD）对象在集群中定义一个新的、唯一的对象类型，称为 kind，并允许 Kubernetes API 服务器处理其整个生命周期。
自定义资源 (CR) 对象由集群管理员通过集群中已添加的 CRD 创建，并支持所有集群用户在项目中增加新的资源类型。
当集群管理员增加新 CRD 至集群中时，Kubernetes API 服务器的回应方式是新建一个可由整个集群或单个项目（命名空间）访问的 RESTful 资源路径，并开始服务于指定的 CR。
集群管理员如果要向其他用户授予 CRD 访问权限，可使用集群角色聚合来向用户授予 admin、edit 或 view 默认集群角色访问权限。集群角色聚合支持将自定义策略规则插入到这些集群角色中。此行为将新资源整合到集群的 RBAC 策略中，就像内置资源一样。
Operator 会通过将 CRD 与任何所需 RBAC 策略和其他软件特定逻辑打包到一起来利用 CRD。集群管理员也可以手动将 CRD 添加到 Operator 生命周期之外的集群中，供所有用户使用。
虽然只有集群管理员可创建 CRD，但具有 CRD 读写权限的开发人员也可通过现有 CRD 来创建 CR。
2.7.1.2. 创建自定义资源定义
要创建自定义资源 (CR) 对象，集群管理员首先必须创建一个自定义资源定义 (CRD)。
先决条件
-
以
cluster-admin用户身份访问 OpenShift Container Platform 集群。
流程
要创建 CRD：
先创建一个包含以下字段类型的 YAML 文件：
CRD 的 YAML 文件示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 使用
apiextensions.k8s.io/v1API。 - 2
- 为定义指定名称。这必须采用
<plural-name>.<group>格式，并使用来自group和plural字段的值。 - 3
- 为 API 指定组名。API 组是一个逻辑上相关的对象集。例如，
Job或ScheduledJob等所有批处理对象，均可添加至批处理 API 组（如batch.api.example.com）中。最好使用您机构的完全限定域名（FQDN）。 - 4
- 指定 URL 中要用的版本名称。每个 API 组都可能存在于多个版本中，例如
v1alpha、v1beta、v1。 - 5
- 指定自定义对象可用于某一个项目 (
Namespaced) 还是集群中的所有项目 (Cluster)。 - 6
- 指定 URL 中要用的复数名称。
plural字段与 API URL 网址中的资源相同。 - 7
- 指定将在 CLI 上用作别名并用于显示的单数名称。
- 8
- 指定可创建的对象类型。类型可以采用 CamelCase。
- 9
- 指定与 CLI 中的资源相匹配的较短字符串。
注意默认情况下，CRD 的覆盖范围为整个集群，适用于所有项目。
创建 CRD 对象：
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在以下位置新建一个 RESTful API 端点：
/apis/<spec:group>/<spec:version>/<scope>/*/<names-plural>/...
/apis/<spec:group>/<spec:version>/<scope>/*/<names-plural>/...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如，以下端点便是通过示例文件创建的：
/apis/stable.example.com/v1/namespaces/*/crontabs/...
/apis/stable.example.com/v1/namespaces/*/crontabs/...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 现在，您即可使用该端点 URL 来创建和管理 CR。对象类型基于您创建的 CRD 对象的
spec.kind字段。
2.7.1.3. 为自定义资源定义创建集群角色
集群管理员可向现有集群范围的自定义资源定义 (CRD) 授予权限。如果使用 admin、edit 和 view 默认集群角色，请利用集群角色聚合来制定规则。
您必须为每个角色明确分配权限。权限更多的角色不会继承权限较少角色的规则。如果要为某个角色分配规则，还必须将该操作动词分配给具有更多权限的角色。例如，如果要向 view 角色授予 get crontabs 的权限，也必须向 edit 和 admin 角色授予该权限。admin 或 edit 角色通常会分配给通过项目模板创建项目的用户。
先决条件
- 创建 CRD。
流程
为 CRD 创建集群角色定义文件。集群角色定义是一个 YAML 文件，其中包含适用于各个集群角色的规则。OpenShift Container Platform 控制器会将您指定的规则添加至默认集群角色中。
集群角色定义的 YAML 文件示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建集群角色：
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.1.4. 通过文件创建自定义资源
将自定义资源定义 (CRD) 添加至集群后，可使用 CLI 按照自定义资源 (CR) 规范通过文件创建 CR。
先决条件
- 集群管理员已将 CRD 添加至集群中。
流程
为 CR 创建 YAML 文件。在下面的定义示例中，
cronSpec和image自定义字段在Kind: CronTab的 CR 中设定。Kind来自 CRD 对象的spec.kind字段：CR 的 YAML 文件示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建完文件后，再创建对象：
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.1.5. 检查自定义资源
您可使用 CLI 检查集群中存在的自定义资源 (CR) 对象。
先决条件
- 您有权访问的命名空间中已存在 CR 对象。
流程
要获取特定类型的 CR 的信息，请运行：
oc get <kind>
$ oc get <kind>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
oc get crontab
$ oc get crontabCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME KIND my-new-cron-object CronTab.v1.stable.example.com
NAME KIND my-new-cron-object CronTab.v1.stable.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 资源名称不区分大小写，您既可使用 CRD 中定义的单数或复数形式，也可使用简称。例如：
oc get crontabs
$ oc get crontabsCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc get crontab
$ oc get crontabCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc get ct
$ oc get ctCopy to Clipboard Copied! Toggle word wrap Toggle overflow 还可查看 CR 的原始 YAML 数据：
oc get <kind> -o yaml
$ oc get <kind> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
oc get ct -o yaml
$ oc get ct -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.2. 管理自定义资源定义中的资源
本指南向开发人员介绍了如何管理来自自定义资源定义 (CRD) 的自定义资源 (CR)。
2.7.2.1. 自定义资源定义
在 Kubernetes API 中，resource（资源）是存储某一类 API 对象集的端点。例如，内置 Pod 资源包含一组 Pod 对象。
自定义资源定义（CRD）对象在集群中定义一个新的、唯一的对象类型，称为 kind，并允许 Kubernetes API 服务器处理其整个生命周期。
自定义资源 (CR) 对象由集群管理员通过集群中已添加的 CRD 创建，并支持所有集群用户在项目中增加新的资源类型。
Operator 会通过将 CRD 与任何所需 RBAC 策略和其他软件特定逻辑打包到一起来利用 CRD。集群管理员也可以手动将 CRD 添加到 Operator 生命周期之外的集群中，供所有用户使用。
虽然只有集群管理员可创建 CRD，但具有 CRD 读写权限的开发人员也可通过现有 CRD 来创建 CR。
2.7.2.2. 通过文件创建自定义资源
将自定义资源定义 (CRD) 添加至集群后，可使用 CLI 按照自定义资源 (CR) 规范通过文件创建 CR。
先决条件
- 集群管理员已将 CRD 添加至集群中。
流程
为 CR 创建 YAML 文件。在下面的定义示例中，
cronSpec和image自定义字段在Kind: CronTab的 CR 中设定。Kind来自 CRD 对象的spec.kind字段：CR 的 YAML 文件示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建完文件后，再创建对象：
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.2.3. 检查自定义资源
您可使用 CLI 检查集群中存在的自定义资源 (CR) 对象。
先决条件
- 您有权访问的命名空间中已存在 CR 对象。
流程
要获取特定类型的 CR 的信息，请运行：
oc get <kind>
$ oc get <kind>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
oc get crontab
$ oc get crontabCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME KIND my-new-cron-object CronTab.v1.stable.example.com
NAME KIND my-new-cron-object CronTab.v1.stable.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 资源名称不区分大小写，您既可使用 CRD 中定义的单数或复数形式，也可使用简称。例如：
oc get crontabs
$ oc get crontabsCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc get crontab
$ oc get crontabCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc get ct
$ oc get ctCopy to Clipboard Copied! Toggle word wrap Toggle overflow 还可查看 CR 的原始 YAML 数据：
oc get <kind> -o yaml
$ oc get <kind> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
oc get ct -o yaml
$ oc get ct -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 3 章 用户任务
3.1. 从已安装的 Operator 创建应用程序
本指南向开发人员介绍了如何使用 OpenShift Container Platform Web 控制台从已安装的 Operator 创建应用程序。
3.1.1. 使用 Operator 创建 etcd 集群
本流程介绍了如何通过由 Operator Lifecycle Manager (OLM) 管理的 etcd Operator 来新建一个 etcd 集群。
先决条件
- 访问 OpenShift Container Platform 4.7 集群
- 管理员已在集群范围内安装了 etcd Operator。
流程
-
针对此流程在 OpenShift Container Platform Web 控制台中新建一个项目。这个示例使用名为
my-etcd的项目。 导航至 Operators → Installed Operators 页面。由集群管理员安装到集群且可供使用的 Operator 将以集群服务版本（CSV）列表形式显示在此处。CSV 用于启动和管理由 Operator 提供的软件。
提示使用以下命令从 CLI 获得该列表：
oc get csv
$ oc get csvCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 Installed Operators 页面中，点 etcd Operator 查看更多详情和可用操作。
正如 Provided API 下所示，该 Operator 提供了三类新资源，包括一种用于 etcd Cluster 的资源（
EtcdCluster资源）。这些对象的工作方式与内置的原生 Kubernetes 对象（如Deployment或ReplicaSet）相似，但包含特定于管理 etcd 的逻辑。新建 etcd 集群：
- 在 etcd Cluster API 框中，点 Create instance。
-
在下一页上，您可对
EtcdCluster对象的最小起始模板进行任何修改，比如集群大小。现在，点击 Create 即可完成。点击后即可触发 Operator 启动 pod、服务和新 etcd 集群的其他组件。
点 example etcd 集群，然后点 Resources 选项卡，您可以看到项目现在包含很多由 Operator 自动创建和配置的资源。
验证已创建了支持您从项目中的其他 pod 访问数据库的 Kubernetes 服务。
给定项目中具有
edit角色的所有用户均可创建、管理和删除应用程序实例（本例中为 etcd 集群），这些实例由已在项目中创建的 Operator 以自助方式管理，就像云服务一样。如果要赋予其他用户这一权利，项目管理员可使用以下命令添加角色：oc policy add-role-to-user edit <user> -n <target_project>
$ oc policy add-role-to-user edit <user> -n <target_project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
现在您有了一个 etcd 集群，当 pod 运行不畅，或在集群中的节点之间迁移时，该集群将对故障做出反应并重新平衡数据。最重要的是，具有适当访问权限的集群管理员或开发人员现在可轻松将该数据库用于其应用程序。
3.2. 在命名空间中安装 Operator
如果集群管理员将 Operator 安装权限委托给您的帐户，您可以以自助服务的方式将 Operator 安装并订阅到命名空间中。
3.2.1. 先决条件
- 集群管理员必须在 OpenShift Container Platform 用户帐户中添加某些权限，以便允许将自助服务 Operator 安装到命名空间。详情请参阅 允许非集群管理员安装 Operator。
3.2.2. 使用 OperatorHub 安装 operator
OperatorHub 是一个发现 Operator 的用户界面，它与 Operator Lifecycle Manager（OLM）一起工作，后者在集群中安装和管理 Operator。
作为具有适当权限的用户，您可以使用 OpenShift Container Platform Web 控制台或 CLI 安装来自 OperatorHub 的 Operator。
安装过程中，您必须为 Operator 确定以下初始设置：
- 安装模式
- 选择要在其中安装 Operator 的特定命名空间。
- 更新频道
- 如果某个 Operator 可通过多个频道获得，则可任选您想要订阅的频道。例如，要通过 stable 频道部署（如果可用），则从列表中选择这个选项。
- 批准策略
您可以选择自动或者手动更新。
如果选择自动更新某个已安装的 Operator，则当所选频道中有该 Operator 的新版本时，Operator Lifecycle Manager（OLM）将自动升级 Operator 的运行实例，而无需人为干预。
如果选择手动更新，则当有新版 Operator 可用时，OLM 会创建更新请求。作为集群管理员，您必须手动批准该更新请求，才可将 Operator 更新至新版本。
3.2.3. 使用 Web 控制台从 OperatorHub 安装
您可以使用 OpenShift Container Platform Web 控制台从 OperatorHub 安装并订阅 Operator。
先决条件
- 使用具有 Operator 安装权限的账户访问 OpenShift Container Platform 集群。
流程
- 在 Web 控制台中导航至 Operators → OperatorHub 页面。
找到您需要的 Operator（滚动页面会在 Filter by keyword 框中输入查找关键字）。例如，输入
advanced来查找 Advanced Cluster Management for Kubernetes Operator。您还可以根据基础架构功能过滤选项。例如，如果您希望 Operator 在断开连接的环境中工作，请选择 Disconnected。
选择要显示更多信息的 Operator。
注意选择 Community Operator 会警告红帽没有认证社区 Operator ; 您必须确认该警告方可继续。
- 阅读 Operator 信息并单击 Install。
在 Install Operator 页面中：
- 选择要在其中安装 Operator 的特定单一命名空间。该 Operator 仅限在该单一命名空间中监视和使用。
- 选择一个更新频道（如有多个可用）。
- 如前面所述，选择自动或手动批准策略。
点击 Install 使 Operator 可供 OpenShift Container Platform 集群上的所选命名空间使用。
如果选择了手动批准策略，订阅的升级状态将保持在 Upgrading 状态，直至您审核并批准安装计划。
在 Install Plan 页面批准后，订阅的升级状态将变为 Up to date。
- 如果选择了 Automatic 批准策略，升级状态会在不用人工参与的情况下变为 Up to date。
在订阅的升级状态成为 Up to date 后，选择 Operators → Installed Operators 来验证已安装 Operator 的 ClusterServiceVersion（CSV）是否最终出现了。状态最终会在相关命名空间中变为 InstallSucceeded。
注意对于 All namespaces… 安装模式，状态在
openshift-operators命名空间中解析为 InstallSucceeded，但如果检查其他命名空间，则状态为 Copied。如果没有：
-
检查
openshift-operators项目（如果选择了 A specific namespace… 安装模式）中的 openshift-operators 项目中的 pod 的日志，这会在 Workloads → Pods 页面中报告问题以便进一步排除故障。
-
检查
3.2.4. 使用 CLI 从 OperatorHub 安装
您可以使用 CLI 从 OperatorHub 安装 Operator，而不必使用 OpenShift Container Platform Web 控制台。使用 oc 命令来创建或更新一个订阅对象。
先决条件
- 使用具有 Operator 安装权限的账户访问 OpenShift Container Platform 集群。
-
在您的本地系统安装
oc命令。
流程
查看 OperatorHub 中集群可用的 Operator 列表：
oc get packagemanifests -n openshift-marketplace
$ oc get packagemanifests -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 记录下所需 Operator 的目录。
检查所需 Operator，以验证其支持的安装模式和可用频道：
oc describe packagemanifests <operator_name> -n openshift-marketplace
$ oc describe packagemanifests <operator_name> -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 一个 Operator 组（由
OperatorGroup对象定义），在其中选择目标命名空间，在其中为与 Operator 组相同的命名空间中的所有 Operator 生成所需的 RBAC 访问权限。订阅 Operator 的命名空间必须具有与 Operator 的安装模式相匹配的 Operator 组，可采用
AllNamespaces模式，也可采用SingleNamespace模式。如果您要使用AllNamespaces安装 Operator，则openshift-operators命名空间已有适当的 Operator 组。如果要安装的 Operator 采用
SingleNamespace模式，而您没有适当的 Operator 组，则必须创建一个。注意在选择
SingleNamespace模式时，该流程的 Web 控制台版本会在后台自动为您处理OperatorGroup和Subscription对象的创建。创建
OperatorGroup对象 YAML 文件，如operatorgroup.yaml：OperatorGroup对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
OperatorGroup对象：oc apply -f operatorgroup.yaml
$ oc apply -f operatorgroup.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建一个
Subscription对象 YAML 文件，以便为 Operator 订阅一个命名空间，如sub.yaml：Subscription对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 对于
AllNamespaces安装模式的使用，指定openshift-operators命名空间。否则，为SingleNamespace安装模式使用指定相关单一命名空间。 - 2
- 要订阅的频道的名称。
- 3
- 要订阅的 Operator 的名称。
- 4
- 提供 Operator 的目录源的名称。
- 5
- 目录源的命名空间。将
openshift-marketplace用于默认的 OperatorHub 目录源。 - 6
env参数定义必须存在于由 OLM 创建的 pod 中所有容器中的环境变量列表。- 7
envFrom参数定义要在容器中填充环境变量的源列表。- 8
volumes参数定义 OLM 创建的 pod 上必须存在的卷列表。- 9
volumeMounts参数定义由 OLM 创建的 pod 中必须存在的 VolumeMounts 列表。如果volumeMount引用不存在的卷，OLM 无法部署 Operator。- 10
tolerations参数为 OLM 创建的 pod 定义 Tolerations 列表。- 11
resources参数为 OLM 创建的 pod 中所有容器定义资源限制。- 12
nodeSelector参数为 OLM 创建的 pod 定义NodeSelector。
创建
Subscription对象：oc apply -f sub.yaml
$ oc apply -f sub.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 此时，OLM 已了解所选的 Operator。Operator 的集群服务版本（CSV）应出现在目标命名空间中，由 Operator 提供的 API 应可用于创建。
3.2.5. 安装 Operator 的特定版本
您可以通过在 Subscription 对象中设置集群服务版本（CSV）来安装 Operator 的特定版本。
先决条件
- 使用具有 Operator 安装权限的账户访问 OpenShift Container Platform 集群
-
已安装 OpenShift CLI（
oc）
流程
通过设置
startingCSV字段，创建一个Subscription对象 YAML 文件，向带有特定版本的 Operator 订阅一个命名空间。将installPlanApproval字段设置为Manual，以便在目录中存在更新的版本时防止 Operator 自动升级。例如，可以使用以下
sub.yaml文件安装 Red Hat Quay Operator，专门用于版本 3.4.0：带有特定起始 Operator 版本的订阅
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
Subscription对象：oc apply -f sub.yaml
$ oc apply -f sub.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 手动批准待处理的安装计划以完成 Operator 安装。
第 4 章 管理员任务
4.1. 在集群中添加 Operator
集群管理员可以通过 OperatorHub 将 Operator 订阅到命名空间来将 Operator 安装到 OpenShift Container Platform 集群。
4.1.1. 使用 OperatorHub 安装 operator
OperatorHub 是一个发现 Operator 的用户界面，它与 Operator Lifecycle Manager（OLM）一起工作，后者在集群中安装和管理 Operator。
作为具有适当权限的用户，您可以使用 OpenShift Container Platform Web 控制台或 CLI 安装来自 OperatorHub 的 Operator。
安装过程中，您必须为 Operator 确定以下初始设置：
- 安装模式
- 选择要在其中安装 Operator 的特定命名空间。
- 更新频道
- 如果某个 Operator 可通过多个频道获得，则可任选您想要订阅的频道。例如，要通过 stable 频道部署（如果可用），则从列表中选择这个选项。
- 批准策略
您可以选择自动或者手动更新。
如果选择自动更新某个已安装的 Operator，则当所选频道中有该 Operator 的新版本时，Operator Lifecycle Manager（OLM）将自动升级 Operator 的运行实例，而无需人为干预。
如果选择手动更新，则当有新版 Operator 可用时，OLM 会创建更新请求。作为集群管理员，您必须手动批准该更新请求，才可将 Operator 更新至新版本。
4.1.2. 使用 Web 控制台从 OperatorHub 安装
您可以使用 OpenShift Container Platform Web 控制台从 OperatorHub 安装并订阅 Operator。
先决条件
-
使用具有
cluster-admin权限的账户访问 OpenShift Container Platform 集群。 - 使用具有 Operator 安装权限的账户访问 OpenShift Container Platform 集群。
流程
- 在 Web 控制台中导航至 Operators → OperatorHub 页面。
找到您需要的 Operator（滚动页面会在 Filter by keyword 框中输入查找关键字）。例如，输入
advanced来查找 Advanced Cluster Management for Kubernetes Operator。您还可以根据基础架构功能过滤选项。例如，如果您希望 Operator 在断开连接的环境中工作，请选择 Disconnected。
选择要显示更多信息的 Operator。
注意选择 Community Operator 会警告红帽没有认证社区 Operator ; 您必须确认该警告方可继续。
- 阅读 Operator 信息并单击 Install。
在 Install Operator 页面中：
任选以下一项：
-
All namespaces on the cluster (default)，选择该项会将 Operator 安装至默认
openshift-operators命名空间，以便供集群中的所有命名空间监视和使用。该选项并非始终可用。 - A specific namespace on the cluster，该项支持您选择单一特定命名空间来安装 Operator。该 Operator 仅限在该单一命名空间中监视和使用。
-
All namespaces on the cluster (default)，选择该项会将 Operator 安装至默认
- 选择要在其中安装 Operator 的特定单一命名空间。该 Operator 仅限在该单一命名空间中监视和使用。
- 选择一个更新频道（如有多个可用）。
- 如前面所述，选择自动或手动批准策略。
点击 Install 使 Operator 可供 OpenShift Container Platform 集群上的所选命名空间使用。
如果选择了手动批准策略，订阅的升级状态将保持在 Upgrading 状态，直至您审核并批准安装计划。
在 Install Plan 页面批准后，订阅的升级状态将变为 Up to date。
- 如果选择了 Automatic 批准策略，升级状态会在不用人工参与的情况下变为 Up to date。
在订阅的升级状态成为 Up to date 后，选择 Operators → Installed Operators 来验证已安装 Operator 的 ClusterServiceVersion（CSV）是否最终出现了。状态最终会在相关命名空间中变为 InstallSucceeded。
注意对于 All namespaces… 安装模式，状态在
openshift-operators命名空间中解析为 InstallSucceeded，但如果检查其他命名空间，则状态为 Copied。如果没有：
-
检查
openshift-operators项目（如果选择了 A specific namespace… 安装模式）中的 openshift-operators 项目中的 pod 的日志，这会在 Workloads → Pods 页面中报告问题以便进一步排除故障。
-
检查
4.1.3. 使用 CLI 从 OperatorHub 安装
您可以使用 CLI 从 OperatorHub 安装 Operator，而不必使用 OpenShift Container Platform Web 控制台。使用 oc 命令来创建或更新一个订阅对象。
先决条件
- 使用具有 Operator 安装权限的账户访问 OpenShift Container Platform 集群。
-
在您的本地系统安装
oc命令。
流程
查看 OperatorHub 中集群可用的 Operator 列表：
oc get packagemanifests -n openshift-marketplace
$ oc get packagemanifests -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 记录下所需 Operator 的目录。
检查所需 Operator，以验证其支持的安装模式和可用频道：
oc describe packagemanifests <operator_name> -n openshift-marketplace
$ oc describe packagemanifests <operator_name> -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 一个 Operator 组（由
OperatorGroup对象定义），在其中选择目标命名空间，在其中为与 Operator 组相同的命名空间中的所有 Operator 生成所需的 RBAC 访问权限。订阅 Operator 的命名空间必须具有与 Operator 的安装模式相匹配的 Operator 组，可采用
AllNamespaces模式，也可采用SingleNamespace模式。如果您要使用AllNamespaces安装 Operator，则openshift-operators命名空间已有适当的 Operator 组。如果要安装的 Operator 采用
SingleNamespace模式，而您没有适当的 Operator 组，则必须创建一个。注意在选择
SingleNamespace模式时，该流程的 Web 控制台版本会在后台自动为您处理OperatorGroup和Subscription对象的创建。创建
OperatorGroup对象 YAML 文件，如operatorgroup.yaml：OperatorGroup对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
OperatorGroup对象：oc apply -f operatorgroup.yaml
$ oc apply -f operatorgroup.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建一个
Subscription对象 YAML 文件，以便为 Operator 订阅一个命名空间，如sub.yaml：Subscription对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 对于
AllNamespaces安装模式的使用，指定openshift-operators命名空间。否则，为SingleNamespace安装模式使用指定相关单一命名空间。 - 2
- 要订阅的频道的名称。
- 3
- 要订阅的 Operator 的名称。
- 4
- 提供 Operator 的目录源的名称。
- 5
- 目录源的命名空间。将
openshift-marketplace用于默认的 OperatorHub 目录源。 - 6
env参数定义必须存在于由 OLM 创建的 pod 中所有容器中的环境变量列表。- 7
envFrom参数定义要在容器中填充环境变量的源列表。- 8
volumes参数定义 OLM 创建的 pod 上必须存在的卷列表。- 9
volumeMounts参数定义由 OLM 创建的 pod 中必须存在的 VolumeMounts 列表。如果volumeMount引用不存在的卷，OLM 无法部署 Operator。- 10
tolerations参数为 OLM 创建的 pod 定义 Tolerations 列表。- 11
resources参数为 OLM 创建的 pod 中所有容器定义资源限制。- 12
nodeSelector参数为 OLM 创建的 pod 定义NodeSelector。
创建
Subscription对象：oc apply -f sub.yaml
$ oc apply -f sub.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 此时，OLM 已了解所选的 Operator。Operator 的集群服务版本（CSV）应出现在目标命名空间中，由 Operator 提供的 API 应可用于创建。
4.1.4. 安装 Operator 的特定版本
您可以通过在 Subscription 对象中设置集群服务版本（CSV）来安装 Operator 的特定版本。
先决条件
- 使用具有 Operator 安装权限的账户访问 OpenShift Container Platform 集群
-
已安装 OpenShift CLI（
oc）
流程
通过设置
startingCSV字段，创建一个Subscription对象 YAML 文件，向带有特定版本的 Operator 订阅一个命名空间。将installPlanApproval字段设置为Manual，以便在目录中存在更新的版本时防止 Operator 自动升级。例如，可以使用以下
sub.yaml文件安装 Red Hat Quay Operator，专门用于版本 3.4.0：带有特定起始 Operator 版本的订阅
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建
Subscription对象：oc apply -f sub.yaml
$ oc apply -f sub.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 手动批准待处理的安装计划以完成 Operator 安装。
4.1.5. Operator 工作负载的 Pod 放置
默认情况下，Operator Lifecycle Manager（OLM）在安装 Operator 或部署 Operand 工作负载时，会将 pod 放置到任意 worker 节点上。作为管理员，您可以使用节点选择器、污点和容限组合使用项目来控制将 Operator 和 Operands 放置到特定节点。
控制 Operator 和 Operand 工作负载的 pod 放置有以下先决条件：
-
根据您的要求，确定 pod 的目标节点或一组节点。如果可用，请注意现有标签，如
node-role.kubernetes.io/app，用于标识节点。否则，使用机器集或直接编辑节点来添加标签，如myoperator。您将在以后的步骤中使用此标签作为项目上的节点选择器。 -
如果要确保只有具有特定标签的 pod 才能在节点上运行，同时将不相关的工作负载加载到其他节点，通过使用机器集或直接编辑节点为节点添加污点。使用一个效果来确保与污点不匹配的新 pod 不能调度到节点上。例如，
myoperator:NoSchedule污点确保与污点不匹配的新 pod 不能调度到该节点上，但节点上现有的 pod 可以保留。 - 创建使用默认节点选择器配置的项目，如果您添加了污点，则创建一个匹配的容限。
此时，您创建的项目可在以下情况下用于将 pod 定向到指定节点：
- 对于 Operator pod
-
管理员可以在项目中创建
Subscription对象。因此，Operator pod 放置在指定的节点上。 - 对于 Operand pod
- 通过使用已安装的 Operator，用户可以在项目中创建一个应用程序，这样可将 Operator 拥有的自定义资源（CR）放置到项目中。因此，Operand pod 放置到指定节点上，除非 Operator 在其他命名空间中部署集群范围对象或资源，在这种情况下，不会应用这个自定义的 pod 放置。
4.2. 升级安装的 Operator
作为集群管理员，您可以升级以前使用 OpenShift Container Platform 集群上的 Operator Lifecycle Manager（OLM）安装的 Operator。
4.2.1. 更改 Operator 的更新频道
已安装的 Operator 的订阅指定一个更新频道，用于跟踪和接收 Operator 的更新。要升级 Operator 以开始跟踪并从更新频道接受更新，您可以更改订阅中的更新频道。
订阅中更新频道的名称可能会因 Operator 而异，但应遵守给定 Operator 中的常规约定。例如，频道名称可能会遵循 Operator 提供的应用程序的次发行版本更新流（1.2、1.3）或发行的频率（stable、fast）。
安装的 Operator 无法变为比当前频道旧的频道。
如果订阅中的批准策略被设置为 Automatic，则升级过程会在所选频道中提供新的 Operator 版本时立即启动。如果批准策略设为 Manual，则必须手动批准待处理的升级。
先决条件
- 之前使用 Operator Lifecycle Manager（OLM）安装的 Operator。
流程
- 在 OpenShift Container Platform Web 控制台的 Administrator 视角中，进入 Operators → Installed Operators。
- 点击您要更改更新频道的 Operator 名称。
- 点 Subscription 标签页。
- 点 Channel 中的更新频道的名称。
- 点要更改的更新频道，然后点 Save。
对于带有 自动批准策略 的订阅，升级会自动开始。返回 Operators → Installed Operators 页面来监控升级的过程。完成后，状态会变为 Succeeded 和 Up to date。
对于采用手动批准策略的订阅，您可以使用 Subscription 选项卡手动批准升级。
4.2.2. 手动批准待处理的 Operator 升级
如果已安装的 Operator 的订阅被设置为 Manual，则当其当前更新频道中发布新更新时，在开始安装前必须手动批准更新。
先决条件
- 之前使用 Operator Lifecycle Manager（OLM）安装的 Operator。
流程
- 在 OpenShift Container Platform Web 控制台的 Administrator 视角中，进入 Operators → Installed Operators。
- 处于待定升级的 Operator 会显示 Upgrade available 状态。点您要升级的 Operator 的名称。
- 点 Subscription 标签页。任何需要批准的升级都会在 Upgrade Status 旁边显示。例如：它可能会显示 1 requires approval。
- 点 1 requires approval，然后点 Preview Install Plan。
- 查看列出可用于升级的资源。在满意后，点 Approve。
- 返回 Operators → Installed Operators 页面来监控升级的过程。完成后，状态会变为 Succeeded 和 Up to date。
4.3. 从集群中删除 Operator
下面介绍如何删除以前使用 OpenShift Container Platform 集群上的 Operator Lifecycle Manager（OLM）安装的 Operator。
4.3.1. 使用 Web 控制台从集群中删除 Operator
集群管理员可以使用 Web 控制台从所选命名空间中删除已安装的 Operator。
先决条件
-
使用具有
cluster-admin权限的账户访问 OpenShift Container Platform 集群 Web 控制台。
流程
- 进入 Operators → Installed Operators 页面，在 Filter by name 字段滚动鼠标或键入关键词，以查找您想要的 Operator。然后点击。
在 Operator Details 页面右侧，从 Actions 列表中选择 Uninstall Operator。
此时会显示 Uninstall Operator? 对话框，提醒您：
删除 Operator 不会移除任何自定义资源定义或受管资源。如果 Operator 在集群中部署了应用程序，或者配置了非集群资源，则这些应用程序将继续运行，需要手动清理。
此操作将删除 Operator 以及 Operator 部署和 pod（若有）。任何 Operands 和由 Operator 管理的资源（包括 CRD 和 CR）都不会被删除。Web 控制台为一些 Operator 启用仪表板和导航项。要在卸载 Operator 后删除这些，您可能需要手动删除 Operator CRD。
- 选择 Uninstall。此 Operator 将停止运行，并且不再接收更新。
4.3.2. 使用 CLI 从集群中删除 Operator
集群管理员可以使用 CLI 从所选命名空间中删除已安装的 Operator。
先决条件
-
使用具有
cluster-admin权限的账户访问 OpenShift Container Platform 集群。 -
已在工作站上安装
oc命令。
流程
通过
currentCSV字段检查已订阅 Operator 的当前版本（如jaeger）：oc get subscription jaeger -n openshift-operators -o yaml | grep currentCSV
$ oc get subscription jaeger -n openshift-operators -o yaml | grep currentCSVCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
currentCSV: jaeger-operator.v1.8.2
currentCSV: jaeger-operator.v1.8.2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 删除订阅（如
jaeger）:oc delete subscription jaeger -n openshift-operators
$ oc delete subscription jaeger -n openshift-operatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
subscription.operators.coreos.com "jaeger" deleted
subscription.operators.coreos.com "jaeger" deletedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用上一步中的
currentCSV值来删除目标命名空间中相应 Operator 的 CSV：oc delete clusterserviceversion jaeger-operator.v1.8.2 -n openshift-operators
$ oc delete clusterserviceversion jaeger-operator.v1.8.2 -n openshift-operatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
clusterserviceversion.operators.coreos.com "jaeger-operator.v1.8.2" deleted
clusterserviceversion.operators.coreos.com "jaeger-operator.v1.8.2" deletedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.3. 刷新失败的订阅
在 Operator Lifecycle Manager（OLM）中，如果您订阅的是引用网络中无法访问的镜像的 Operator，您可以在 openshift-marketplace 命名空间中找到带有以下错误的作业：
输出示例
ImagePullBackOff for Back-off pulling image "example.com/openshift4/ose-elasticsearch-operator-bundle@sha256:6d2587129c846ec28d384540322b40b05833e7e00b25cca584e004af9a1d292e"
ImagePullBackOff for
Back-off pulling image "example.com/openshift4/ose-elasticsearch-operator-bundle@sha256:6d2587129c846ec28d384540322b40b05833e7e00b25cca584e004af9a1d292e"输出示例
rpc error: code = Unknown desc = error pinging docker registry example.com: Get "https://example.com/v2/": dial tcp: lookup example.com on 10.0.0.1:53: no such host
rpc error: code = Unknown desc = error pinging docker registry example.com: Get "https://example.com/v2/": dial tcp: lookup example.com on 10.0.0.1:53: no such host因此，订阅会处于这个失败状态，Operator 无法安装或升级。
您可以通过删除订阅、集群服务版本（CSV）及其他相关对象来刷新失败的订阅。重新创建订阅后，OLM 会重新安装 Operator 的正确版本。
先决条件
- 您有一个失败的订阅，无法拉取不能访问的捆绑包镜像。
- 已确认可以访问正确的捆绑包镜像。
流程
从安装 Operator 的命名空间中获取
Subscription和ClusterServiceVersion对象的名称：oc get sub,csv -n <namespace>
$ oc get sub,csv -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME PACKAGE SOURCE CHANNEL subscription.operators.coreos.com/elasticsearch-operator elasticsearch-operator redhat-operators 5.0 NAME DISPLAY VERSION REPLACES PHASE clusterserviceversion.operators.coreos.com/elasticsearch-operator.5.0.0-65 OpenShift Elasticsearch Operator 5.0.0-65 Succeeded
NAME PACKAGE SOURCE CHANNEL subscription.operators.coreos.com/elasticsearch-operator elasticsearch-operator redhat-operators 5.0 NAME DISPLAY VERSION REPLACES PHASE clusterserviceversion.operators.coreos.com/elasticsearch-operator.5.0.0-65 OpenShift Elasticsearch Operator 5.0.0-65 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除订阅：
oc delete subscription <subscription_name> -n <namespace>
$ oc delete subscription <subscription_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 删除集群服务版本：
oc delete csv <csv_name> -n <namespace>
$ oc delete csv <csv_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在
openshift-marketplace命名空间中获取所有失败的作业的名称和相关配置映射：oc get job,configmap -n openshift-marketplace
$ oc get job,configmap -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME COMPLETIONS DURATION AGE job.batch/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb 1/1 26s 9m30s NAME DATA AGE configmap/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb 3 9m30s
NAME COMPLETIONS DURATION AGE job.batch/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb 1/1 26s 9m30s NAME DATA AGE configmap/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb 3 9m30sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除作业：
oc delete job <job_name> -n openshift-marketplace
$ oc delete job <job_name> -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 这样可确保尝试拉取无法访问的镜像的 Pod 不会被重新创建。
删除配置映射：
oc delete configmap <configmap_name> -n openshift-marketplace
$ oc delete configmap <configmap_name> -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 在 Web 控制台中使用 OperatorHub 重新安装 Operator。
验证
检查是否已成功重新安装 Operator:
oc get sub,csv,installplan -n <namespace>
$ oc get sub,csv,installplan -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4. 在 Operator Lifecycle Manager 中配置代理支持
如果在 OpenShift Container Platform 集群中配置了全局代理，Operator Lifecycle Manager（OLM）会自动配置使用集群范围代理管理的 Operator。但是，您也可以配置已安装的 Operator 来覆盖全局代理服务器或注入自定义 CA 证书。
4.4.1. 覆盖 Operator 的代理设置
如果配置了集群范围的出口代理，使用 Operator Lifecycle Manager（OLM）运行的 Operator 会继承其部署上的集群范围代理设置。集群管理员还可以通过配置 Operator 的订阅来覆盖这些代理设置。
操作员必须为任何受管 Operands 处理 pod 中的代理设置环境变量。
先决条件
-
使用具有
cluster-admin权限的账户访问 OpenShift Container Platform 集群。
流程
- 在 Web 控制台中导航至 Operators → OperatorHub 页面。
- 选择 Operator 并点 Install。
在 Install Operator 页面中，修改
Subscription对象，使其在spec部分中包含一个或多个以下环境变量：-
HTTP_PROXY -
HTTPS_PROXY -
NO_PROXY
例如：
带有代理设置的
Subscription对象覆盖Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意这些环境变量也可以使用空值取消设置，以删除所有之前设定的集群范围或自定义代理设置。
OLM 将这些环境变量作为一个单元处理; 如果至少设置了一个环境变量，则所有 3 个变量都将被视为覆盖，并且集群范围的默认值不会用于订阅的 Operator 部署。
-
- 点击 Install 使 Operator 可供所选命名空间使用。
当 Operator 的 CSV 出现在相关命名空间中后，您可以验证部署中是否设置了自定义代理环境变量。例如，使用 CLI：
oc get deployment -n openshift-operators \ etcd-operator -o yaml \ | grep -i "PROXY" -A 2$ oc get deployment -n openshift-operators \ etcd-operator -o yaml \ | grep -i "PROXY" -A 2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4.2. 注入自定义 CA 证书
当集群管理员使用配置映射向集群添加自定义 CA 证书时，Cluster Network Operator 会将用户提供的证书和系统 CA 证书合并为一个捆绑包（bundle）。您可以将这个合并捆绑包注入 Operator Lifecycle Manager (OLM) 上运行的 Operator 中，如果您有一个中间人（man-in-the-middle）HTTPS 代理，这将会有用。
先决条件
-
使用具有
cluster-admin权限的账户访问 OpenShift Container Platform 集群。 - 使用配置映射添加自定义 CA 证书至集群。
- 在 OLM 上安装并运行所需的 Operator。
流程
在存在 Operator 订阅的命名空间中创建一个空配置映射，并包括以下标签：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建此配置映射后，它会立即使用合并捆绑包的证书内容填充。
更新您的
Subscription对象，使其包含spec.config部分，该部分可将trusted-ca配置映射作为卷挂载到需要自定义 CA 的 pod 中的每个容器：Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5. 查看 Operator 状态
了解 Operator Lifecycle Manager (OLM) 中的系统状态，对于决定和调试已安装 Operator 的问题来说非常重要。OLM 可让您了解订阅和相关目录源的状态以及执行的操作。这样有助于用户更好地理解 Operator 的运行状况。
4.5.1. operator 订阅状况类型
订阅可报告以下状况类型：
| 状况 | 描述 |
|---|---|
|
| 用于解析的一个或多个目录源不健康。 |
|
| 缺少订阅的安装计划。 |
|
| 订阅的安装计划正在安装中。 |
|
| 订阅的安装计划失败。 |
默认 OpenShift Container Platform 集群 Operator 由 Cluster Version Operator（CVO）管理，它们没有 Subscription 对象。应用程序 Operator 由 Operator Lifecycle Manager（OLM）管理，它们具有 Subscription 对象。
4.5.2. 使用 CLI 查看 Operator 订阅状态
您可以使用 CLI 查看 Operator 订阅状态。
先决条件
-
您可以使用具有
cluster-admin角色的用户访问集群。 -
已安装 OpenShift CLI(
oc)。
流程
列出 Operator 订阅：
oc get subs -n <operator_namespace>
$ oc get subs -n <operator_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
oc describe命令检查Subscription资源：oc describe sub <subscription_name> -n <operator_namespace>
$ oc describe sub <subscription_name> -n <operator_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在命令输出中，找到 Operator 订阅状况类型的
Conditions部分。在以下示例中，CatalogSourcesUnhealthy条件类型具有false状态，因为所有可用目录源都健康：输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
默认 OpenShift Container Platform 集群 Operator 由 Cluster Version Operator（CVO）管理，它们没有 Subscription 对象。应用程序 Operator 由 Operator Lifecycle Manager（OLM）管理，它们具有 Subscription 对象。
4.5.3. 使用 CLI 查看 Operator 目录源状态
您可以使用 CLI 查看 Operator 目录源的状态。
先决条件
-
您可以使用具有
cluster-admin角色的用户访问集群。 -
已安装 OpenShift CLI(
oc)。
流程
列出命名空间中的目录源。例如，您可以检查
openshift-marketplace命名空间，该命名空间用于集群范围的目录源：oc get catalogsources -n openshift-marketplace
$ oc get catalogsources -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
oc describe命令获取有关目录源的详情和状态：oc describe catalogsource example-catalog -n openshift-marketplace
$ oc describe catalogsource example-catalog -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在上例的输出中，最后观察到的状态是
TRANSIENT_FAILURE。此状态表示目录源建立连接时出现问题。列出创建目录源的命名空间中的 pod：
oc get pods -n openshift-marketplace
$ oc get pods -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在命名空间中创建目录源时，会在该命名空间中为目录源创建一个 pod。在前面的示例中，
example-catalog-bwt8zpod 的状态是ImagePullBackOff。此状态表示拉取目录源的索引镜像存在问题。使用
oc describe命令检查 pod 以获取更多详细信息：oc describe pod example-catalog-bwt8z -n openshift-marketplace
$ oc describe pod example-catalog-bwt8z -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在前面的示例输出中，错误消息表示目录源的索引镜像因为授权问题而无法成功拉取。例如，索引镜像可能存储在需要登录凭证的 registry 中。
4.6. 管理 Operator 条件
作为集群管理员，您可以使用 Operator Lifecycle Manager（OLM）来管理 Operator 状况。
4.6.1. 覆盖 Operator 条件
作为集群管理员，您可能想要忽略由 Operator 报告的、支持的 Operator 条件。Spec.Overrides 阵列中的 Operator 条件会覆盖 Status.Conditions 阵列中的条件，以便集群管理员可以处理 Operator 向 Operator Lifecycle Manager（OLM）报告了不正确状态的情况。
例如，一个 Operator 的已知版本，它始终会告知它是不可升级的。在这种情况下，尽管报告是不可升级的，您仍然希望升级 Operator。这可以通过在 OperatorCondition 资源中的 Spec.Overrides 阵列中添加 type 和 status 来覆盖 Operator 条件来实现。
先决条件
-
具有
OperatorCondition资源的 Operator，使用 OLM 安装。
流程
编辑 Operator 的
OperatorCondition资源：oc edit operatorcondition <name>
$ oc edit operatorcondition <name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在对象中添加
Spec.Overrides数组：Operator 条件覆盖示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 允许集群管理员将升级就绪状态更改为
True。
4.6.2. 更新 Operator 以使用 Operator 条件
Operator Lifecycle Manager（OLM）会自动为每个它所协调的 ClusterServiceVersion 资源创建一个 OperatorCondition 资源。CSV 中的所有服务帐户都会被授予 RBAC，以便与 Operator 拥有的 OperatorCondition 交互。
Operator 作者可开发其自己的 Operator 来使用 operator-lib 库，以便在由 OLM 部署 Operator 后，它可以设置自己的条件。如需有关编写逻辑以将 Operator 条件设置为 Operator 作者的更多信息，请参阅 Operator SDK 文档。
4.6.2.1. 设置默认值
为了保持向后兼容，OLM 认为在没有 OperatorCondition 时代表不使用条件。因此，要使用 Operator 条件的 Operator，在将 pod 的就绪探测设置为 true 前应设置默认条件。这为 Operator 提供了一个宽限期，用于将条件更新为正确的状态。
4.7. 允许非集群管理员安装 Operator
Operator 可能需要广泛权限才可运行，且不同版本需要的权限也可能不同。Operator Lifecycle Manager (OLM) 需要 cluster-admin 权限才可运行。默认情况下，Operator 作者可在集群服务版本（CSV）中指定任意权限集，OLM 之后会将其授予 Operator。
集群管理员应采取措施，确保 Operator 无法获得全集群权限，且用户不可使用 OLM 来提升权限。要实现这一目的的一种方法要求集群管理员在将 Operator 添加至集群之前先对其进行审核。集群管理员还可获得一些工具来决定和限制在使用服务账户安装或升级 Operator 期间允许的操作。
通过将 Operator 组与获得一组权限的服务账户相关联，集群管理员便可对 Operator 设定策略，以确保它们仅在预先决定的边界范围内按照 RBAC 规则运行。Operator 无法执行任何这些规则未明确允许的操作。
非集群管理员可自行安装 Operator 但范围有限，这一规定意味着更多 Operator Framework 工具可安全提供给更多用户，为通过 Operator 构建应用程序提供更丰富的体验。
4.7.1. 了解 Operator 安装策略
通过使用 OLM，集群管理员可选择为一个 OperatorGroup 指定一个服务账户，以便部署与这个 Operator 组相关联的所有 Operator，并按照服务账户获得的权限运行。
APIService 和 CustomResourceDefinition 资源都由 OLM 使用 cluster-admin 角色来创建。不应向与 Operator 组相关联的服务账户授予写入这些资源的权限。
如果指定的服务账户对于正在安装或升级的 Operator 没有足够权限，则会在相应资源状态中添加实用背景信息，以便集群管理员轻松排除故障并解决问题。
与该 Operator 组相关联的所有 Operator 现已被限制在指定服务账户获得的权限范围内。如果 Operator 请求了超出服务账户范围的权限，安装将会失败，并将显示相应错误。
4.7.1.1. 安装场景
在确定是否可在集群上安装或升级 Operator 时，Operator Lifecycle Manager（OLM）会考虑以下情况：
- 集群管理员新建了一个 Operator 组并指定了服务账户。已安装与该 Operator 组关联的所有 Operator，并根据相应服务账户获得的权限运行。
- 集群管理员新建了一个 Operator 组，且不指定任何服务帐户。OpenShift Container Platform 保持向后兼容性，因此会保留默认行为，并允许安装和升级 Operator。
- 对于未指定服务账户的现有 Operator 组，会保留默认行为,并允许安装和升级 Operator。
- 集群管理员更新了现有 Operator 组并指定了服务帐户。OLM 支持现有 Operator 继续根据当前权限运行。现有 Operator 升级后，它会重新安装并根据相应服务账户获得的权限运行，与新 Operator 一样。
- 由 Operator 组指定的服务帐户通过添加或删除权限来更改，或者现有服务账户被换为新服务帐户。现有 Operator 升级后，它会重新安装并根据更新后的服务账户获得的权限运行，与新 Operator 一样。
- 集群管理员从 Operator 组中删除服务账户。默认行为保留，并允许安装和升级 Operator。
4.7.1.2. 安装工作流
当 Operator 组与服务账户绑定，并且安装或升级了 Operator 时，Operator Lifecycle Manager（OLM）会使用以下工作流：
-
OLM 会提取给定
订阅对象。 - OLM 获取与该订阅相关联的 Operator 组。
- OLM 确定 Operator 组是否指定了服务帐户。
- OLM 在服务账户范围内创建一个客户端，并使用该范围内客户端来安装 Operator。这样可确保 Operator 请求的任何权限始终限制在 Operator 组中服务账户的权限范围内。
- OLM 新建一个服务账户，在 CSV 中指定其权限集，并将其分配至 Operator。Operator 将根据所分配的服务账户运行。
4.7.2. 限定 Operator 安装范围
要为 Operator Lifecycle Manager（OLM）上的 Operator 安装和升级提供范围规则，请将服务帐户与 Operator 组关联。
集群管理员可借鉴本例，将一组 Operator 限制到指定命名空间中。
流程
新建命名空间：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 分配 Operator 的权限范围。这涉及创建新服务帐户、相关角色和角色绑定。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 为简便起见，以下示例授予服务账户在指定命名空间进行任何操作的权限。在生产环境中，应创建更为精细的权限集：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在指定的命名空间中创建
OperatorGroup对象。该 Operator 组以指定的命名空间为目标，以确保其租期仅限于该命名空间。另外，Operator 组允许用户指定服务帐户。指定上一步中创建的服务帐户：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在指定命名空间中安装的任何 Operator 均会关联至此 Operator 组，因此也会关联到指定的服务账户。
在指定命名空间中创建
Subscription对象以安装 Operator:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 与该 Operator 组相关联的所有 Operator 都仅限于为指定服务账户授予的权限。如果 Operator 请求的权限超出服务账户范围，安装会失败并显示相关错误。
4.7.2.1. 细粒度权限
Operator Lifecycle Manager（OLM）使用 Operator 组中指定的服务账户来创建或更新与正在安装的 Operator 相关的以下资源：
-
ClusterServiceVersion -
Subscription -
Secret -
ServiceAccount -
Service -
ClusterRole和ClusterRoleBinding -
Role和RoleBinding
要将 Operator 限制到指定命名空间，集群管理员可以首先向服务账户授予以下权限：
以下角色只是一个通用示例，具体 Operator 可能需要额外规则。
另外，如果任何 Operator 指定了 pull secret，还必须增加以下权限：
- 1
- 需要从 OLM 命名空间中获取 secret。
4.7.3. 故障排除权限失败
如果因为缺少权限而导致 Operator 安装失败，请按照以下流程找出错误。
流程
查看
Subscription对象。其状态中有一个指向InstallPlan对象的对象引用installPlanRef，该对象试图为 Operator 创建需要的[Cluster]Role[Binding]：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 检查
InstallPlan对象的状态中的任何错误：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 错误信息中会显示：
-
创建失败的资源类型，包括资源的 API 组。本例中为
rbac.authorization.k8s.io组中的clusterroles。 - 资源名称。
-
错误类型：
is forbidden表明相应用户没有足够权限来执行这一操作。 - 试图创建或更新资源的用户名称。本例中指的是 Operator 组中指定的服务账户。
操作范围：
集群范围内或范围外。用户可在服务账户中增加所缺权限，然后迭代操作。
注意Operator Lifecycle Manager（OLM）目前未提供第一次尝试的完整错误列表。
-
创建失败的资源类型，包括资源的 API 组。本例中为
4.8. 管理自定义目录
本指南介绍了如何在 OpenShift Container Platform 的 Operator Lifecycle Manager (OLM) 中处理以 Bundle Format 或传统的 Bundle Format 打包的自定义目录。
4.8.1. 使用捆绑格式（Bundle Format）的自定义目录
4.8.1.1. 先决条件
-
安装
opmCLI。
4.8.1.2. 创建索引镜像
您可以使用 opm CLI 创建索引镜像。
先决条件
-
opm版本 1.12.3+ -
podman版本 1.9.3+ 构建并推送到支持 Docker v2-2 的 registry 的捆绑包镜像
重要OpenShift Container Platform 集群的内部 registry 不能用作目标 registry，因为它不支持没有标签的推送（在镜像过程中需要这个功能）。
流程
启动一个新的索引：
opm index add \ --bundles <registry>/<namespace>/<bundle_image_name>:<tag> \ --tag <registry>/<namespace>/<index_image_name>:<tag> \ [--binary-image <registry_base_image>]$ opm index add \ --bundles <registry>/<namespace>/<bundle_image_name>:<tag> \1 --tag <registry>/<namespace>/<index_image_name>:<tag> \2 [--binary-image <registry_base_image>]3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将索引镜像推送到 registry。
如果需要，与目标 registry 进行身份验证：
podman login <registry>
$ podman login <registry>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 推送索引镜像：
podman push <registry>/<namespace>/test-catalog:latest
$ podman push <registry>/<namespace>/test-catalog:latestCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.8.1.3. 从索引镜像创建目录
您可以从索引镜像创建 Operator 目录，并将其应用到 OpenShift Container Platform 集群，供 Operator Lifecycle Manager（OLM）使用。
先决条件
- 构建并推送到 registry 的索引镜像。
流程
创建一个
CatalogSource对象来引用索引镜像。根据您的规格修改以下内容，并将它保存为
catalogSource.yaml文件：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用该文件创建
CatalogSource对象：oc apply -f catalogSource.yaml
$ oc apply -f catalogSource.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
确定成功创建以下资源。
检查 pod:
oc get pods -n openshift-marketplace
$ oc get pods -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE my-operator-catalog-6njx6 1/1 Running 0 28s marketplace-operator-d9f549946-96sgr 1/1 Running 0 26h
NAME READY STATUS RESTARTS AGE my-operator-catalog-6njx6 1/1 Running 0 28s marketplace-operator-d9f549946-96sgr 1/1 Running 0 26hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查目录源：
oc get catalogsource -n openshift-marketplace
$ oc get catalogsource -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME DISPLAY TYPE PUBLISHER AGE my-operator-catalog My Operator Catalog grpc 5s
NAME DISPLAY TYPE PUBLISHER AGE my-operator-catalog My Operator Catalog grpc 5sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查软件包清单：
oc get packagemanifest -n openshift-marketplace
$ oc get packagemanifest -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME CATALOG AGE jaeger-product My Operator Catalog 93s
NAME CATALOG AGE jaeger-product My Operator Catalog 93sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
现在，您可以在 OpenShift Container Platform Web 控制台中通过 OperatorHub 安装 Operator。
4.8.1.4. 更新索引镜像
在将 OperatorHub 配置为使用引用自定义索引镜像的目录源后，集群管理员可通过将捆绑包镜像添加到索引镜像来保持其集群上的可用 Operator 最新状态。
您可以使用 opm index add 命令来更新存在的索引镜像。
先决条件
-
opm版本 1.12.3+ -
podman版本 1.9.3+ - 构建并推送到 registry 的索引镜像。
- 引用索引镜像的现有目录源。
流程
通过添加捆绑包镜像来更新现有索引：
opm index add \ --bundles <registry>/<namespace>/<new_bundle_image>@sha256:<digest> \ --from-index <registry>/<namespace>/<existing_index_image>:<existing_tag> \ --tag <registry>/<namespace>/<existing_index_image>:<updated_tag> \ --pull-tool podman$ opm index add \ --bundles <registry>/<namespace>/<new_bundle_image>@sha256:<digest> \1 --from-index <registry>/<namespace>/<existing_index_image>:<existing_tag> \2 --tag <registry>/<namespace>/<existing_index_image>:<updated_tag> \3 --pull-tool podman4 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中：
<registry>-
指定 registry 的主机名，如
quay.io或mirror.example.com。 <namespace>-
指定 registry 的命名空间，如
ocs-dev或abc。 <new_bundle_image>-
指定要添加到 registry 的新捆绑包镜像，如
ocs-operator。 <digest>-
指定捆绑包镜像的 SHA 镜像 ID 或摘要，如
c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41。 <existing_index_image>-
指定之前推送的镜像，如
abc-redhat-operator-index。 <existing_tag>-
指定之前推送的镜像标签，如
4.7。 <updated_tag>-
指定要应用到更新的索引镜像的镜像标签，如
4.7.1。
示例命令
opm index add \ --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \ --from-index mirror.example.com/abc/abc-redhat-operator-index:4.7 \ --tag mirror.example.com/abc/abc-redhat-operator-index:4.7.1 \ --pull-tool podman$ opm index add \ --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \ --from-index mirror.example.com/abc/abc-redhat-operator-index:4.7 \ --tag mirror.example.com/abc/abc-redhat-operator-index:4.7.1 \ --pull-tool podmanCopy to Clipboard Copied! Toggle word wrap Toggle overflow 推送更新的索引镜像：
podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>
$ podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Operator Lifecycle Manager（OLM）会在常规时间段内自动轮询目录源中引用的索引镜像，验证是否已成功添加新软件包：
oc get packagemanifests -n openshift-marketplace
$ oc get packagemanifests -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.8.1.5. 修剪索引镜像
基于 Operator Bundle Format 的索引镜像是 Operator 目录的容器化快照。您可以修剪除指定的软件包列表以外的所有索引，创建只包含您想要的 Operator 的源索引副本。
先决条件
-
podman版本 1.9.3+ -
grpcurl（第三方命令行工具） -
opm版本 1.18.0+ 访问支持 Docker v2-2 的 registry
重要OpenShift Container Platform 集群的内部 registry 不能用作目标 registry，因为它不支持没有标签的推送（在镜像过程中需要这个功能）。
流程
通过目标 registry 进行身份验证：
podman login <target_registry>
$ podman login <target_registry>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 确定您要包括在您的修剪索引中的软件包列表。
运行您要修剪容器中的源索引镜像。例如：
podman run -p50051:50051 \ -it registry.redhat.io/redhat/redhat-operator-index:v4.7$ podman run -p50051:50051 \ -it registry.redhat.io/redhat/redhat-operator-index:v4.7Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.7... Getting image source signatures Copying blob ae8a0c23f5b1 done ... INFO[0000] serving registry database=/database/index.db port=50051
Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.7... Getting image source signatures Copying blob ae8a0c23f5b1 done ... INFO[0000] serving registry database=/database/index.db port=50051Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在一个单独的终端会话中，使用
grpcurl命令获取由索引提供的软件包列表：grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out
$ grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.outCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查
package.out文件，确定要保留在此列表中的哪个软件包名称。例如：软件包列表片断示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
在您执行
podman run命令的终端会话中，按 Ctrl 和 C 停止容器进程。
运行以下命令来修剪指定软件包以外的所有源索引：
opm index prune \ -f registry.redhat.io/redhat/redhat-operator-index:v4.7 \ -p advanced-cluster-management,jaeger-product,quay-operator \ [-i registry.redhat.io/openshift4/ose-operator-registry:v4.7] \ -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.7$ opm index prune \ -f registry.redhat.io/redhat/redhat-operator-index:v4.7 \1 -p advanced-cluster-management,jaeger-product,quay-operator \2 [-i registry.redhat.io/openshift4/ose-operator-registry:v4.7] \3 -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.74 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令将新索引镜像推送到目标 registry:
podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.7
$ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.7Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中
<namespace>是 registry 上的任何现有命名空间。
4.8.2. 使用 Package Manifest Format 的自定义目录
4.8.2.1. 构建软件包清单格式目录镜像
集群管理员可以根据 Operator Lifecycle Manager（OLM）使用的 Package Manifest Format 来构建自定义 Operator 目录镜像。目录镜像可推送到支持 Docker v2-2 的容器镜像 registry。对于受限网络中的集群，此 registry 可以是集群有网络访问权限的 registry，如在受限网络集群安装过程中创建的镜像 registry。
OpenShift Container Platform 集群的内部 registry 不能用作目标 registry，因为它不支持没有标签的推送（在镜像过程中需要这个功能）。
在这一示例中，流程假定在使用镜像 registry 时可访问您的网络以及互联网。
只有 oc 客户端的 Linux 版本可用于此流程，因为 Windows 和 macOS 版本不提供 oc adm catalog build 命令。
先决条件
- 没有网络访问限制的工作站
-
oc版本 4.3.5+ Linux 客户端 -
podman版本 1.9.3+ - 访问支持 Docker v2-2 的镜像（mirror）registry
如果您正在使用私有 registry，请将
REG_CREDS环境变量设置为到 registry 凭证的文件路径。例如，对于podmanCLI:REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json$ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您正在使用 quay.io 帐户可访问的私有命名空间，您必须设置 Quay 身份验证令牌。使用您的 quay.io 凭证对登录 API 发出请求，从而设置用于
--auth-token标志的AUTH_TOKEN环境变量：Copy to Clipboard Copied! Toggle word wrap Toggle overflow
流程
在没有网络访问限制的工作站中，与目标镜像（mirror） registry 进行身份验证：
podman login <registry_host_name>
$ podman login <registry_host_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
registry.redhat.io进行身份验证，以便在构建期间拉取基础镜像：podman login registry.redhat.io
$ podman login registry.redhat.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 根据 Quay.io 中的
redhat-operators目录构建目录镜像，进行标记并将其推送到您的镜像 registry:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 从 App Registry 实例中拉取的机构（命名空间）。
- 2
- 使用与目标 OpenShift Container Platform 集群主版本和次版本匹配的标签将
--from设置为 Operator Registry 基础镜像。 - 3
- 将
--filter-by-os设置为用于基本镜像的操作系统和架构，该镜像必须与目标 OpenShift Container Platform 集群匹配。有效值是linux/amd64、linux/ppc64le和linux/s390x。 - 4
- 为您的目录镜像命名并包含标签，例如:
v1。 - 5
- 可选：如果需要，指定 registry 凭证文件的位置。
- 6
- 可选：如果您不想为目标 registry 配置信任，请添加
--insecure标志。 - 7
- 可选：如果使用其他不公开的应用程序 registry 目录，则需要指定 Quay 身份验证令牌。
输出示例
INFO[0013] loading Bundles dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605 ... Pushed sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3 to example_registry:5000/olm/redhat-operators:v1
INFO[0013] loading Bundles dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605 ... Pushed sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3 to example_registry:5000/olm/redhat-operators:v1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 有时红帽提供的无效清单是意外引入的目录 ; 当发生这种情况时，您可能会看到一些错误：
出错的输出示例
... INFO[0014] directory dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605 file=4.2 load=package W1114 19:42:37.876180 34665 builder.go:141] error building database: error loading package into db: fuse-camel-k-operator.v7.5.0 specifies replacement that couldn't be found Uploading ... 244.9kB/s
... INFO[0014] directory dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605 file=4.2 load=package W1114 19:42:37.876180 34665 builder.go:141] error building database: error loading package into db: fuse-camel-k-operator.v7.5.0 specifies replacement that couldn't be found Uploading ... 244.9kB/sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 这些错误通常不是致命的，如果所提及 Operator 软件包不包含您计划安装的 Operator 或其依赖项，则可以忽略它们。
4.8.2.2. 对 Package Manifest Format 目录镜像进行镜像(mirror)
集群管理员可以根据 Package Manifest Format 将自定义 Operator 目录镜像(mirror)到 registry 中，并使用目录源将内容加载到其集群中。本例中的流程使用之前构建并推送到受支持的 registry 的自定义 redhat-operators 目录镜像。
先决条件
- 没有网络访问限制的工作站
- 基于推送到受支持的 registry 的 Package Manifest Format 的自定义 Operator 目录镜像
-
oc版本 4.3.5+ -
podman版本 1.9.3+ 访问支持 Docker v2-2 的镜像（mirror）registry
重要OpenShift Container Platform 集群的内部 registry 不能用作目标 registry，因为它不支持没有标签的推送（在镜像过程中需要这个功能）。
如果您正在使用私有 registry，请将
REG_CREDS环境变量设置为到 registry 凭证的文件路径。例如，对于podmanCLI:REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json$ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow
流程
oc adm catalog mirror命令提取自定义 Operator catalog 镜像的内容，以生成镜像（mirror）所需的清单：您可以选择：- 允许该命令的默认行为在生成清单后自动将所有镜像内容镜像到您的镜像 registry 中，或者
-
添加
--manifests-only标志来只生成镜像所需的清单，但并不实际将镜像内容镜像到 registry。这对检查哪些要镜像（mirror）非常有用。如果您只需要部分内容的话，可以对映射列表做出任何修改。然后，您可以使用该文件与oc image mirror命令一起，在以后的步骤中镜像修改的镜像列表。
在没有网络访问限制的工作站中，运行以下命令：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
using database path mapping: /:/tmp/190214037 wrote database to /tmp/190214037 using database at: /tmp/190214037/bundles.db ...
using database path mapping: /:/tmp/190214037 wrote database to /tmp/190214037 using database at: /tmp/190214037/bundles.db1 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 命令生成的临时数据库。
运行完该命令后，会在当前目录中创建
manifests-<index_image_name>-<random_number>/目录并生成以下文件：-
catalogSource.yaml文件是CatalogSource对象的基本定义，它预先填充目录镜像标签及其他相关元数据。此文件可原样使用，或进行相应修改来在集群中添加目录源。 用来定义
ImageContentSourcePolicy对象的imageContentSourcePolicy.yaml，它可以将节点配置为在 Operator 清单中存储的镜像（image）引用和镜像 (mirror) 的 registry 间进行转换。注意如果您的集群使用
ImageContentSourcePolicy对象来配置存储库镜像，则只能将全局 pull secret 用于镜像 registry。您不能在项目中添加 pull secret。-
mapping.txt文件，在其中包含所有源镜像，并将它们映射到目标 registry。此文件与oc image mirror命令兼容，可用于进一步自定义镜像（mirror）配置。
如果您在上一步中使用
--manifests-only标志，并只想镜像部分内容：将
mapping.txt文件中的镜像列表改为您的规格。如果您不确定要镜像的镜像子集的名称和版本，请使用以下步骤查找：对
oc adm catalog mirror命令生成的临时数据库运行sqlite3工具，以检索与一般搜索查询匹配的镜像列表。输出以后如何编辑mapping.txt文件的帮助信息。例如，要检索与字符串
clusterlogging.4.3类似的镜像列表：echo "select * from related_image \ where operatorbundle_name like 'clusterlogging.4.3%';" \ | sqlite3 -line /tmp/190214037/bundles.db$ echo "select * from related_image \ where operatorbundle_name like 'clusterlogging.4.3%';" \ | sqlite3 -line /tmp/190214037/bundles.db1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 请参阅
oc adm catalog mirror命令的输出结果来查找数据库文件的路径。
输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用上一步的结果来编辑
mapping.txt文件，使其只包含您要镜像的镜像子集。例如，您可以使用前面示例输出中的
image值来找出您的mapping.txt文件中存在以下匹配行：mapping.txt中的匹配镜像映射registry.redhat.io/openshift-logging/kibana6-rhel8@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61=<registry_host_name>:<port>/kibana6-rhel8:a767c8f0 registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506=<registry_host_name>:<port>/openshift4-ose-oauth-proxy:3754ea2b
registry.redhat.io/openshift-logging/kibana6-rhel8@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61=<registry_host_name>:<port>/kibana6-rhel8:a767c8f0 registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506=<registry_host_name>:<port>/openshift4-ose-oauth-proxy:3754ea2bCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在这个示例中，如果您只想镜像这些 image，可以在
mapping.txt文件中删除所有其他条目，仅保留上述两行。
在您的没有网络访问限制的工作站中，使用您修改的
mapping.txt文件，使用oc image mirror命令将镜像镜像到 registry:oc image mirror \ [-a ${REG_CREDS}] \ --filter-by-os='.*' \ -f ./manifests-redhat-operators-<random_number>/mapping.txt$ oc image mirror \ [-a ${REG_CREDS}] \ --filter-by-os='.*' \ -f ./manifests-redhat-operators-<random_number>/mapping.txtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 警告如果未设置
--filter-by-os标志或设置为.*以外的任何值，该命令会过滤不同的架构，用来更改清单列表摘要，也称为 多架构镜像。不正确的摘要会导致在断开连接的集群中部署这些镜像和 Operator 失败。
创建
ImageContentSourcePolicy对象：oc create -f ./manifests-redhat-operators-<random_number>/imageContentSourcePolicy.yaml
$ oc create -f ./manifests-redhat-operators-<random_number>/imageContentSourcePolicy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
现在，您可以创建一个 CatalogSource 对象来引用您的镜像内容。
4.8.2.3. 更新软件包清单格式目录镜像
集群管理员将 OperatorHub 配置为使用自定义 Operator 目录镜像后，管理员可通过红帽提供的 App Registry 目录获得更新，使其 OpenShift Container Platform 集群与最新的 Operator 保持一致。这可以通过构建和推送新的 Operator 目录镜像，然后将 CatalogSource 对象中现有的 spec.image 参数替换为新镜像摘要。
在本例中，该流程假设已配置了自定义 redhat-operators 目录镜像，以便与 OperatorHub 搭配使用。
只有 oc 客户端的 Linux 版本可用于此流程，因为 Windows 和 macOS 版本不提供 oc adm catalog build 命令。
先决条件
- 没有网络访问限制的工作站
-
oc版本 4.3.5+ Linux 客户端 -
podman版本 1.9.3+ 访问支持 Docker v2-2 的镜像（mirror）registry
重要OpenShift Container Platform 集群的内部 registry 不能用作目标 registry，因为它不支持没有标签的推送（在镜像过程中需要这个功能）。
- OperatorHub 配置为使用自定义目录镜像
如果您正在使用私有 registry，请将
REG_CREDS环境变量设置为到 registry 凭证的文件路径。例如，对于podmanCLI:REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json$ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您正在使用 quay.io 帐户可访问的私有命名空间，您必须设置 Quay 身份验证令牌。使用您的 quay.io 凭证对登录 API 发出请求，从而设置用于
--auth-token标志的AUTH_TOKEN环境变量：Copy to Clipboard Copied! Toggle word wrap Toggle overflow
流程
在没有网络访问限制的工作站中，与目标镜像（mirror） registry 进行身份验证：
podman login <registry_host_name>
$ podman login <registry_host_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
registry.redhat.io进行身份验证，以便在构建期间拉取基础镜像：podman login registry.redhat.io
$ podman login registry.redhat.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 根据 Quay.io 中的
redhat-operators目录构建新目录镜像，标记并将其推送到您的镜像 registry:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 从 App Registry 实例中拉取的机构（命名空间）。
- 2
- 使用与目标 OpenShift Container Platform 集群主版本和次版本匹配的标签将
--from设置为 Operator Registry 基础镜像。 - 3
- 将
--filter-by-os设置为用于基本镜像的操作系统和架构，该镜像必须与目标 OpenShift Container Platform 集群匹配。有效值是linux/amd64、linux/ppc64le和linux/s390x。 - 4
- 为您的目录镜像命名并包含一个标签，例如:
v2，因为它是更新的目录。 - 5
- 可选：如果需要，指定 registry 凭证文件的位置。
- 6
- 可选：如果您不想为目标 registry 配置信任，请添加
--insecure标志。 - 7
- 可选：如果使用其他不公开的应用程序 registry 目录，则需要指定 Quay 身份验证令牌。
输出示例
INFO[0013] loading Bundles dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605 ... Pushed sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3 to example_registry:5000/olm/redhat-operators:v2
INFO[0013] loading Bundles dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605 ... Pushed sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3 to example_registry:5000/olm/redhat-operators:v2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将目录镜像 (mirror) 到目标 registry。以下
oc adm catalog mirror命令提取自定义 Operator catalog 镜像的内容，以生成镜像 (mirror) 和把镜像（image）镜像 (mirror)到 registry 所需的清单：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用新生成的清单：
oc replace -f ./manifests-redhat-operators-<random_number>
$ oc replace -f ./manifests-redhat-operators-<random_number>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要您可能不需要应用
imageContentSourcePolicy.yaml清单。对文件进行一个diff操作来决定是否需要改变。更新
CatalogSource对象以引用您的目录镜像。如果您有此
CatalogSource对象的原始catalogsource.yaml文件：编辑
catalogsource.yaml文件，在spec.image字段中引用新目录镜像 ：Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定新 Operator 目录镜像。
使用更新的文件替换
CatalogSource对象：oc replace -f catalogsource.yaml
$ oc replace -f catalogsource.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
或者，使用以下命令编辑目录源，在
spec.image参数中引用您的新目录镜像 ：oc edit catalogsource <catalog_source_name> -n openshift-marketplace
$ oc edit catalogsource <catalog_source_name> -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
现在，OpenShift Container Platform 集群上的 OperatorHub 页中应可以提供更新的 Operator。
4.8.2.4. 测试软件包清单格式目录镜像
要验证 Operator 目录镜像内容，您可以将其作为容器运行并查询其 gRPC API。要进一步测试镜像，您可以通过引用目录源中的镜像来在 Operator Lifecycle Manager（OLM）中解析订阅。本例中的流程使用之前构建并推送到受支持的 registry 的自定义 redhat-operators 目录镜像。
先决条件
- 推送到受支持的 registry 的自定义 Package Manifest Format 目录镜像
-
podman版本 1.9.3+ -
oc版本 4.3.5+ 访问支持 Docker v2-2 的镜像（mirror）registry
重要OpenShift Container Platform 集群的内部 registry 不能用作目标 registry，因为它不支持没有标签的推送（在镜像过程中需要这个功能）。
-
grpcurl
流程
拉取 Operator 目录镜像：
podman pull <registry_host_name>:<port>/olm/redhat-operators:v1
$ podman pull <registry_host_name>:<port>/olm/redhat-operators:v1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行镜像：
podman run -p 50051:50051 \ -it <registry_host_name>:<port>/olm/redhat-operators:v1$ podman run -p 50051:50051 \ -it <registry_host_name>:<port>/olm/redhat-operators:v1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
grpcurl查询正在运行的镜像中的可用软件包：grpcurl -plaintext localhost:50051 api.Registry/ListPackages
$ grpcurl -plaintext localhost:50051 api.Registry/ListPackagesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在频道中获取最新的 Operator 捆绑包：
grpcurl -plaintext -d '{"pkgName":"kiali-ossm","channelName":"stable"}' localhost:50051 api.Registry/GetBundleForChannel$ grpcurl -plaintext -d '{"pkgName":"kiali-ossm","channelName":"stable"}' localhost:50051 api.Registry/GetBundleForChannelCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
{ "csvName": "kiali-operator.v1.0.7", "packageName": "kiali-ossm", "channelName": "stable", ...{ "csvName": "kiali-operator.v1.0.7", "packageName": "kiali-ossm", "channelName": "stable", ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 获取镜像摘要：
podman inspect \ --format='{{index .RepoDigests 0}}' \ <registry_host_name>:<port>/olm/redhat-operators:v1$ podman inspect \ --format='{{index .RepoDigests 0}}' \ <registry_host_name>:<port>/olm/redhat-operators:v1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
example_registry:5000/olm/redhat-operators@sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3
example_registry:5000/olm/redhat-operators@sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3Copy to Clipboard Copied! Toggle word wrap Toggle overflow 假设命名空间
my-ns中存在一个支持您的 Operator 及其依赖项的 Operator 组，使用镜像摘要创建一个CatalogSource对象。例如：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建一个可从您的目录镜像解析最新可用
servicemeshoperator及其依赖项的订阅：Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.8.3. 从私有 registry 访问 Operator 的镜像
如果与 Operator Lifecycle Manager（OLM）管理的 Operator 相关的某些镜像托管在需要经过身份验证的容器镜像 registry（也称为私有 registry）中时，在默认情况下，OLM 和 OperatorHub 将无法拉取镜像。要启用访问权限，可以创建一个包含 registry 验证凭证的 pull secret。通过引用一个或多个目录源的 pull secret，OLM 可以处理将 secret 放置到 Operator 和目录命名空间中以允许进行安装。
Operator 或其 Operands 所需的其他镜像可能会需要访问私有 registry。对于这种情况，OLM 不处理将 secret 放置到目标租户命名空间中，但身份验证凭证可以添加到全局范围集群 pull secret 中，或单独的命名空间服务帐户中，以启用所需的访问权限。
在决定由 OLM 管理的 Operator 是否有适当的拉取访问权限时，应该考虑以下类型的镜像：
- 索引或目录镜像
-
CatalogSource对象可以引用索引镜像或目录镜像，这些镜像是作为托管在镜像 registry 中的容器镜像的目录源打包的。索引镜像使用 Bundle Format 并引用捆绑包镜像，而目录镜像使用 Package Manifest Format。如果索引或目录镜像托管在私有 registry 中，可以使用 secret 来启用拉取访问。 - 捆绑包镜像
- Operator 捆绑包镜像是元数据和清单，并被打包为容器镜像，代表 Operator 的一个特定版本。如果目录源中引用的任何捆绑包镜像托管在一个或多个私有 registry 中，可以使用一个 secret 来启用拉取（pull）访问。
- Operator 和 Operand 镜像
如果从目录源安装的 Operator 使用私有镜像，对于 Operator 镜像本身或它监视的 Operand 镜像之一，Operator 将无法安装，因为部署无法访问所需的 registry 身份验证。在目录源中引用 secret 不会使 OLM 将 secret 放置到安装 Operands 的目标租户命名空间中。
相反，身份验证详情被添加到
openshift-config命名空间中的全局集群 pull secret 中，该 secret 提供对集群上所有命名空间的访问。另外，如果不允许访问整个集群，则可将 pull secret 添加到目标租户命名空间的default服务帐户中。
先决条件
至少以下之一被托管在私有 registry 中：
- 一个索引镜像或目录镜像。
- 一个 Operator 捆绑包镜像。
- 一个 Operator 或 Operand 镜像。
流程
为每个必需的私有 registry 创建 secret。
登录到私有 registry 以创建或更新 registry 凭证文件：
podman login <registry>:<port>
$ podman login <registry>:<port>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意registry 凭证的文件路径可能会根据用于登录到 registry 的容器工具的不同而有所不同。对于
podmanCLI，默认位置为${XDG_RUNTIME_DIR}/containers/auth.json。对于dockerCLI，默认位置为/root/.docker/config.json。建议您为每个 secret 只包含一个 registry 的凭证，并在单独的 secret 中为多个 registry 管理凭证。后续步骤中的
CatalogSource可包括多个 secret，OpenShift Container Platform 会将这些 secret 合并为一个单独的虚拟凭证文件，以便在镜像拉取过程中使用。默认情况下，registry 凭证文件可以存储多个 registry 的详情。确认您的文件的当前内容。例如：
为两个 registry 存储凭证的文件
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 由于此文件用于后续步骤中创建 secret，请确保为每个文件只存储一个 registry 的详情。这可使用以下方法之一完成：
-
使用
podman logout <registry>命令为额外 registry 删除凭证，直到您只保留一个 registry。 编辑 registry 凭证文件，将 registry 详情分开以存储在多个文件中。例如：
为一个 registry 存储凭证的文件
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 为另一个 registry 存储凭证的文件
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
使用
在
openshift-marketplace命名空间中创建 secret，其中包含私有 registry 的身份验证凭证：oc create secret generic <secret_name> \ -n openshift-marketplace \ --from-file=.dockerconfigjson=<path/to/registry/credentials> \ --type=kubernetes.io/dockerconfigjson$ oc create secret generic <secret_name> \ -n openshift-marketplace \ --from-file=.dockerconfigjson=<path/to/registry/credentials> \ --type=kubernetes.io/dockerconfigjsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重复此步骤，为任何其他需要的私有 registry 创建额外的 secret，更新
--from-file标志以指定另一个 registry 凭证文件路径。
创建或更新现有的
CatalogSource对象以引用一个或多个 secret：Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 添加
spec.secrets部分并指定任何所需 secret。
如果订阅的 Operator 引用的任何 Operator 或 Operand 镜像需要访问私有 registry，您可以提供对集群中的所有命名空间或单独的目标租户命名空间的访问。
要访问集群中的所有命名空间，请将身份验证详情添加到
openshift-config命名空间中的全局集群 pull secret 中。警告集群资源必须调整为新的全局 pull secret，这样可暂时限制集群的可用性。
从全局 pull secret 中提取
.dockerconfigjson文件：oc extract secret/pull-secret -n openshift-config --confirm
$ oc extract secret/pull-secret -n openshift-config --confirmCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用所需私有 registry 或 registry 的身份验证凭证更新
.dockerconfigjson文件，并将它保存为新文件：cat .dockerconfigjson | \ jq --compact-output '.auths["<registry>:<port>/<namespace>/"] |= . + {"auth":"<token>"}' \ > new_dockerconfigjson$ cat .dockerconfigjson | \ jq --compact-output '.auths["<registry>:<port>/<namespace>/"] |= . + {"auth":"<token>"}' \1 > new_dockerconfigjsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
<registry>:<port> /<namespace>替换为私有 registry 的详情，将<token>替换为您的身份验证凭证。
使用新文件更新全局 pull secret：
oc set data secret/pull-secret -n openshift-config \ --from-file=.dockerconfigjson=new_dockerconfigjson$ oc set data secret/pull-secret -n openshift-config \ --from-file=.dockerconfigjson=new_dockerconfigjsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow
要更新单个命名空间，请向 Operator 的服务帐户添加一个 pull secret，以便在目标租户命名空间中访问该 Operator。
在租户命名空间中为
openshift-marketplace重新创建 secret：oc create secret generic <secret_name> \ -n <tenant_namespace> \ --from-file=.dockerconfigjson=<path/to/registry/credentials> \ --type=kubernetes.io/dockerconfigjson$ oc create secret generic <secret_name> \ -n <tenant_namespace> \ --from-file=.dockerconfigjson=<path/to/registry/credentials> \ --type=kubernetes.io/dockerconfigjsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 通过搜索租户命名空间来验证 Operator 的服务帐户名称：
oc get sa -n <tenant_namespace>
$ oc get sa -n <tenant_namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 如果 Operator 安装在单独的命名空间中，请搜索该命名空间。如果 Operator 已为所有命名空间安装，请搜索
openshift-operators命名空间。
输出示例
NAME SECRETS AGE builder 2 6m1s default 2 6m1s deployer 2 6m1s etcd-operator 2 5m18s
NAME SECRETS AGE builder 2 6m1s default 2 6m1s deployer 2 6m1s etcd-operator 2 5m18s1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 已安装的 etcd Operator 的服务帐户。
将 secret 链接到 Operator 的服务帐户：
oc secrets link <operator_sa> \ -n <tenant_namespace> \ <secret_name> \ --for=pull$ oc secrets link <operator_sa> \ -n <tenant_namespace> \ <secret_name> \ --for=pullCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.8.4. 禁用默认的 OperatorHub 源
在 OpenShift Container Platform 安装过程中，默认为 OperatorHub 配置由红帽和社区项目提供的源内容的 operator 目录。作为集群管理员，您可以禁用默认目录集。
流程
通过在
OperatorHub对象中添加disableAllDefaultSources: true 来禁用默认目录的源：oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'$ oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
或者，您可以使用 Web 控制台管理目录源。在 Administration → Cluster Settings → Global Configuration → OperatorHub 页面中，点 Sources 选项卡，其中可创建、删除、禁用和启用单独的源。
4.8.5. 删除自定义目录
作为集群管理员，您可以删除之前添加到集群中的自定义 Operator 目录，方法是删除相关的目录源。
流程
- 在 Web 控制台的 Administrator 视角中，导航至 Administration → Cluster Settings。
- 点 Global Configuration 选项卡，然后点 OperatorHub。
- 点 Sources 选项卡。
-
选择您要删除的目录的 Options 菜单
，然后点 Delete CatalogSource。
4.9. 在受限网络中使用 Operator Lifecycle Manager
对于在受限网络中安装的 OpenShift Container Platform 集群（也称为 断开连接的集群 ），Operator Lifecycle Manager（OLM）默认无法访问托管在远程 registry 上的红帽提供的 OperatorHub 源，因为这些远程源需要足够的互联网连接。
但是，作为集群管理员，如果您有一个有完全互联网访问的工作站，则仍可以让集群在受限网络中使用 OLM。工作站需要完全访问互联网来拉取远程 OperatorHub 内容，用于准备远程源的本地镜像，并将内容推送到镜像 registry。
镜像 registry 可以位于堡垒主机上，它需要连接到您的工作站和断开连接的集群，或者一个完全断开连接的或 airgapped 主机，这需要可移动介质物理将镜像内容移到断开连接的环境中。
本指南描述了在受限网络中启用 OLM 所需的流程：
- 为 OLM 禁用默认远程 OperatorHub 源。
- 使用有完全互联网访问的工作站来创建并推送 OperatorHub 内容的本地镜像到镜像 registry。
- 将 OLM 配置为从镜像 registry 上的本地源而不是默认的远程源安装和管理 Operator。
在受限网络中启用 OLM 后，您可以继续使用不受限制的工作站在发布新版 Operator 时保持本地 OperatorHub 源的更新。
虽然 OLM 可以从本地源管理 Operator，但给定 Operator 在受限网络中能否成功运行仍取决于 Operator 本身。Operator 必须：
-
在
ClusterServiceVersion(CSV) 对象的relatedImages参数中列出所有相关的镜像，或 Operator 执行时可能需要的其他容器镜像。 - 通过摘要 (SHA) 而不是标签来引用所有指定的镜像。
如需了解在断开连接的模式模中可以运行的 Operator 列表，请参阅以下红帽知识库文章：
4.9.1. 先决条件
-
以具有
cluster-admin权限的用户身份登录 OpenShift Container Platform 集群。 -
如果要修剪默认目录，且只有选择地镜像部分 Operator，请安装
opmCLI。
如果您在 IBM Z 上的受限网络中使用 OLM，则必须至少为放置 registry 的目录分配 12 GB 的存储空间。
4.9.2. 禁用默认的 OperatorHub 源
在 OpenShift Container Platform 安装过程中，默认为 OperatorHub 配置由红帽和社区项目提供的源内容的 operator 目录。在受限网络环境中，必须以集群管理员身份禁用默认目录。然后，您可以将 OperatorHub 配置为使用本地目录源。
流程
通过在
OperatorHub对象中添加disableAllDefaultSources: true 来禁用默认目录的源：oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'$ oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
或者，您可以使用 Web 控制台管理目录源。在 Administration → Cluster Settings → Global Configuration → OperatorHub 页面中，点 Sources 选项卡，其中可创建、删除、禁用和启用单独的源。
4.9.3. 修剪索引镜像
基于 Operator Bundle Format 的索引镜像是 Operator 目录的容器化快照。您可以修剪除指定的软件包列表以外的所有索引，创建只包含您想要的 Operator 的源索引副本。
当将 Operator Lifecycle Manager（OLM）配置为在受限网络 OpenShift Container Platform 集群上使用镜像内容时，如果您只想从默认目录中镜像一部分 Operator，请使用此修剪方法。
对于此过程中的步骤，目标 registry 是一个存在的镜像 registry，您的具有无限网络访问权限的工作站可以访问该 registry。本例还显示修剪默认 redhat-operators 目录的索引镜像，但所有索引镜像的过程都是一样的。
先决条件
- 没有网络访问限制的工作站
-
podman版本 1.9.3+ -
grpcurl（第三方命令行工具） -
opm版本 1.18.0+ 访问支持 Docker v2-2 的 registry
重要OpenShift Container Platform 集群的内部 registry 不能用作目标 registry，因为它不支持没有标签的推送（在镜像过程中需要这个功能）。
流程
通过
registry.redhat.io进行身份验证：podman login registry.redhat.io
$ podman login registry.redhat.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 通过目标 registry 进行身份验证：
podman login <target_registry>
$ podman login <target_registry>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 确定您要包括在您的修剪索引中的软件包列表。
运行您要修剪容器中的源索引镜像。例如：
podman run -p50051:50051 \ -it registry.redhat.io/redhat/redhat-operator-index:v4.7$ podman run -p50051:50051 \ -it registry.redhat.io/redhat/redhat-operator-index:v4.7Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.7... Getting image source signatures Copying blob ae8a0c23f5b1 done ... INFO[0000] serving registry database=/database/index.db port=50051
Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.7... Getting image source signatures Copying blob ae8a0c23f5b1 done ... INFO[0000] serving registry database=/database/index.db port=50051Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在一个单独的终端会话中，使用
grpcurl命令获取由索引提供的软件包列表：grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out
$ grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.outCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查
package.out文件，确定要保留在此列表中的哪个软件包名称。例如：软件包列表片断示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
在您执行
podman run命令的终端会话中，按 Ctrl 和 C 停止容器进程。
运行以下命令来修剪指定软件包以外的所有源索引：
opm index prune \ -f registry.redhat.io/redhat/redhat-operator-index:v4.7 \ -p advanced-cluster-management,jaeger-product,quay-operator \ [-i registry.redhat.io/openshift4/ose-operator-registry:v4.7] \ -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.7$ opm index prune \ -f registry.redhat.io/redhat/redhat-operator-index:v4.7 \1 -p advanced-cluster-management,jaeger-product,quay-operator \2 [-i registry.redhat.io/openshift4/ose-operator-registry:v4.7] \3 -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.74 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令将新索引镜像推送到目标 registry:
podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.7
$ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.7Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中
<namespace>是 registry 上的任何现有命名空间。例如，您可以创建一个olm-mirror命名空间来将所有镜像的内容推送到。
4.9.4. 对 Operator 目录进行镜像(mirror)
您可以使用 oc adm catalog mirror 命令将红帽提供的目录或自定义目录的 Operator 内容镜像到容器镜像 registry 中。目标 registry 必须支持 Docker v2-2。对于受限网络中的集群，此 registry 可以是集群有网络访问权限的 registry，如在受限网络集群安装过程中创建的镜像 registry。
OpenShift Container Platform 集群的内部 registry 不能用作目标 registry，因为它不支持没有标签的推送（在镜像过程中需要这个功能）。
oc adm catalog mirror 命令还会自动将在镜像过程中指定的索引镜像（无论是红帽提供的索引镜像还是您自己的自定义构建索引镜像）镜像到目标 registry。然后，您可以使用镜像的索引镜像创建一个目录源，允许 Operator Lifecycle Manager（OLM）将镜像目录加载到 OpenShift Container Platform 集群。
先决条件
- 没有网络访问限制的工作站
-
podman1.9.3 或更高版本。 - 访问支持 Docker v2-2 的镜像 registry。
-
决定镜像 registry 上用于存储已镜像 Operator 内容的镜像 registry 内容。例如，您可以创建一个
olm-mirror命名空间。 - 如果您的镜像 registry 无法访问互联网，请将可移动介质连接到您的没有网络访问限制的工作站。
如果您正在使用私有 registry，包括
registry.redhat.io，请将REG_CREDS环境变量设置为 registry 凭证的文件路径，以便在后续步骤中使用。例如，对于podmanCLI:REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json$ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow
流程
如果要镜像红帽提供的目录，请在具有无网络访问限制的工作站中运行以下命令，以便与
registry.redhat.io进行身份验证：podman login registry.redhat.io
$ podman login registry.redhat.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm catalog mirror命令提取索引镜像的内容，以生成镜像所需的清单。命令的默认行为会生成清单，然后会自动将索引镜像以及索引镜像本身中的所有镜像内容镜像（mirror）到您的镜像 registry。另外，如果您的镜像 registry 位于完全断开连接的主机上，或者断开连接的或 airgapped 主机上，您可以首先将内容镜像到可移动介质，将介质移到断开连接的环境中，然后将内容从介质镜像到 registry。选项 A: 如果您的镜像 registry 与您的没有网络访问限制的工作站位于同一个网络中，请在您的工作站中执行以下操作：
如果您的镜像 registry 需要身份验证，请运行以下命令登录到 registry:
podman login <mirror_registry>
$ podman login <mirror_registry>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令镜像内容：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定您要镜像的目录的索引镜像。例如，这可能是之前创建的已修剪索引镜像，也可以是默认目录的源索引镜像之一，如
registry.redhat.io/redhat/redhat-operator-index:v4.7。 - 2
- 指定要将 Operator 内容镜像到的目标 registry 和命名空间的完全限定域名(FQDN)，其中
<namespace>是 registry 上的任何现有命名空间。例如，您可以创建一个olm-mirror命名空间来将所有镜像的内容推送到。 - 3
- 可选：如果需要，指定 registry 凭证文件的位置。
registry.redhat.io需要{REG_CREDS}。 - 4
- 可选：如果您不想为目标 registry 配置信任，请添加
--insecure标志。 - 5
- 可选：在有多个变体可用时，指定索引镜像的平台和架构。镜像被传递为
'<platform>/<arch>[/<variant>]'。这不适用于索引引用的镜像。有效值是linux/amd64、linux/ppc64le和linux/s390x。 - 6
- 可选：只生成镜像所需的清单，但并不实际将镜像内容镜像到 registry。这个选项对检查哪些将被镜像（mirror）非常有用，如果您只需要一小部分软件包，可以对映射列表进行修改。然后，您可以使用带有
oc image mirror命令的mapping.txt文件来在以后的步骤中镜像修改的镜像列表。此标志仅用于从目录中对内容进行高级选择性镜像；opm index prune命令适用于大多数目录管理用例，如果之前用来修剪索引镜像。
输出示例
src image has index label for database path: /database/index.db using database path mapping: /database/index.db:/tmp/153048078 wrote database to /tmp/153048078 ... wrote mirroring manifests to manifests-redhat-operator-index-1614211642
src image has index label for database path: /database/index.db using database path mapping: /database/index.db:/tmp/153048078 wrote database to /tmp/1530480781 ... wrote mirroring manifests to manifests-redhat-operator-index-16142116422 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意Red Hat Quay 不支持嵌套存储库。因此，运行
oc adm catalog mirror命令会失败，并显示401未授权错误。作为临时解决方案，您可以在运行oc adm catalog mirror命令时使用--max-components=2选项来禁用嵌套存储库的创建。有关这个临时解决方案的更多信息，请参阅使用带有 Quay registry 知识库文章的 catalog mirror 命令时出现 Unauthorized 错误。
选项 B：如果您的镜像 registry 位于断开连接的主机上，请执行以下操作。
在您的工作站中运行以下命令，且没有网络访问权限将内容镜像到本地文件中：
oc adm catalog mirror \ <index_image> \ file:///local/index \ [-a ${REG_CREDS}] \ [--insecure]$ oc adm catalog mirror \ <index_image> \1 file:///local/index \2 [-a ${REG_CREDS}] \ [--insecure]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
将当前目录中生成的
v2/目录复制到可移动介质中。 - 物理删除该介质并将其附加到断开连接的环境中可访问镜像 registry 的主机。
如果您的镜像 registry 需要身份验证，请在断开连接的环境中的主机上运行以下命令以登录到 registry：
podman login <mirror_registry>
$ podman login <mirror_registry>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 从包含
v2/目录的父目录运行以下命令，将镜像从本地文件上传到镜像 registry：oc adm catalog mirror \ file://local/index/<repo>/<index_image>:<tag> \ <mirror_registry>:<port>/<namespace> \ [-a ${REG_CREDS}] \ [--insecure]$ oc adm catalog mirror \ file://local/index/<repo>/<index_image>:<tag> \1 <mirror_registry>:<port>/<namespace> \2 [-a ${REG_CREDS}] \ [--insecure]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意Red Hat Quay 不支持嵌套存储库。因此，运行
oc adm catalog mirror命令会失败，并显示401未授权错误。作为临时解决方案，您可以在运行oc adm catalog mirror命令时使用--max-components=2选项来禁用嵌套存储库的创建。有关这个临时解决方案的更多信息，请参阅使用带有 Quay registry 知识库文章的 catalog mirror 命令时出现 Unauthorized 错误。再次运行
oc adm catalog mirror命令。使用新镜像的索引镜像作为源，以及上一步中与目标相同的镜像 registry 命名空间：Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 此步骤需要
--manifests-only标志，以便该命令不会再次复制所有镜像的内容。
重要这一步是必需的，因为上一步中生成的
imageContentSourcePolicy.yaml文件中的镜像映射必须从本地路径更新为有效的镜像位置。如果不这样做，会在稍后的步骤中创建ImageContentSourcePolicy对象时会导致错误。
将内容镜像到 registry 后，检查当前目录中生成的清单目录。
注意清单目录名会在以后的步骤中使用。
如果您在上一步中将内容镜像到同一网络上的 registry，则目录名称采用以下格式：
manifests-<index_image_name>-<random_number>
manifests-<index_image_name>-<random_number>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您在上一步中将内容镜像到断开连接的主机上的 registry，则目录名称采用以下格式：
manifests-index/<namespace>/<index_image_name>-<random_number>
manifests-index/<namespace>/<index_image_name>-<random_number>Copy to Clipboard Copied! Toggle word wrap Toggle overflow manifests 目录包含以下文件，其中的一些文件可能需要进一步修改：
catalogSource.yaml文件是CatalogSource对象的基本定义，它预先填充索引镜像标签及其他相关元数据。此文件可原样使用，或进行相应修改来在集群中添加目录源。重要如果将内容镜像到本地文件，您必须修改 catalogSource
.yaml文件，从metadata.name字段中删除任何反斜杠(/)字符。否则，当您试图创建对象时，会失败并显示 "invalid resource name” 错误。用来定义
ImageContentSourcePolicy对象的imageContentSourcePolicy.yaml，它可以将节点配置为在 Operator 清单中存储的镜像（image）引用和镜像 (mirror) 的 registry 间进行转换。注意如果您的集群使用
ImageContentSourcePolicy对象来配置存储库镜像，则只能将全局 pull secret 用于镜像 registry。您不能在项目中添加 pull secret。mapping.txt文件，在其中包含所有源镜像，并将它们映射到目标 registry。此文件与oc image mirror命令兼容，可用于进一步自定义镜像（mirror）配置。重要如果您在镜像过程中使用
--manifests-only标志，并希望进一步调整要镜像的软件包子集，请参阅"镜像软件包清单格式目录镜像"中有关修改mapping.txt文件的步骤，并使用oc image mirror命令使用该文件。在进行了这些操作后，您可以继续这个过程。
在可访问断开连接的集群的主机上，运行以下命令来指定 manifests 目录中的
imageContentSourcePolicy.yaml文件，创建ImageContentSourcePolicy(ICSP) 对象：oc create -f <path/to/manifests/dir>/imageContentSourcePolicy.yaml
$ oc create -f <path/to/manifests/dir>/imageContentSourcePolicy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 其中
<path/to/manifests/dir>是镜像内容的 manifests 目录的路径。注意应用 ICSP 会导致集群中的所有 worker 节点重启。在继续操作前，您必须等待此重启过程完成每个 worker 节点的循环。
现在，您可以创建一个 CatalogSource 来引用您的镜像索引镜像和 Operator 内容。
4.9.5. 从索引镜像创建目录
您可以从索引镜像创建 Operator 目录，并将其应用到 OpenShift Container Platform 集群，供 Operator Lifecycle Manager（OLM）使用。
先决条件
- 构建并推送到 registry 的索引镜像。
流程
创建一个
CatalogSource对象来引用索引镜像。如果使用oc adm catalog mirror命令将目录镜像到目标 registry，您可以使用生成的catalogSource.yaml文件作为起点。根据您的规格修改以下内容，并将它保存为
catalogSource.yaml文件：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用该文件创建
CatalogSource对象：oc apply -f catalogSource.yaml
$ oc apply -f catalogSource.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
确定成功创建以下资源。
检查 pod:
oc get pods -n openshift-marketplace
$ oc get pods -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE my-operator-catalog-6njx6 1/1 Running 0 28s marketplace-operator-d9f549946-96sgr 1/1 Running 0 26h
NAME READY STATUS RESTARTS AGE my-operator-catalog-6njx6 1/1 Running 0 28s marketplace-operator-d9f549946-96sgr 1/1 Running 0 26hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查目录源：
oc get catalogsource -n openshift-marketplace
$ oc get catalogsource -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME DISPLAY TYPE PUBLISHER AGE my-operator-catalog My Operator Catalog grpc 5s
NAME DISPLAY TYPE PUBLISHER AGE my-operator-catalog My Operator Catalog grpc 5sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查软件包清单：
oc get packagemanifest -n openshift-marketplace
$ oc get packagemanifest -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME CATALOG AGE jaeger-product My Operator Catalog 93s
NAME CATALOG AGE jaeger-product My Operator Catalog 93sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
现在，您可以在 OpenShift Container Platform Web 控制台中通过 OperatorHub 安装 Operator。
4.9.6. 更新索引镜像
在将 OperatorHub 配置为使用引用自定义索引镜像的目录源后，集群管理员可通过将捆绑包镜像添加到索引镜像来保持其集群上的可用 Operator 最新状态。
您可以使用 opm index add 命令来更新存在的索引镜像。对于受限网络，还必须将更新的内容重新镜像到集群。
先决条件
-
opm版本 1.12.3+ -
podman版本 1.9.3+ - 构建并推送到 registry 的索引镜像。
- 引用索引镜像的现有目录源。
流程
通过添加捆绑包镜像来更新现有索引：
opm index add \ --bundles <registry>/<namespace>/<new_bundle_image>@sha256:<digest> \ --from-index <registry>/<namespace>/<existing_index_image>:<existing_tag> \ --tag <registry>/<namespace>/<existing_index_image>:<updated_tag> \ --pull-tool podman$ opm index add \ --bundles <registry>/<namespace>/<new_bundle_image>@sha256:<digest> \1 --from-index <registry>/<namespace>/<existing_index_image>:<existing_tag> \2 --tag <registry>/<namespace>/<existing_index_image>:<updated_tag> \3 --pull-tool podman4 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中：
<registry>-
指定 registry 的主机名，如
quay.io或mirror.example.com。 <namespace>-
指定 registry 的命名空间，如
ocs-dev或abc。 <new_bundle_image>-
指定要添加到 registry 的新捆绑包镜像，如
ocs-operator。 <digest>-
指定捆绑包镜像的 SHA 镜像 ID 或摘要，如
c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41。 <existing_index_image>-
指定之前推送的镜像，如
abc-redhat-operator-index。 <existing_tag>-
指定之前推送的镜像标签，如
4.7。 <updated_tag>-
指定要应用到更新的索引镜像的镜像标签，如
4.7.1。
示例命令
opm index add \ --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \ --from-index mirror.example.com/abc/abc-redhat-operator-index:4.7 \ --tag mirror.example.com/abc/abc-redhat-operator-index:4.7.1 \ --pull-tool podman$ opm index add \ --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \ --from-index mirror.example.com/abc/abc-redhat-operator-index:4.7 \ --tag mirror.example.com/abc/abc-redhat-operator-index:4.7.1 \ --pull-tool podmanCopy to Clipboard Copied! Toggle word wrap Toggle overflow 推送更新的索引镜像：
podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>
$ podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 按照镜像 Operator 目录流程中的步骤来镜像更新的内容。但是，当进入创建
ImageContentSourcePolicy（ICSP）对象的步骤时，请使用oc replace命令而不是oc create命令。例如：oc replace -f ./manifests-redhat-operator-index-<random_number>/imageContentSourcePolicy.yaml
$ oc replace -f ./manifests-redhat-operator-index-<random_number>/imageContentSourcePolicy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 这一更改是必需的，因为对象已存在且必须更新。
注意通常，
oc apply命令可用于更新之前使用oc apply创建的现有对象。但是，由于有关 ICSP 对象中的metadata.annotations字段大小的已知问题，oc replace命令当前必须用于此步骤。Operator Lifecycle Manager（OLM）会在常规时间段内自动轮询目录源中引用的索引镜像，验证是否已成功添加新软件包：
oc get packagemanifests -n openshift-marketplace
$ oc get packagemanifests -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第 5 章 开发 Operator
5.1. 关于 Operator SDK
Operator Framework 是一个开源工具包，用于以有效、自动化且可扩展的方式管理 Kubernetes 原生应用程序，即 Operator。Operator 利用 Kubernetes 的可扩展性来展现云服务的自动化优势，如置备、扩展以及备份和恢复，同时能够在 Kubernetes 可运行的任何地方运行。
Operator 有助于简化对 Kubernetes 上的复杂、有状态的应用程序的管理。然而，现在编写 Operator 并不容易，会面临一些挑战，如使用低级别 API、编写样板文件以及缺乏模块化功能（这会导致重复工作）。
Operator SDK 是 Operator Framework 的一个组件，它提供了一个命令行界面（CLI）工具，供 Operator 开发人员用来构建、测试和部署 Operator。
为什么使用 Operator SDK?
Operator SDK 简化了这一构建 Kubernetes 原生应用程序的过程，它需要深入掌握特定于应用程序的操作知识。Operator SDK 不仅降低了这一障碍，而且有助于减少许多常见管理功能（如 metering 或监控）所需的样板代码量。
Operator SDK 是一个框架，它使用 controller-runtime 库来简化 Operator 的编写，并具有以下特色：
- 高级 API 和抽象，用于更直观地编写操作逻辑
- 支架和代码生成工具，用于快速引导新项目
- 与 Operator Lifecycle Manager（OLM）集成，简化了集群上的打包、安装和运行的 Operator
- 扩展项，覆盖常见的 Operator 用例
- 指标（metrics）在基于 Go 的 Operator 中自动设置，用于部署 Prometheus Operator 的集群
具有集群管理员访问权限的 operator 作者（如 OpenShift Container Platform）可以使用 Operator SDK CLI 根据 Go、Ansible 或 Helm 开发自己的 Operator。Kubebuilder 作为基于 Go 的 Operator 的构建解决方案嵌入到 Operator SDK 中，这意味着现有的 Kubebuilder 项目可以象 Operator SDK 一样使用并继续工作。
OpenShift Container Platform 4.7 支持 Operator SDK v1.3.0 或更高版本。
5.1.1. 什么是 Operator?
有关基本 Operator 概念和术语的概述，请参阅了解 Operator。
5.1.2. 开发工作流
Operator SDK 提供以下工作流来开发新的 Operator：
- 使用 Operator SDK 命令行界面（CLI）创建 Operator 项目。
- 通过添加自定义资源定义 (CRD) 来定义新的资源 API。
- 使用 Operator SDK API 指定要监视的资源。
- 在指定的处理程序中定义 Operator 协调逻辑，并使用 Operator SDK API 与资源交互。
- 使用 Operator SDK CLI 来构建和生成 Operator 部署清单。
图 5.1. Operator SDK 工作流
在高级别上，使用 Operator SDK 的 Operator 会在 Operator 作者定义的处理程序中处理与被监视资源相关的事件，并采取措施协调应用程序的状态。
5.2. 安装 Operator SDK CLI
Operator SDK 提供了一个命令行界面（CLI）工具，Operator 开发人员可使用它来构建、测试和部署 Operator。您可以在工作站上安装 Operator SDK CLI，以便准备开始编写自己的 Operator。
OpenShift Container Platform 4.7 支持 Operator SDK v1.3.0。
5.2.1. 安装 Operator SDK CLI
您可以在 Linux 上安装 OpenShift SDK CLI 工具。
先决条件
- Go v1.13+
-
dockerv17.03+、podmanv1.9.3+ 或buildahv1.7+
流程
- 导航到 OpenShift 镜像站点。
-
在
4.7.23目录中下载 Linux 的 tarball 的最新版本。 解包存档：
tar xvf operator-sdk-v1.3.0-ocp-linux-x86_64.tar.gz
$ tar xvf operator-sdk-v1.3.0-ocp-linux-x86_64.tar.gzCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使文件可执行：
chmod +x operator-sdk
$ chmod +x operator-sdkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将提取的
operator-sdk二进制文件移到PATH中的一个目录中。提示检查
PATH：echo $PATH
$ echo $PATHCopy to Clipboard Copied! Toggle word wrap Toggle overflow sudo mv ./operator-sdk /usr/local/bin/operator-sdk
$ sudo mv ./operator-sdk /usr/local/bin/operator-sdkCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
安装 Operator SDK CLI 后，验证它是否可用：
operator-sdk version
$ operator-sdk versionCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
operator-sdk version: "v1.3.0-ocp", ...
operator-sdk version: "v1.3.0-ocp", ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. 基于 Go 的 Operator
5.3.1. 基于 Go 的 Operator 开始使用 Operator SDK
如需演示使用 Operator SDK 提供的工具和库来设置和运行基于 Go 的 Operator 的基本知识，Operator 开发人员可以为 Memcached 构建 Go-based Operator 示例，一个分布式键值存储，并将它部署到集群中。
5.3.1.1. 先决条件
- 已安装 operator SDK CLI
-
已安装 OpenShift CLI（
oc）v4.7+ -
使用具有
cluster-admin权限的oc登录到 OpenShift Container Platform 4.7 集群 - 要允许集群拉取镜像，推送镜像的存储库必须设置为公共的存储库，或必须配置一个镜像 pull secret。
5.3.1.2. 创建并部署基于 Go 的 Operator
您可以使用 Operator SDK 为 Memcached 构建和部署简单的 Go-based Operator。
流程
创建一个项目。
创建您的项目目录：
mkdir memcached-operator
$ mkdir memcached-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 切换到项目所在的目录：
cd memcached-operator
$ cd memcached-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行
operator-sdk init命令以初始化项目：operator-sdk init \ --domain=example.com \ --repo=github.com/example-inc/memcached-operator$ operator-sdk init \ --domain=example.com \ --repo=github.com/example-inc/memcached-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 命令默认使用 Go 插件。
要启用基于 Go 的 Operator 在 OpenShift Container Platform 上运行，编辑
config/manager/manager.yaml文件并替换以下行：runAsUser: 65532
runAsUser: 65532Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用：
runAsNonRoot: true
runAsNonRoot: trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意此步骤只是针对 Go 的 Operator 的一个临时解决方案。如需更多信息，请参阅 BZ#1914406。
创建 API。
创建简单的 Memcached API：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 构建并推送 Operator 镜像。
使用默认的
Makefile目标来构建和推送 Operator。使用镜像的 pull spec 设置IMG，该 spec 使用您可推送到的 registry：make docker-build docker-push IMG=<registry>/<user>/<image_name>:<tag>
$ make docker-build docker-push IMG=<registry>/<user>/<image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行 Operator。
安装 CRD：
make install
$ make installCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将项目部署到集群中。将
IMG设置为您推送的镜像：make deploy IMG=<registry>/<user>/<image_name>:<tag>
$ make deploy IMG=<registry>/<user>/<image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
创建示例自定义资源（CR）。
创建一个示例 CR：
oc apply -f config/samples/cache_v1_memcached.yaml \ -n memcached-operator-system$ oc apply -f config/samples/cache_v1_memcached.yaml \ -n memcached-operator-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 查看 CR 协调 Operator：
oc logs deployment.apps/memcached-operator-controller-manager \ -c manager \ -n memcached-operator-system$ oc logs deployment.apps/memcached-operator-controller-manager \ -c manager \ -n memcached-operator-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow
清理。
运行以下命令清理在此流程中创建的资源：
make undeploy
$ make undeployCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.1.3. 后续步骤
- 如需更深入地了解如何构建基于 Go 的 Operator，请参阅基于 Go 的 Operator SDK 指南。
5.3.2. 基于 Go 的 Operator 的 operator SDK 指南
Operator SDK 中的 Go 编程语言支持可以利用 Operator SDK 中的 Go 编程语言支持，为 Memcached 构建基于 Go 的 Operator 示例、分布式键值存储并管理其生命周期。
通过以下两个 Operator Framework 核心组件来完成此过程：
- Operator SDK
-
operator-sdkCLI 工具和controller-runtime库 API - Operator Lifecycle Manager (OLM)
- 集群中 Operator 的安装、升级和基于角色的访问控制（RBAC）
本教程的内容比基于 Go 的 Operator 开始使用 Operator SDK 更详细。
5.3.2.1. 先决条件
- 已安装 operator SDK CLI
-
已安装 OpenShift CLI（
oc）v4.7+ -
使用具有
cluster-admin权限的oc登录到 OpenShift Container Platform 4.7 集群 - 要允许集群拉取镜像，推送镜像的存储库必须设置为公共的存储库，或必须配置一个镜像 pull secret。
5.3.2.2. 创建一个项目
使用 Operator SDK CLI 创建名为 memcached-operator 的 项目。
流程
为项目创建一个目录：
mkdir -p $HOME/projects/memcached-operator
$ mkdir -p $HOME/projects/memcached-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 进入该目录：
cd $HOME/projects/memcached-operator
$ cd $HOME/projects/memcached-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 激活对 Go 模块的支持：
export GO111MODULE=on
$ export GO111MODULE=onCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行
operator-sdk init命令以初始化项目：operator-sdk init \ --domain=example.com \ --repo=github.com/example-inc/memcached-operator$ operator-sdk init \ --domain=example.com \ --repo=github.com/example-inc/memcached-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意operator-sdk init命令默认使用 Go 插件。operator-sdk init命令生成一个go.mod文件，用于 Go 模块。在创建$GOPATH/src/项目时需要--repo标志，因为生成的文件需要有效的模块路径。要启用基于 Go 的 Operator 在 OpenShift Container Platform 上运行，编辑
config/manager/manager.yaml文件并替换以下行：runAsUser: 65532
runAsUser: 65532Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用：
runAsNonRoot: true
runAsNonRoot: trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意此步骤只是针对 Go 的 Operator 的一个临时解决方案。如需更多信息，请参阅 BZ#1914406。
5.3.2.2.1. PROJECT 文件
operator-sdk init 命令生成的文件中是一个 Kubebuilder PROJECT 文件。从项目 root 运行的后续 operator-sdk 命令以及 help 输出会读取该文件，并注意到项目的类型为 Go。例如：
5.3.2.2.2. 关于 Manager
Operator 的主要程序是 main.go 文件，它初始化并运行 Manager。Manager 会自动注册所有自定义资源（CR）API 定义的方案，并设置和运行控制器和 webhook。
Manager 可以限制所有控制器监视资源的命名空间：
mgr, err := ctrl.NewManager(cfg, manager.Options{Namespace: namespace})
mgr, err := ctrl.NewManager(cfg, manager.Options{Namespace: namespace})
默认情况下， Manager 会监视 Operator 的运行命名空间。要监视所有命名空间，您可以将 namespace 选项留空：
mgr, err := ctrl.NewManager(cfg, manager.Options{Namespace: ""})
mgr, err := ctrl.NewManager(cfg, manager.Options{Namespace: ""})
您还可以使用 MultiNamespacedCacheBuilder 功能监控特定命名空间集合：
var namespaces []string
mgr, err := ctrl.NewManager(cfg, manager.Options{
NewCache: cache.MultiNamespacedCacheBuilder(namespaces),
})
var namespaces []string
mgr, err := ctrl.NewManager(cfg, manager.Options{
NewCache: cache.MultiNamespacedCacheBuilder(namespaces),
})5.3.2.2.3. 关于多组 API
在创建 API 和控制器前，请考虑您的 Operator 是否需要多个 API 组。本教程涵盖了单个组 API 的默认情况，但要更改项目布局来支持多组 API，您可以运行以下命令：
operator-sdk edit --multigroup=true
$ operator-sdk edit --multigroup=true
这个命令更新了 PROJECT 文件，该文件应该类似以下示例：
domain: example.com layout: go.kubebuilder.io/v3 multigroup: true ...
domain: example.com
layout: go.kubebuilder.io/v3
multigroup: true
...
对于多组项目，API Go 类型文件会在 apis/<group> /<version> / 目录中创建，控制器在 controllers/<group> / 目录中创建。然后会相应地更新 Dockerfile。
5.3.2.3. 创建 API 和控制器
使用 Operator SDK CLI 创建自定义资源定义（CRD）API 和控制器。
流程
运行以下命令创建带有组
cache、版本v1和种类Memcached的 API：operator-sdk create api \ --group=cache \ --version=v1 \ --kind=Memcached$ operator-sdk create api \ --group=cache \ --version=v1 \ --kind=MemcachedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 提示时，输入
y来创建资源和控制器：Create Resource [y/n] y Create Controller [y/n] y
Create Resource [y/n] y Create Controller [y/n] yCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Writing scaffold for you to edit... api/v1/memcached_types.go controllers/memcached_controller.go ...
Writing scaffold for you to edit... api/v1/memcached_types.go controllers/memcached_controller.go ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
此过程会在 api/v1/memcached_types.go 和 controllers/memcached_controller.go 中生成 Memcached 资源 API。
5.3.2.3.1. 定义 API
定义 Memcached 自定义资源（CR）的 API。
流程
修改
api/v1/memcached_types.go中的 Go 类型定义，使其具有以下spec和status：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 为资源类型更新生成的代码：
make generate
$ make generateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 提示在修改了
*_types.go文件后，您必须运行make generate命令来更新该资源类型生成的代码。以上 Makefile 目标调用
controller-gen程序来更新api/v1/zz_generated.deepcopy.go文件。这样可确保您的 API Go 类型定义实现了runtime.Object接口，所有 Kind 类型都必须实现。
5.3.2.3.2. 生成 CRD 清单
在使用 spec 和 status 字段和自定义资源定义（CRD）验证标记定义后，您可以生成 CRD 清单。
流程
运行以下命令以生成和更新 CRD 清单：
make manifests
$ make manifestsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 此 Makefile 目标调用
controller-gen实用程序在config/crd/bases/cache.example.com_memcacheds.yaml文件中生成 CRD 清单。
5.3.2.3.2.1. 关于 OpenAPI 验证
当生成清单时，openAPIV3 模式会添加到 spec.validation 块中的 CRD 清单中。此验证块允许 Kubernetes 在 Memcached 自定义资源（CR）创建或更新时验证其中的属性。
标记或注解可用于为您的 API 配置验证。这些标记始终具有 +kubebuilder:validation 前缀。
5.3.2.4. 实现控制器
在创建新 API 和控制器后，您可以实现控制器逻辑。
流程
在本例中，将生成的控制器文件
controllers/memcached_controller.go替换为以下示例实现：例 5.1.
memcached_controller.go示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 示例控制器为每个
Memcached自定义资源（CR）运行以下协调逻辑：- 如果尚无 Memcached 部署，创建一个。
-
确保部署大小与
MemcachedCR spec 指定的大小相同。 -
使用
memcachedPod 的名称更新MemcachedCR 状态。
下面的小节解释了示例中的控制器如何监视资源以及如何触发协调循环。您可以跳过这些小节以，直接进入运行 Operator。
5.3.2.4.1. 控制器监视的资源
controllers/memcached_controller.go 中的 SetupWithManager() 功能指定如何构建控制器来监视 CR 和其他控制器拥有和管理的资源。
NewControllerManagedBy() 提供了一个控制器构建器，它允许各种控制器配置。
for(&cachev1.Memcached{}) 将 Memcached 类型指定为要监视的主要资源。对于 Memcached 类型的每个 Add、Update 或 Delete 事件，协调循环都会为该 Memcached 对象发送一个协调 Request 参数，其中包括命名空间和名称键。
owns(&appsv1.Deployment{}) 将 Deployment 类型指定为要监视的辅助资源。对于 Deployment 类型的每个 Add、Update 或 Delete 事件，事件处理程序会将每个事件映射到部署所有者的协调请求。在本例中，所有者是创建部署的 Memcached 对象。
5.3.2.4.2. 控制器配置
您可以不同的配置来初始化控制器。例如：
使用
MaxConcurrentReconciles选项设置控制器的并发协调的最大数量，其默认值为1：Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 使用 predicates 过滤监视事件。
-
选择 EventHandler 类型来更改监视事件转换方式以协调协调循环的请求。对于比主和从属资源更复杂的 Operator 关系，您可以使用
EnqueueRequestsFromMapFunc处理程序将监控事件转换为一组任意协调请求。
有关这些配置和其他配置的详情，请参阅上游 Builder 和 Controller GoDocs。
5.3.2.4.3. 协调循环
每个控制器都有一个协调器对象，它带有实现了协调循环的 Reconcile() 方法。协调循环通过 Request 参数传递，该参数是从缓存中查找主资源对象 Memcached 的命名空间和名称键：
根据返回值、结果和错误，请求可能会重新排序，协调循环可能会再次触发：
您可以将 Result.RequeueAfter 设置为在宽限期后重新排序请求：
import "time"
// Reconcile for any reason other than an error after 5 seconds
return ctrl.Result{RequeueAfter: time.Second*5}, nil
import "time"
// Reconcile for any reason other than an error after 5 seconds
return ctrl.Result{RequeueAfter: time.Second*5}, nil
您可以返回带有 RequeueAfter 设置的 Result 来定期协调一个 CR。
有关协调器、客户端并与资源事件交互的更多信息，请参阅 Controller Runtime Client API 文档。
5.3.2.4.4. 权限和 RBAC 清单
控制器需要特定的 RBAC 权限与它管理的资源交互。它们通过 RBAC 标记来指定，如下所示：
config/rbac/role.yaml 中的 ClusterRole 对象清单通过在每次运行 manifests 命令时使用 controller-gen 实用程序的以前的标记生成。
5.3.2.5. 运行 Operator
您可以使用 Operator SDK CLI 构建和运行 Operator：
- 作为 Go 程序在集群外本地运行。
- 作为集群的部署运行。
- 捆绑 Operator，并使用 Operator Lifecycle Manager（OLM）在集群中部署。
在将基于 Go 的 Operator 作为在 OpenShift Container Platform 上部署或作为使用 OLM 的捆绑包运行之前，请确保您的项目已更新为使用支持的镜像。
5.3.2.5.1. 在集群外本地运行
您可以作为集群外的 Go 程序运行您的 Operator 项目。这可以加快部署和测试的速度，对于开发非常有用。
流程
运行以下命令，以在
~/.kube/config文件中配置的集群中安装自定义资源定义（CRD），并在本地运行 Operator：make install run
$ make install runCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.2.5.2. 准备 Operator 以使用支持的镜像
在 OpenShift Container Platform 上运行基于 Go 的 Operator 之前，请将项目更新为使用支持的镜像。
流程
更新项目根级别 Dockerfile 以使用支持的镜像。更改默认运行程序镜像引用：
FROM gcr.io/distroless/static:nonroot
FROM gcr.io/distroless/static:nonrootCopy to Clipboard Copied! Toggle word wrap Toggle overflow 改为：
FROM registry.access.redhat.com/ubi8/ubi-minimal:latest
FROM registry.access.redhat.com/ubi8/ubi-minimal:latestCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
根据 Go 项目版本，您的 Dockerfile 可能包含
USER 65532:65532或USER nonroot:nonroot指令。在这两种情况下，删除该行，因为受支持的 runner 镜像不需要该行。 在
config/default/manager_auth_proxy_patch.yaml文件中，修改image值：gcr.io/kubebuilder/kube-rbac-proxy:<tag>
gcr.io/kubebuilder/kube-rbac-proxy:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用支持的镜像：
registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.7
registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.7Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.2.5.3. 作为集群的部署运行
您可以作为一个部署在集群中运行 Operator 项目。
先决条件
- 通过更新项目以使用支持的镜像，准备基于 Go 的 Operator 在 OpenShift Container Platform 上运行
流程
运行以下
make命令来构建和推送 Operator 镜像。在以下步骤中修改IMG参数来引用您可访问的库。您可以获取在存储库站点（如 Quay.io）存储容器的帐户。构建镜像：
make docker-build IMG=<registry>/<user>/<image_name>:<tag>
$ make docker-build IMG=<registry>/<user>/<image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意由 SDK 为 Operator 生成的 Dockerfile 明确引用了
go 构建的GOARCH=amd64。对于非 AMD64 构架，这已被应用于GOARCH=$TARGETARCH。Docker 会自动将 环境变量设置为-platform指定的值。使用 Buildah，-build-arg需要用于目的。如需更多信息，请参阅 多个架构。将镜像推送到存储库：
make docker-push IMG=<registry>/<user>/<image_name>:<tag>
$ make docker-push IMG=<registry>/<user>/<image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意镜像的名称和标签，如
IMG=<registry> /<user> /<image_name>:<tag>，在两个命令中都可在您的 Makefile 中设置。修改IMG ?= controller:latest值来设置您的默认镜像名称。
运行以下命令来部署 Operator：
make deploy IMG=<registry>/<user>/<image_name>:<tag>
$ make deploy IMG=<registry>/<user>/<image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 默认情况下，这个命令会创建一个带有 Operator 项目名称的命名空间，格式为
<project_name>-system，用于部署。此命令还从config/rbac安装 RBAC 清单。验证 Operator 是否正在运行：
oc get deployment -n <project_name>-system
$ oc get deployment -n <project_name>-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY UP-TO-DATE AVAILABLE AGE <project_name>-controller-manager 1/1 1 1 8m
NAME READY UP-TO-DATE AVAILABLE AGE <project_name>-controller-manager 1/1 1 1 8mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator Lifecycle Manager（OLM）可帮助您在 Kubernetes 集群上安装、更新 Operator 及其相关服务的生命周期。OLM 在 OpenShift Container Platform 上默认安装，并作为 Kubernetes 扩展运行，以便您可以在没有任何额外工具的情况下将 Web 控制台和 OpenShift CLI（oc）用于所有 Operator 生命周期管理功能。
Operator Bundle Format 是 Operator SDK 和 OLM 的默认打包方法。您可以通过使用 Operator SDK 来通过 OLM 构建、推送、验证和运行捆绑包镜像，让 Operator 准备好进行 OLM。
先决条件
- 在开发工作站上安装 operator SDK CLI
-
已安装 OpenShift CLI（
oc）v4.7+ -
Operator Lifecycle Manager（OLM）安装在一个基于 Kubernetes 的集群上（如果使用
apiextensions.k8s.io/v1CRD，则为 v1.16.0 或更新版本，如 OpenShift Container Platform 4.7） -
使用具有
cluster-admin权限的账户使用oc登录到集群 - 使用 Operator SDK 初始化 operator 项目
- 如果 Operator 是基于 Go 的，则必须更新您的项目以使用支持的镜像在 OpenShift Container Platform 上运行
流程
在 Operator 项目目录中运行以下
make命令来构建和推送 Operator 镜像。在以下步骤中修改IMG参数来引用您可访问的库。您可以获取在存储库站点（如 Quay.io）存储容器的帐户。构建镜像：
make docker-build IMG=<registry>/<user>/<operator_image_name>:<tag>
$ make docker-build IMG=<registry>/<user>/<operator_image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意由 SDK 为 Operator 生成的 Dockerfile 明确引用了
go 构建的GOARCH=amd64。对于非 AMD64 构架，这已被应用于GOARCH=$TARGETARCH。Docker 会自动将 环境变量设置为-platform指定的值。使用 Buildah，-build-arg需要用于目的。如需更多信息，请参阅 多个架构。将镜像推送到存储库：
make docker-push IMG=<registry>/<user>/<operator_image_name>:<tag>
$ make docker-push IMG=<registry>/<user>/<operator_image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
运行
make bundle命令创建 Operator 捆绑包清单，该命令调用多个命令，其中包括 Operator SDKgenerate bundle和bundle validate子命令：make bundle IMG=<registry>/<user>/<operator_image_name>:<tag>
$ make bundle IMG=<registry>/<user>/<operator_image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Operator 的捆绑包清单描述了如何显示、创建和管理应用程序。
make bundle命令在 Operator 项目中创建以下文件和目录：-
包含
ClusterServiceVersion对象的捆绑包清单目录，名为bundle/manifests -
名为
bundle/metadata的捆绑包元数据目录 -
config/crd目录中的所有自定义资源定义（CRD） -
一个 Dockerfile
bundle.Dockerfile
然后，使用
operator-sdk bundle validate自动验证这些文件，以确保磁盘上的捆绑包的格式是正确的。-
包含
运行以下命令来构建和推送捆绑包镜像。OLM 使用索引镜像来消耗 Operator 捆绑包，该镜像引用一个或多个捆绑包镜像。
构建捆绑包镜像。使用您要推送镜像的 registry、用户命名空间和镜像标签的详情，设置
BUNDLE_IMAGE：make bundle-build BUNDLE_IMG=<registry>/<user>/<bundle_image_name>:<tag>
$ make bundle-build BUNDLE_IMG=<registry>/<user>/<bundle_image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 推送捆绑包镜像：
docker push <registry>/<user>/<bundle_image_name>:<tag>
$ docker push <registry>/<user>/<bundle_image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
使用以下命令，检查集群中的 OLM 状态：
operator-sdk olm status \ --olm-namespace=openshift-operator-lifecycle-manager$ operator-sdk olm status \ --olm-namespace=openshift-operator-lifecycle-managerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用 Operator SDK 中的 OLM 集成在集群中运行 Operator：
operator-sdk run bundle \ [-n <namespace>] \ <registry>/<user>/<bundle_image_name>:<tag>$ operator-sdk run bundle \ [-n <namespace>] \1 <registry>/<user>/<bundle_image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 默认情况下，命令会在
~/.kube/config文件中当前活跃的项目中安装 Operator。您可以添加-n标志来为安装设置不同的命名空间范围。
这个命令执行以下操作：
- 使用注入的捆绑包镜像创建索引镜像。
- 创建指向新索引镜像的目录源，以便 OperatorHub 能够发现 Operator。
- 通过创建一个 Operator 组、订阅、安装计划以及所有其他必要的对象（包括 RBAC），将 Operator 部署到集群中。
5.3.2.6. 创建自定义资源
安装 Operator 后，您可以通过创建一个由 Operator 在集群中提供的自定义资源（CR）来测试它。
先决条件
-
在集群中安装的 Memcached Operator 示例，它提供
MemcachedCR）
流程
切换到安装 Operator 的命名空间。例如，如果使用
make deploy命令部署 Operator：oc project memcached-operator-system
$ oc project memcached-operator-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 编辑
config/samples/cache_v1_memcached.yaml上的MemcachedCR 清单示例，使其包含以下规格：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建 CR:
oc apply -f config/samples/cache_v1_memcached.yaml
$ oc apply -f config/samples/cache_v1_memcached.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 确保
MemcachedOperator 为示例 CR 创建部署，其大小正确：oc get deployments
$ oc get deploymentsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY UP-TO-DATE AVAILABLE AGE memcached-operator-controller-manager 1/1 1 1 8m memcached-sample 3/3 3 3 1m
NAME READY UP-TO-DATE AVAILABLE AGE memcached-operator-controller-manager 1/1 1 1 8m memcached-sample 3/3 3 3 1mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查 pod 和 CR 状态，以确认其状态是否使用 Memcached pod 名称更新。
检查 pod:
oc get pods
$ oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE memcached-sample-6fd7c98d8-7dqdr 1/1 Running 0 1m memcached-sample-6fd7c98d8-g5k7v 1/1 Running 0 1m memcached-sample-6fd7c98d8-m7vn7 1/1 Running 0 1m
NAME READY STATUS RESTARTS AGE memcached-sample-6fd7c98d8-7dqdr 1/1 Running 0 1m memcached-sample-6fd7c98d8-g5k7v 1/1 Running 0 1m memcached-sample-6fd7c98d8-m7vn7 1/1 Running 0 1mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查 CR 状态：
oc get memcached/memcached-sample -o yaml
$ oc get memcached/memcached-sample -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
更新部署大小。
更新
config/samples/cache_v1_memcached.yaml文件，将MemcachedCR 中的spec.size字段从3改为5：oc patch memcached memcached-sample \ -p '{"spec":{"size": 5}}' \ --type=merge$ oc patch memcached memcached-sample \ -p '{"spec":{"size": 5}}' \ --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 确认 Operator 已更改部署大小：
oc get deployments
$ oc get deploymentsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY UP-TO-DATE AVAILABLE AGE memcached-operator-controller-manager 1/1 1 1 10m memcached-sample 5/5 5 5 3m
NAME READY UP-TO-DATE AVAILABLE AGE memcached-operator-controller-manager 1/1 1 1 10m memcached-sample 5/5 5 5 3mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
清理本教程中创建的资源。
如果使用
make deploy命令来测试 Operator，请运行以下命令：make undeploy
$ make undeployCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果使用
operator-sdk run bundle命令来测试 Operator，请运行以下命令：operator-sdk cleanup <project_name>
$ operator-sdk cleanup <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.3. 基于 Go 的 Operator 的项目布局
operator-sdk CLI 可为每个 Operator 项目生成或 scaffold 多个 软件包和文件。
5.3.3.1. 基于 Go 的项目布局
使用 operator-sdk init 命令生成的基于 Go 的 Operator 项目（默认类型）包含以下文件和目录：
| 文件或目录 | 用途 |
|---|---|
|
|
Operator 的主要程序。这会实例化一个新管理器，它会在 |
|
|
定义 CRD API 的目录树。您必须编辑 |
|
|
控制器的实现。编辑 |
|
| 用于在集群中部署控制器的 Kubernetes 清单，包括 CRD、RBAC 和证书。 |
|
| 用于构建和部署控制器的目标。 |
|
| 容器引擎用来构建 Operator 的说明。 |
|
| Kubernetes 清单用于注册 CRD、设置 RBAC 和将 Operator 部署为部署。 |
5.4. 基于 Ansible 的 Operator
5.4.1. 基于 Ansible 的 Operator 的 Operator SDK 入门
Operator SDK 包括生成 Operator 项目的选项，它利用现有 Ansible playbook 和模块将 Kubernetes 资源部署为统一应用程序，而无需编写任何 Go 代码。
如需演示使用 Operator SDK 提供的工具和库设置并运行基于 Ansible 的 Operator 的基本知识，Operator 开发人员可以为 Memcached、分布式键值存储构建基于 Ansible 的 Operator 示例，并将它部署到集群中。
5.4.1.1. 先决条件
- 已安装 operator SDK CLI
-
已安装 OpenShift CLI（
oc）v4.7+ - Ansible 版本 v2.9.0
- Ansible Runner 版本 v1.1.0+
- Ansible Runner HTTP Event Emitter plug-in 版本 v1.0.0+
- OpenShift Python client 版本 v0.11.2+
-
使用具有
cluster-admin权限的oc登录到 OpenShift Container Platform 4.7 集群 - 要允许集群拉取镜像，推送镜像的存储库必须设置为公共的存储库，或必须配置一个镜像 pull secret。
5.4.1.2. 创建并部署基于 Ansible 的 Operator
您可以使用 Operator SDK 为 Memcached 构建和部署简单的基于 Ansible 的 Operator。
流程
创建一个项目。
创建您的项目目录：
mkdir memcached-operator
$ mkdir memcached-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 切换到项目所在的目录：
cd memcached-operator
$ cd memcached-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
ansible插件运行operator-sdk init命令以初始化项目：operator-sdk init \ --plugins=ansible \ --domain=example.com$ operator-sdk init \ --plugins=ansible \ --domain=example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建 API。
创建简单的 Memcached API：
operator-sdk create api \ --group cache \ --version v1 \ --kind Memcached \ --generate-role$ operator-sdk create api \ --group cache \ --version v1 \ --kind Memcached \ --generate-role1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 为 API 生成 Ansible 角色。
构建并推送 Operator 镜像。
使用默认的
Makefile目标来构建和推送 Operator。使用镜像的 pull spec 设置IMG，该 spec 使用您可推送到的 registry：make docker-build docker-push IMG=<registry>/<user>/<image_name>:<tag>
$ make docker-build docker-push IMG=<registry>/<user>/<image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行 Operator。
安装 CRD：
make install
$ make installCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将项目部署到集群中。将
IMG设置为您推送的镜像：make deploy IMG=<registry>/<user>/<image_name>:<tag>
$ make deploy IMG=<registry>/<user>/<image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
创建示例自定义资源（CR）。
创建一个示例 CR：
oc apply -f config/samples/cache_v1_memcached.yaml \ -n memcached-operator-system$ oc apply -f config/samples/cache_v1_memcached.yaml \ -n memcached-operator-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 查看 CR 协调 Operator：
oc logs deployment.apps/memcached-operator-controller-manager \ -c manager \ -n memcached-operator-system$ oc logs deployment.apps/memcached-operator-controller-manager \ -c manager \ -n memcached-operator-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
清理。
运行以下命令清理在此流程中创建的资源：
make undeploy
$ make undeployCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.1.3. 后续步骤
- 如需更深入地了解如何构建基于 Ansible 的 Operator，请参阅基于 Ansible 的 Operator SDK 指南。
5.4.2. 基于 Ansible 的 Operator 的 operator SDK 指南
operator 开发人员可以利用 Operator SDK 中的 Ansible 支持来为 Memcached 构建基于 Ansible 的示例 Operator、分布式键值存储并管理其生命周期。本教程介绍了以下过程：
- 创建 Memcached 部署
-
确保部署大小与
Memcached自定义资源（CR）spec 指定的大小相同 -
使用 status writer 带有
memcachedPod 的名称来更新MemcachedCR 状态
此过程可通过以下两个 Operator Framework 核心组件完成：
- Operator SDK
-
operator-sdkCLI 工具和controller-runtime库 API - Operator Lifecycle Manager (OLM)
- 集群中 Operator 的安装、升级和基于角色的访问控制（RBAC）
本教程的内容比基于 Ansible 的 Operator 开始使用 Operator SDK 内容更详细。
5.4.2.1. 先决条件
- 已安装 operator SDK CLI
-
已安装 OpenShift CLI（
oc）v4.7+ - Ansible 版本 v2.9.0
- Ansible Runner 版本 v1.1.0+
- Ansible Runner HTTP Event Emitter plug-in 版本 v1.0.0+
- OpenShift Python client 版本 v0.11.2+
-
使用具有
cluster-admin权限的oc登录到 OpenShift Container Platform 4.7 集群 - 要允许集群拉取镜像，推送镜像的存储库必须设置为公共的存储库，或必须配置一个镜像 pull secret。
5.4.2.2. 创建一个项目
使用 Operator SDK CLI 创建名为 memcached-operator 的 项目。
流程
为项目创建一个目录：
mkdir -p $HOME/projects/memcached-operator
$ mkdir -p $HOME/projects/memcached-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 进入该目录：
cd $HOME/projects/memcached-operator
$ cd $HOME/projects/memcached-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
ansible插件运行operator-sdk init命令以初始化项目：operator-sdk init \ --plugins=ansible \ --domain=example.com$ operator-sdk init \ --plugins=ansible \ --domain=example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.2.2.1. PROJECT 文件
operator-sdk init 命令生成的文件中是一个 Kubebuilder PROJECT 文件。从项目 root 运行的后续 operator-sdk 命令以及 help 输出可读取该文件，并注意到项目的类型是 Ansible。例如：
domain: example.com layout: ansible.sdk.operatorframework.io/v1 projectName: memcached-operator version: 3-alpha
domain: example.com
layout: ansible.sdk.operatorframework.io/v1
projectName: memcached-operator
version: 3-alpha5.4.2.3. 创建 API
使用 Operator SDK CLI 创建 Memcached API。
流程
运行以下命令创建带有组
cache、版本v1和种类Memcached的 API：operator-sdk create api \ --group cache \ --version v1 \ --kind Memcached \ --generate-role$ operator-sdk create api \ --group cache \ --version v1 \ --kind Memcached \ --generate-role1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 为 API 生成 Ansible 角色。
创建 API 后，Operator 项目会以以下结构更新：
- Memcached CRD
-
包括一个
Memcached资源示例 - Manager（管理者）
使用以下方法将集群状态协调到所需状态的程序：
- 一个协调器，可以是 Ansible 角色或 playbook
-
一个
watches.yaml文件，将Memcached资源连接到memcachedAnsible 角色
5.4.2.4. 修改管理者
更新您的 Operator 项目，以提供协调逻辑，其格式为 Ansible 角色，它在每次创建、更新或删除 Memcached 资源时运行。
流程
用下列结构更新
roles/memcached/tasks/main.yml文件：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 这个
memcached角色可确保存在memcached部署并设置部署大小。通过编辑
roles/memcached/defaults/main.yml文件，为您的 Ansible 角色中使用的变量设置默认值：--- # defaults file for Memcached size: 1
--- # defaults file for Memcached size: 1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下结构更新
config/samples/cache_v1_memcached.yaml文件中的Memcached示例资源：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 自定义资源（CR）spec 中的键值对作为额外变量传递给 Ansible。
在运行 Ansible 前，Operator 会将 spec 字段中所有变量的名称转换为 snake case，即小写并附带下划线。例如，spec 中的 serviceAccount 在 Ansible 中会变成 service_account。
您可以通过在 watches.yaml 文件中将 snakeCaseParameters 选项设置为 false 来禁用大小写转换。建议您在 Ansible 中对变量执行一些类型验证，以确保应用程序收到所需输入。
5.4.2.5. 运行 Operator
您可以使用 Operator SDK CLI 构建和运行 Operator：
- 作为 Go 程序在集群外本地运行。
- 作为集群的部署运行。
- 捆绑 Operator，并使用 Operator Lifecycle Manager（OLM）在集群中部署。
5.4.2.5.1. 在集群外本地运行
您可以作为集群外的 Go 程序运行您的 Operator 项目。这可以加快部署和测试的速度，对于开发非常有用。
流程
运行以下命令，以在
~/.kube/config文件中配置的集群中安装自定义资源定义（CRD），并在本地运行 Operator：make install run
$ make install runCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.2.5.2. 准备 Operator 以使用支持的镜像
在 OpenShift Container Platform 上运行基于 Ansible 的 Operator 之前，请将项目更新为使用支持的镜像。
流程
更新项目根级别 Dockerfile 以使用支持的镜像。更改默认构建器镜像引用：
FROM quay.io/operator-framework/ansible-operator:v1.3.0
FROM quay.io/operator-framework/ansible-operator:v1.3.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 改为：
FROM registry.redhat.io/openshift4/ose-ansible-operator:v4.7
FROM registry.redhat.io/openshift4/ose-ansible-operator:v4.7Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要使用与 Operator SDK 版本匹配的构建器镜像版本。因项目布局或 scaffolding 而导致问题，特别是将较新的 Operator SDK 版本与下游 OpenShift Container Platform 构建器镜像混合时。
在
config/default/manager_auth_proxy_patch.yaml文件中，修改image值：gcr.io/kubebuilder/kube-rbac-proxy:<tag>
gcr.io/kubebuilder/kube-rbac-proxy:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用支持的镜像：
registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.7
registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.7Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.2.5.3. 作为集群的部署运行
您可以作为一个部署在集群中运行 Operator 项目。
流程
运行以下
make命令来构建和推送 Operator 镜像。在以下步骤中修改IMG参数来引用您可访问的库。您可以获取在存储库站点（如 Quay.io）存储容器的帐户。构建镜像：
make docker-build IMG=<registry>/<user>/<image_name>:<tag>
$ make docker-build IMG=<registry>/<user>/<image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意由 SDK 为 Operator 生成的 Dockerfile 明确引用了
go 构建的GOARCH=amd64。对于非 AMD64 构架，这已被应用于GOARCH=$TARGETARCH。Docker 会自动将 环境变量设置为-platform指定的值。使用 Buildah，-build-arg需要用于目的。如需更多信息，请参阅 多个架构。将镜像推送到存储库：
make docker-push IMG=<registry>/<user>/<image_name>:<tag>
$ make docker-push IMG=<registry>/<user>/<image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意镜像的名称和标签，如
IMG=<registry> /<user> /<image_name>:<tag>，在两个命令中都可在您的 Makefile 中设置。修改IMG ?= controller:latest值来设置您的默认镜像名称。
运行以下命令来部署 Operator：
make deploy IMG=<registry>/<user>/<image_name>:<tag>
$ make deploy IMG=<registry>/<user>/<image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 默认情况下，这个命令会创建一个带有 Operator 项目名称的命名空间，格式为
<project_name>-system，用于部署。此命令还从config/rbac安装 RBAC 清单。验证 Operator 是否正在运行：
oc get deployment -n <project_name>-system
$ oc get deployment -n <project_name>-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY UP-TO-DATE AVAILABLE AGE <project_name>-controller-manager 1/1 1 1 8m
NAME READY UP-TO-DATE AVAILABLE AGE <project_name>-controller-manager 1/1 1 1 8mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator Lifecycle Manager（OLM）可帮助您在 Kubernetes 集群上安装、更新 Operator 及其相关服务的生命周期。OLM 在 OpenShift Container Platform 上默认安装，并作为 Kubernetes 扩展运行，以便您可以在没有任何额外工具的情况下将 Web 控制台和 OpenShift CLI（oc）用于所有 Operator 生命周期管理功能。
Operator Bundle Format 是 Operator SDK 和 OLM 的默认打包方法。您可以通过使用 Operator SDK 来通过 OLM 构建、推送、验证和运行捆绑包镜像，让 Operator 准备好进行 OLM。
先决条件
- 在开发工作站上安装 operator SDK CLI
-
已安装 OpenShift CLI（
oc）v4.7+ -
Operator Lifecycle Manager（OLM）安装在一个基于 Kubernetes 的集群上（如果使用
apiextensions.k8s.io/v1CRD，则为 v1.16.0 或更新版本，如 OpenShift Container Platform 4.7） -
使用具有
cluster-admin权限的账户使用oc登录到集群 - 使用 Operator SDK 初始化 operator 项目
流程
在 Operator 项目目录中运行以下
make命令来构建和推送 Operator 镜像。在以下步骤中修改IMG参数来引用您可访问的库。您可以获取在存储库站点（如 Quay.io）存储容器的帐户。构建镜像：
make docker-build IMG=<registry>/<user>/<operator_image_name>:<tag>
$ make docker-build IMG=<registry>/<user>/<operator_image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意由 SDK 为 Operator 生成的 Dockerfile 明确引用了
go 构建的GOARCH=amd64。对于非 AMD64 构架，这已被应用于GOARCH=$TARGETARCH。Docker 会自动将 环境变量设置为-platform指定的值。使用 Buildah，-build-arg需要用于目的。如需更多信息，请参阅 多个架构。将镜像推送到存储库：
make docker-push IMG=<registry>/<user>/<operator_image_name>:<tag>
$ make docker-push IMG=<registry>/<user>/<operator_image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
运行
make bundle命令创建 Operator 捆绑包清单，该命令调用多个命令，其中包括 Operator SDKgenerate bundle和bundle validate子命令：make bundle IMG=<registry>/<user>/<operator_image_name>:<tag>
$ make bundle IMG=<registry>/<user>/<operator_image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Operator 的捆绑包清单描述了如何显示、创建和管理应用程序。
make bundle命令在 Operator 项目中创建以下文件和目录：-
包含
ClusterServiceVersion对象的捆绑包清单目录，名为bundle/manifests -
名为
bundle/metadata的捆绑包元数据目录 -
config/crd目录中的所有自定义资源定义（CRD） -
一个 Dockerfile
bundle.Dockerfile
然后，使用
operator-sdk bundle validate自动验证这些文件，以确保磁盘上的捆绑包的格式是正确的。-
包含
运行以下命令来构建和推送捆绑包镜像。OLM 使用索引镜像来消耗 Operator 捆绑包，该镜像引用一个或多个捆绑包镜像。
构建捆绑包镜像。使用您要推送镜像的 registry、用户命名空间和镜像标签的详情，设置
BUNDLE_IMAGE：make bundle-build BUNDLE_IMG=<registry>/<user>/<bundle_image_name>:<tag>
$ make bundle-build BUNDLE_IMG=<registry>/<user>/<bundle_image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 推送捆绑包镜像：
docker push <registry>/<user>/<bundle_image_name>:<tag>
$ docker push <registry>/<user>/<bundle_image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
使用以下命令，检查集群中的 OLM 状态：
operator-sdk olm status \ --olm-namespace=openshift-operator-lifecycle-manager$ operator-sdk olm status \ --olm-namespace=openshift-operator-lifecycle-managerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用 Operator SDK 中的 OLM 集成在集群中运行 Operator：
operator-sdk run bundle \ [-n <namespace>] \ <registry>/<user>/<bundle_image_name>:<tag>$ operator-sdk run bundle \ [-n <namespace>] \1 <registry>/<user>/<bundle_image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 默认情况下，命令会在
~/.kube/config文件中当前活跃的项目中安装 Operator。您可以添加-n标志来为安装设置不同的命名空间范围。
这个命令执行以下操作：
- 使用注入的捆绑包镜像创建索引镜像。
- 创建指向新索引镜像的目录源，以便 OperatorHub 能够发现 Operator。
- 通过创建一个 Operator 组、订阅、安装计划以及所有其他必要的对象（包括 RBAC），将 Operator 部署到集群中。
5.4.2.6. 创建自定义资源
安装 Operator 后，您可以通过创建一个由 Operator 在集群中提供的自定义资源（CR）来测试它。
先决条件
-
在集群中安装的 Memcached Operator 示例，它提供
MemcachedCR）
流程
切换到安装 Operator 的命名空间。例如，如果使用
make deploy命令部署 Operator：oc project memcached-operator-system
$ oc project memcached-operator-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 编辑
config/samples/cache_v1_memcached.yaml上的MemcachedCR 清单示例，使其包含以下规格：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建 CR:
oc apply -f config/samples/cache_v1_memcached.yaml
$ oc apply -f config/samples/cache_v1_memcached.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 确保
MemcachedOperator 为示例 CR 创建部署，其大小正确：oc get deployments
$ oc get deploymentsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY UP-TO-DATE AVAILABLE AGE memcached-operator-controller-manager 1/1 1 1 8m memcached-sample 3/3 3 3 1m
NAME READY UP-TO-DATE AVAILABLE AGE memcached-operator-controller-manager 1/1 1 1 8m memcached-sample 3/3 3 3 1mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查 pod 和 CR 状态，以确认其状态是否使用 Memcached pod 名称更新。
检查 pod:
oc get pods
$ oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE memcached-sample-6fd7c98d8-7dqdr 1/1 Running 0 1m memcached-sample-6fd7c98d8-g5k7v 1/1 Running 0 1m memcached-sample-6fd7c98d8-m7vn7 1/1 Running 0 1m
NAME READY STATUS RESTARTS AGE memcached-sample-6fd7c98d8-7dqdr 1/1 Running 0 1m memcached-sample-6fd7c98d8-g5k7v 1/1 Running 0 1m memcached-sample-6fd7c98d8-m7vn7 1/1 Running 0 1mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查 CR 状态：
oc get memcached/memcached-sample -o yaml
$ oc get memcached/memcached-sample -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
更新部署大小。
更新
config/samples/cache_v1_memcached.yaml文件，将MemcachedCR 中的spec.size字段从3改为5：oc patch memcached memcached-sample \ -p '{"spec":{"size": 5}}' \ --type=merge$ oc patch memcached memcached-sample \ -p '{"spec":{"size": 5}}' \ --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 确认 Operator 已更改部署大小：
oc get deployments
$ oc get deploymentsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY UP-TO-DATE AVAILABLE AGE memcached-operator-controller-manager 1/1 1 1 10m memcached-sample 5/5 5 5 3m
NAME READY UP-TO-DATE AVAILABLE AGE memcached-operator-controller-manager 1/1 1 1 10m memcached-sample 5/5 5 5 3mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
清理本教程中创建的资源。
如果使用
make deploy命令来测试 Operator，请运行以下命令：make undeploy
$ make undeployCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果使用
operator-sdk run bundle命令来测试 Operator，请运行以下命令：operator-sdk cleanup <project_name>
$ operator-sdk cleanup <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.3. 基于 Ansible 的 Operator 的项目布局
operator-sdk CLI 可为每个 Operator 项目生成或 scaffold 多个 软件包和文件。
5.4.3.1. 基于 Ansible 的项目布局
使用 operator-sdk init --plugins ansible 命令生成的基于 Ansible 的 Operator 项目包含以下目录和文件：
| 文件或目录 | 用途 |
|---|---|
|
| 用于为 Operator 构建容器镜像的 Dockerfile。 |
|
| 用于构建、发布、部署容器镜像的目标，其中包含 Operator 二进制文件，用于安装和卸载自定义资源定义（CRD）。 |
|
| 包含 Operator 元数据信息的 YAML 文件。 |
|
|
基本 CRD 文件和 |
|
|
为部署收集所有 Operator 清单。被 |
|
| Controller Manager 部署。 |
|
|
用于监控 Operator 的 |
|
| 领导选举和身份验证代理的角色和角色绑定。 |
|
| 为 CRD 创建的资源示例。 |
|
| 用于测试的示例配置。 |
|
| 要运行的 playbook 的子目录。 |
|
| 要运行的角色树的子目录。 |
|
|
要监视的资源的 Group/version/kind（GVK）和 Ansible 调用方法。使用 |
|
| 包含要在构建期间安装的 Ansible 集合和角色依赖项的 YAML 文件。 |
|
| 模拟您角色和 Operator 端到端测试的场景。 |
5.4.4. Operator SDK 中的 Ansible 支持
5.4.4.1. 自定义资源文件
Operator 会使用 Kubernetes 的扩展机制，即自定义资源定义 (CRD)，这样您的自定义资源 (CR) 的外观和行为均类似于内置的原生 Kubernetes 对象。
CR 文件格式是一个 Kubernetes 资源文件。该对象具有必填和选填字段：
| 字段 | 描述 |
|---|---|
|
| 要创建 CR 的版本。 |
|
| 要创建 CR 的类型。 |
|
| 要创建的 Kubernetes 特定元数据。 |
|
| 传输至 Ansible 的变量键值列表。本字段默认为空。 |
|
|
总结对象的当前状态。对于基于 Ansible 的 Operator， |
|
| 要附于 CR 的 Kubernetes 特定注解。 |
以下 CR 注解列表会修改 Operator 的行为：
| 注解 | 描述 |
|---|---|
|
|
为 CR 指定协调间隔。该值将通过标准 Golang 软件包 |
基于 Ansible 的 Operator 注解示例
5.4.4.2. watches.yaml 文件
group/version/kind (GVK) 是 Kubernetes API 的唯一标识符。watches.yaml 文件包含从自定义资源（CR）中标识的自定义资源（CR）到 Ansible 角色或 playbook 的映射列表。Operator 期望这个映射文件位于 /opt/ansible/watches.yaml 的预定义位置。
| 字段 | 描述 |
|---|---|
|
| 要监视的 CR 组。 |
|
| 要监视的 CR 版本。 |
|
| 要监视的 CR 类型 |
|
|
添加至容器中的 Ansible 角色的路径。例如：如果您的 |
|
|
添加至容器中的 Ansible playbook 的路径。期望这个 playbook 作为一种调用角色的方法。该字段与 |
|
| 给定 CR 的协调间隔，角色或 playbook 运行的频率。 |
|
|
如果设置为 |
watches.yaml 文件示例
5.4.4.2.1. 高级选项
高级功能可通过添加至每个 GVK 的 watches.yaml 文件中来启用。它们可放在 group、version、kind 和 playbook 或 role 字段下方。
可使用 CR 上的注解覆盖每个资源的一些功能。可覆盖的选项会指定以下注解。
| 功能 | YAML 密钥 | 描述 | 覆盖注解 | 默认值 |
|---|---|---|---|---|
| 协调周期 |
| 特定 CR 的协调运行间隔时间。 |
|
|
| 管理状态 |
|
允许 Operator 管理每个 CR |
| |
| 监视依赖资源 |
| 支持 Operator 动态监视由 Ansible 创建的资源。 |
| |
| 监控集群范围内的资源 |
| 支持 Operator 监视由 Ansible 创建的集群范围的资源。 |
| |
| 最大运行程序工件 |
| 管理 Ansible Runner 在 Operator 容器中为每个单独资源保存的构件目录的数量。 |
|
|
带有高级选项的 watches.yml 文件示例
5.4.4.3. 发送至 Ansible 的额外变量
额外变量可发送至 Ansible，然后由 Operator 管理。自定义资源 (CR) 的 spec 部分作为额外变量按照键值对传递。等同于传递给 ansible-playbook 命令的额外变量。
Operator 还会在 meta 字段下传递额外变量，用于 CR 的名称和 CR 的命名空间。
对于以下 CR 示例：
作为额外变量传递至 Ansible 的结构为：
message 和 newParameter 字段在顶层被设置为额外变量，meta 则为 Operator 中定义的 CR 提供相关元数据。meta 字段可使用 Ansible 中的点符号来访问，如：
---
- debug:
msg: "name: {{ ansible_operator_meta.name }}, {{ ansible_operator_meta.namespace }}"
---
- debug:
msg: "name: {{ ansible_operator_meta.name }}, {{ ansible_operator_meta.namespace }}"5.4.4.4. Ansible Runner 目录
Ansible Runner 会将与 Ansible 运行相关的信息保存至容器中。具体位于：/tmp/ansible-operator/runner/<group>/<version>/<kind>/<namespace>/<name>。
5.4.5. Kubernetes Collection for Ansible
要使用 Ansible 管理 Kubernetes 上的应用程序生命周期，您可以使用 Kubernetes Collection for Ansible。此 Ansible 模块集合允许开发人员利用通过 YAML 编写的现有 Kubernetes 资源文件，或用原生 Ansible 表达生命周期管理。
将 Ansible 与现有 Kubernetes 资源文件相结合的一个最大好处在于可使用 Jinja 模板，这样您只需借助 Ansible 中的几个变量即可轻松自定义资源。
本节详细介绍了 Kubernetes 集合的使用方法。开始之前，在本地工作站上安装集合，并使用 playbook 进行测试，然后再移至 Operator 内使用它。
5.4.5.1. 为 Ansible 安装 Kubernetes 集合
您可以在本地工作站上安装 Kubernetes Collection for Ansible。
流程
安装 Ansible 2.9+：
sudo dnf install ansible
$ sudo dnf install ansibleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 安装 OpenShift python 客户端 软件包：
pip3 install openshift
$ pip3 install openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下方法之一安装 Kubernetes Collection：
您可以直接从 Ansible Galaxy 安装集合：
ansible-galaxy collection install community.kubernetes
$ ansible-galaxy collection install community.kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您已初始化了 Operator，则可能在项目顶层都有一个
requirements.yml文件。此文件指定必须安装的 Ansible 依赖项，才能让 Operator 正常工作。在默认情况下，这个文件会安装community.kubernetes集合以及operator_sdk.util集合，它为特定 Operator 的单元提供模块和插件。安装来自
requirements.yml文件的依赖模块：ansible-galaxy collection install -r requirements.yml
$ ansible-galaxy collection install -r requirements.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.5.2. 本地测试 Kubernetes Collection
operator 开发人员可以从其本地机器运行 Ansible 代码，而不是每次运行和重建 Operator。
先决条件
- 初始化基于 Ansible 的 Operator 项目，并使用 Operator SDK 创建具有生成 Ansible 角色的 API
- 安装 Kubernetes Collection for Ansible
流程
在基于 Ansible 的 Operator 项目目录中，使用您想要的 Ansible 逻辑来修改
roles/<kind> /tasks/main.yml文件。在创建 API 时，当使用--generate-role标志时，会创建roles/<kind> /目录。<kind>可替换与您为 API 指定的类型匹配。以下示例根据名为
state的变量值创建并删除配置映射：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 修改
roles/<kind> /defaults/main.yml文件，将默认state设置为present：--- state: present
--- state: presentCopy to Clipboard Copied! Toggle word wrap Toggle overflow 通过在项目目录的顶层创建一个
playbook.yml文件来创建一个 Ansible playbook，其中包含您的<kind>角色：--- - hosts: localhost roles: - <kind>--- - hosts: localhost roles: - <kind>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行 playbook：
ansible-playbook playbook.yml
$ ansible-playbook playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 验证配置映射是否已创建：
oc get configmaps
$ oc get configmapsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME DATA AGE example-config 0 2m1s
NAME DATA AGE example-config 0 2m1sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重新运行 playbook，设置
state为absent：ansible-playbook playbook.yml --extra-vars state=absent
$ ansible-playbook playbook.yml --extra-vars state=absentCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 验证配置映射是否已删除：
oc get configmaps
$ oc get configmapsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.5.3. 后续步骤
- 如需了解当自定义资源（CR）更改时在 Operator 内触发自定义 Ansible 逻辑的详情，请参阅在 Operator 中使用 Ansible。
5.4.6. 在 Operator 中使用 Ansible
熟悉在本地使用 Kubernetes Collection for Ansible 后，当自定义资源（CR）发生变化时，您可以在 Operator 内部触发相同的 Ansible 逻辑。本示例将 Ansible 角色映射到 Operator 所监视的特定 Kubernetes 资源。该映射在 watches.yaml 文件中完成。
5.4.6.1. 自定义资源文件
Operator 会使用 Kubernetes 的扩展机制，即自定义资源定义 (CRD)，这样您的自定义资源 (CR) 的外观和行为均类似于内置的原生 Kubernetes 对象。
CR 文件格式是一个 Kubernetes 资源文件。该对象具有必填和选填字段：
| 字段 | 描述 |
|---|---|
|
| 要创建 CR 的版本。 |
|
| 要创建 CR 的类型。 |
|
| 要创建的 Kubernetes 特定元数据。 |
|
| 传输至 Ansible 的变量键值列表。本字段默认为空。 |
|
|
总结对象的当前状态。对于基于 Ansible 的 Operator， |
|
| 要附于 CR 的 Kubernetes 特定注解。 |
以下 CR 注解列表会修改 Operator 的行为：
| 注解 | 描述 |
|---|---|
|
|
为 CR 指定协调间隔。该值将通过标准 Golang 软件包 |
基于 Ansible 的 Operator 注解示例
5.4.6.2. 本地测试基于 Ansible 的 Operator
您可以使用 Operator 项目的顶层目录中的 make run 命令，测试本地运行的基于 Ansible 的 Operator 内部的逻辑。make run Makefile 目标在本地运行 ansible-operator 二进制文件，从 watches.yaml 文件中读取并使用 ~/.kube/config 文件与 Kubernetes 集群通信，就像 k8s 模块一样。
您可以通过设置环境变量 ANSIBLE_ROLES_PATH 或者使用 ansible-roles-path 标记来自定义角色路径。如果在 ANSIBLE_ROLES_PATH 值中没有找到该角色，Operator 会在 {{current directory}}/roles 中查找它。
先决条件
- Ansible Runner 版本 v1.1.0+
- Ansible Runner HTTP Event Emitter plug-in 版本 v1.0.0+
- 执行前面的步骤在本地测试 Kubernetes Collection
流程
为自定义资源（CR）安装自定义资源定义（CRD）和正确的基于角色的访问控制（RBAC）定义：
make install
$ make installCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
/usr/bin/kustomize build config/crd | kubectl apply -f - customresourcedefinition.apiextensions.k8s.io/memcacheds.cache.example.com created
/usr/bin/kustomize build config/crd | kubectl apply -f - customresourcedefinition.apiextensions.k8s.io/memcacheds.cache.example.com createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行
make run命令：make run
$ make runCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 现在，Operator 会监控 CR 的事件，创建 CR 将触发您的 Ansible 角色运行。
注意考虑
config/samples/<gvk>.yamlCR 清单示例：apiVersion: <group>.example.com/v1alpha1 kind: <kind> metadata: name: "<kind>-sample"
apiVersion: <group>.example.com/v1alpha1 kind: <kind> metadata: name: "<kind>-sample"