红帽全球峰会Operator
Red Hat OpenShift Service on AWS Operators。
摘要
第 1 章 Operator 概述
Operator 是 Red Hat OpenShift Service on AWS 中最重要的组件。Operator 是 control plane 上打包、部署和管理服务的首选方法。它们还可以为用户运行的应用程序提供优势。
Operator 与 Kubernetes API 和 CLI 工具（如 kubectl 和 OpenShift CLI oc 命令）集成。它们提供了监控应用程序、执行健康检查、管理无线(OTA)更新的方法，并确保应用程序保持在指定的状态。
Operator 为 Kubernetes 原生应用程序专门设计，以实施并自动化常见的第 1 天操作，如安装和配置。Operator 也可以自动执行第 2 天操作，如自动缩放，创建备份。所有这些活动都由集群中运行的一个软件进行控制。
虽然这两个操作都遵循类似的 Operator 概念和目标，但 Red Hat OpenShift Service on AWS 中的 Operator 由两个不同的系统管理，具体取决于它们的目的：
- Cluster Operators
- 由 Cluster Version Operator (CVO) 管理并默认安装来执行集群功能。
- 可选的附加组件 Operator
- 由 Operator Lifecycle Manager (OLM) 管理，并可供用户在其应用程序中运行。也称为 基于 OLM 的 Operator。
1.1. 对于开发人员
作为 Operator 作者，您可以为基于 OLM 的 Operator 执行以下开发任务：
1.2. 对于管理员
作为具有 dedicated-admin 角色的管理员，您可以执行以下 Operator 任务：
1.3. 后续步骤
第 2 章 了解 Operator
2.1. 什么是 Operator?
从概念上讲，Operator 会收集人类操作知识，并将其编码成更容易分享给消费者的软件。
Operator 是一组软件，可用于降低运行其他软件的操作复杂程度。它可以被看作是软件厂商的工程团队的扩展，可以监控 Kubernetes 环境（如 Red Hat OpenShift Service on AWS），并使用其当前状态实时做出决策。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 （以及扩展，Red Hat OpenShift Service on AWS）包含构建复杂分布式系统（包括 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 Lifecycle Manager
- Operator Lifecycle Manager (OLM) 能够控制集群中 Operator 的安装、升级和基于角色的访问控制 (RBAC)。默认情况下，它在 Red Hat OpenShift Service on AWS 4 中部署。
- Operator Registry
- Operator Registry 存储 ClusterServiceVersions (CSV) 和自定义资源定义 (CRD) 以便在集群中创建，并存储有关软件包和频道的 Operator 元数据。它运行在 Kubernetes 或 OpenShift 集群中，向 OLM 提供这些 Operator 目录数据。
- OperatorHub
- OperatorHub 是一个 web 控制台，供集群管理员用来发现并选择要在其集群上安装的 Operator。它默认部署在 Red Hat OpenShift Service on AWS 中。
这些工具可组合使用，因此您可自由选择对您有用的工具。
2.1.3. Operator 成熟度模型
Operator 内部封装的管理逻辑的复杂程度各有不同。该逻辑通常还高度依赖于 Operator 所代表的服务类型。
对于大部分 Operator 可能包含的特定功能集来说，可以大致推断出 Operator 封装操作的成熟度等级。就此而言，以下 Operator 成熟度模型针对 Operator 的第二天通用操作定义了五个成熟度阶段：
图 2.1. Operator 成熟度模型
2.2. Operator Framework 打包格式
本指南概述了 Red Hat OpenShift Service on AWS 中 Operator Lifecycle Manager (OLM)支持的 Operator 打包格式。
2.2.1. 捆绑包格式
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 目录中。
捆绑包格式布局示例
额外支持的对象
以下对象类型也可以包括在捆绑包的 /manifests 目录中：
支持的可选对象类型
-
ClusterRole -
ClusterRoleBinding -
ConfigMap -
ConsoleCLIDownload -
ConsoleLink -
ConsoleQuickStart -
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- 使用这个类型，作者可以使用 group/version/kind(GVK)信息指定依赖项，类似于 CSV 中现有 CRD 和基于 API 的使用量。该路径使 Operator 作者可以合并所有依赖项、API 或显式版本，使它们处于同一位置。
olm.constraint- 这个类型在任意 Operator 属性上声明通用限制。
在以下示例中，为 Prometheus Operator 和 etcd CRD 指定依赖项：
dependencies.yaml 文件示例
2.2.1.4. 关于 opm CLI
opm CLI 工具由 Operator Framework 提供,用于 Operator 捆绑格式。您可以通过此工具从与软件存储库类似的 Operator 捆绑包列表中创建和维护 Operator 目录。其结果是一个容器镜像，它可以存储在容器的 registry 中，然后安装到集群中。
目录包含一个指向 Operator 清单内容的指针数据库，可通过在运行容器镜像时提供的已包含 API 进行查询。在 Red Hat OpenShift Service on AWS 上，Operator Lifecycle Manager (OLM)可以在由 CatalogSource 对象定义的目录源中引用镜像，它会定期轮询镜像，以对集群上安装的 Operator 进行更新。
2.2.2. 亮点
基于文件的目录是 Operator Lifecycle Manager (OLM) 中目录格式的最新迭代。它是基于纯文本（JSON 或 YAML）和早期 SQLite 数据库格式的声明式配置演变，并且完全向后兼容。此格式的目标是启用 Operator 目录编辑、可组合性和可扩展性。
- 编辑
使用基于文件的目录，与目录内容交互的用户可以对格式进行直接更改，并验证其更改是否有效。由于这种格式是纯文本 JSON 或 YAML，因此目录维护人员可以通过手动或广泛支持的 JSON 或 YAML 工具（如
jqCLI）轻松操作目录元数据。此可编辑功能启用以下功能和用户定义的扩展：
- 将现有捆绑包提升到新频道
- 更改软件包的默认频道
- 用于添加、更新和删除升级路径的自定义算法
- Composability
基于文件的目录存储在任意目录层次结构中，从而启用目录组成。例如，考虑两个单独的基于文件的目录目录：
catalogA和catalogB。目录维护人员可以通过生成新目录catalogC并将catalogA和catalogB复制到其中来创建新的组合目录。这种可组合性支持分散的目录。格式允许 Operator 作者维护特定于 Operator 的目录，它允许维护人员轻松构建由单个 Operator 目录组成的目录。基于文件的目录可以通过组合多个其他目录、提取一个目录的子集或两者的组合来组成。
注意不允许软件包中重复软件包和重复捆绑包。如果找到任何重复项，
opm validate命令将返回错误。因为 Operator 作者最熟悉其 Operator、其依赖项及其升级兼容性，所以他们可以维护自己的 Operator 目录并直接控制其内容。对于基于文件的目录，Operator 作者负责在目录中构建和维护其软件包的任务。但是，复合目录维护者仅拥有在其目录中管理软件包并将目录发布到用户的任务。
- 可扩展性
基于文件的目录规格是目录的一个低级别表示。虽然目录维护器可以直接以低级形式维护，但目录维护人员可以在其自己的自定义工具上构建有趣的扩展，以供其自身的自定义工具用于实现任意数量的变异。
例如，工具可以将一个高级 API （如
(mode=semver)） 转换为升级路径基于文件的低级别目录格式。或目录维护人员可能需要通过添加新属性到符合特定标准的捆绑包来自定义所有捆绑包元数据。虽然这种可扩展性允许在低级别 API 上开发额外的官方工具，用于将来的 Red Hat OpenShift Service on AWS 版本，但目录维护人员也具有此功能。
从 Red Hat OpenShift Service on AWS 4.11 开始，默认的红帽提供的 Operator 目录以基于文件的目录格式发布。通过以过时的 SQLite 数据库格式发布的 4.10，Red Hat OpenShift Service on AWS 4.6 的默认红帽提供的 Operator 目录。
与 SQLite 数据库格式相关的 opm 子命令、标志和功能已被弃用，并将在以后的版本中删除。功能仍被支持，且必须用于使用已弃用的 SQLite 数据库格式的目录。
许多 opm 子命令和标志都用于 SQLite 数据库格式，如 opm index prune，它们无法使用基于文件的目录格式。有关使用基于文件的目录的更多信息，请参阅管理自定义目录。
2.2.2.1. 目录结构
基于文件的目录可从基于目录的文件系统进行存储和加载。opm CLI 通过遍历根目录并递归到子目录来加载目录。CLI 尝试加载它找到的每个文件，如果发生错误，则会失败。
可以使用 .indexignore 文件忽略非目录文件，这些文件对模式和优先级与 .gitignore 文件具有相同的规则。
示例 .indexignore 文件
目录维护人员具有选择所需的布局的灵活性，但建议将每个软件包基于文件的目录 Blob 存储在单独的子目录中。每个单独的文件可以是 JSON 或 YAML；目录中的每一文件并不需要使用相同的格式。
基本推荐结构
此推荐结构具有目录层次结构中的每个子目录都是自包含目录的属性，它使得目录组成、发现和导航简单文件系统操作。通过将目录复制到父目录的根目录，目录也可以包含在父目录中。
2.2.2.2. 模式
基于文件的目录使用基于 CUE 语言规范 的格式，该格式可使用任意模式进行扩展。以下 _Meta CUE 模式定义了所有基于文件的目录 Blob 必须遵循的格式：
_Meta 架构
此规格中列出的 CUE 模式不可被视为详尽模式。opm validate 命令具有额外的验证，很难或不可能在 CUE 中简洁地表达。
Operator Lifecycle Manager (OLM) 目录目前使用三种模式（olm.package、olm.channel 和 olm.bundle），它们对应于 OLM 的现有软件包和捆绑包概念。
目录中的每个 Operator 软件包都需要一个 olm.package blob、至少一个 olm.channel blob 以及一个或多个 olm.bundle blob。
所有 olm.* 模式都为 OLM 定义的模式保留。自定义模式必须使用唯一前缀，如您拥有的域。
2.2.2.2.1. olm.package schema
olm.package 模式为 Operator 定义软件包级别的元数据。这包括其名称、描述、默认频道和图标。
例 2.1. olm.package schema
2.2.2.2.2. olm.channel schema
olm.channel 模式在软件包中定义频道、属于频道成员的捆绑包条目，以及这些捆绑包的升级路径。
如果捆绑包条目代表多个 olm.channel blob 中的边缘，则每个频道只能显示一次。
它对条目的 replaces 值有效，以引用无法在此目录或其他目录中找到的另一捆绑包名称。但是，所有其他频道变量都必须为 true，比如频道没有多个磁头。
例 2.2. olm.channel schema
在使用 skipRange 字段时，跳过的 Operator 版本会从更新图中删除，因此不再可以被带有 Subscription 对象的 spec.startingCSV 属性的用户安装。
您可以使用 skipRange 和 replaces 字段以递增方式更新 Operator，同时保留以前安装的版本供用户使用。确保 replaces 字段指向相关的 Operator 版本前一个版本。
2.2.2.2.3. olm.bundle schema
例 2.3. olm.bundle schema
2.2.2.2.4. olm.deprecations schema
可选的 olm.deprecations 模式定义了目录中软件包、捆绑包和频道的弃用信息。Operator 作者可使用此模式向从目录运行这些 Operator 的用户提供与 Operator 相关的信息，如支持状态和推荐的升级路径。
当定义了此模式时，Red Hat OpenShift Service on AWS Web 控制台会在 OperatorHub 的前和安装后页面中显示 Operator 受影响元素的警告徽标，包括任何自定义弃用信息。
olm.deprecations schema 条目包含一个或多个 reference 类型，这表示弃用范围。安装 Operator 后，可以在相关的 Subscription 对象上查看任何指定的信息作为状态条件。
| 类型 | 影响范围 | 状态条件 |
|---|---|---|
|
| 代表整个软件包 |
|
|
| 代表一个频道 |
|
|
| 表示一个捆绑包版本 |
|
每个 reference 类型都有自己的要求，如下例所示。
例 2.4. 带有每个 reference 类型的 olm.deprecations 模式示例
弃用功能没有考虑重叠的弃用，例如，软件包与频道与捆绑包的比较。
Operator 作者可在与软件包的 index.yaml 文件相同的目录中将 olm.deprecations schema 条目保存为 deprecations.yaml 文件：
带有弃用的目录的目录结构示例
my-catalog
└── my-operator
├── index.yaml
└── deprecations.yaml
my-catalog
└── my-operator
├── index.yaml
└── deprecations.yaml2.2.2.3. Properties
属性是可附加到基于文件的目录方案的任意元数据片段。type 字段是一个有效指定 value 字段语义和语法含义的字符串。该值可以是任意 JSON 或 YAML。
OLM 定义几个属性类型，再次使用保留的 olm.* 前缀。
2.2.2.3.1. olm.package 属性
olm.package 属性定义软件包名称和版本。这是捆绑包上的必要属性，必须正好有一个这些属性。packageName 字段必须与捆绑包的 first-class package 字段匹配，并且 version 字段必须是有效的语义版本。
例 2.5. olm.package 属性
2.2.2.3.2. olm.gvk 属性
olm.gvk 属性定义此捆绑包提供的 Kubernetes API 的 group/version/kind (GVK)。OLM 使用此属性解析捆绑包，作为列出与所需 API 相同的 GVK 的其他捆绑包的依赖项。GVK 必须遵循 Kubernetes GVK 验证。
例 2.6. olm.gvk 属性
2.2.2.3.3. olm.package.required
olm.package.required 属性定义此捆绑包需要的另一软件包的软件包名称和版本范围。对于捆绑包列表的每个所需软件包属性，OLM 确保集群中为列出的软件包和所需版本范围安装了一个 Operator。versionRange 字段必须是有效的语义版本（模拟）范围。
例 2.7. olm.package.required 属性
2.2.2.3.4. olm.gvk.required
olm.gvk.required 属性定义此捆绑包需要的 Kubernetes API 的 group/version/kind (GVK)。对于捆绑包列表的每个必需的 GVK 属性，OLM 确保集群中安装了提供它的 Operator。GVK 必须遵循 Kubernetes GVK 验证。
例 2.8. olm.gvk.required 属性
2.2.2.4. 目录示例
对于基于文件的目录，目录维护人员可以专注于 Operator 策展和兼容性。由于 Operator 作者已为其 Operator 创建了特定于 Operator 的目录，因此目录维护人员可以通过将每个 Operator 目录渲染到目录根目录的子目录来构建其目录。
构建基于文件的目录的方法有很多；以下步骤概述了一个简单的方法：
为目录维护一个配置文件，其中包含目录中每个 Operator 的镜像引用：
目录配置文件示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行一个脚本，该脚本将解析配置文件并从其引用中创建新目录：
脚本示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.2.2.5. 指南
在维护基于文件的目录时，请考虑以下准则。
2.2.2.5.1. 不可变捆绑包
Operator Lifecycle Manager (OLM) 的常规建议是捆绑包镜像及其元数据应视为不可变。
如果一个错误的捆绑包被推送到目录，您必须假设至少有一个用户已升级到该捆绑包。基于这种假设，您必须从损坏的捆绑包中发布另一个带有升级路径的捆绑包，以确保安装了有问题的捆绑包的用户收到升级。如果目录中更新了该捆绑包的内容，OLM 将不会重新安装已安装的捆绑包。
然而，在某些情况下首选更改目录元数据：
-
频道升级：如果您已发布了捆绑包，且之后决定将其添加到另一个频道，您可以在另一个
olm.channelblob 中添加捆绑包条目。 -
新的升级路径：如果您发布一个新的
1.2.z捆绑包版本，如1.2.4，但1.3.0已发布，您可以更新1.3.0的目录元数据以跳过1.2.4。
2.2.2.5.2. 源控制
目录元数据应存储在源控制中，并被视为事实来源。目录镜像的更新应包括以下步骤：
- 使用新的提交来更新源控制的目录目录。
-
构建并推送目录镜像。使用一致的标记分类，如
:latest或:<target_cluster_version>，以便用户可以在目录可用时接收到更新。
2.2.2.6. CLI 用法
有关使用 opm CLI 创建基于文件的目录的说明，请参阅管理自定义目录。
2.2.2.7. 自动化
建议 Operator 作者和目录维护人员使用 CI/CD 工作流自动化其目录维护。目录维护人员可通过构建 GitOps 自动化以完成以下任务来进一步改进：
- 检查是否允许拉取请求 (PR) 作者进行请求的更改，例如更新其软件包的镜像引用。
-
检查目录更新是否通过
opm validate命令。 - 检查是否有更新的捆绑包或目录镜像引用，目录镜像在集群中成功运行，来自该软件包的 Operator 可以成功安装。
- 自动合并通过之前检查的 PR。
- 自动重新构建和重新发布目录镜像。
2.3. Operator Framework 常用术语表
本主题提供了与 Operator Framework 相关的常用术语表，包括 Operator Lifecycle Manager (OLM)。
2.3.1. 捆绑包（Bundle）
在 Bundle Format 中，捆绑包是 Operator CSV、清单和元数据的集合。它们一起构成了可在集群中安装的 Operator 的唯一版本。
2.3.2. 捆绑包镜像
在 Bundle Format 中， 捆绑包镜像是一个从 Operator 清单中构建的容器镜像，其中包含一个捆绑包。捆绑包镜像由 Open Container Initiative (OCI) spec 容器 registry 存储和发布，如 Quay.io 或 DockerHub。
2.3.3. 目录源
目录源 catalog source 代表 OLM 可查询的元数据存储，以发现和安装 Operator 及其依赖项。
2.3.4. Channel
频道为 Operator 定义更新流，用于为订阅者推出更新。频道头指向该频道的最新版本。例如，stable 频道中会包含 Operator 的所有稳定版本，按由旧到新的顺序排列。
Operator 可以有几个频道，与特定频道绑定的订阅只会在该频道中查找更新。
2.3.5. 频道头
频道头是指特定频道中最新已知的更新。
2.3.6. 集群服务版本
集群服务版本（cluster service version，简称 CSV 是一个利用 Operator 元数据创建的 YAML 清单，可辅助 OLM 在集群中运行 Operator。它是 Operator 容器镜像附带的元数据，用于在用户界面填充徽标、描述和版本等信息。
此外，CSV 还是运行 Operator 所需的技术信息来源，类似于其需要的 RBAC 规则及其管理或依赖的自定义资源 (CR)。
2.3.7. 依赖项
Operator 可能会依赖于集群中存在的另一个 Operator。例如，Vault Operator 依赖于 etcd Operator 的数据持久性层。
OLM 通过确保在安装过程中在集群中安装 Operator 和 CRD 的所有指定版本来解决依赖关系。通过在目录中查找并安装满足所需 CRD API 且与软件包或捆绑包不相关的 Operator，解决这个依赖关系。
2.3.8. 扩展
扩展可让集群管理员在其 Red Hat OpenShift Service on AWS 集群上扩展功能。扩展由 Operator Lifecycle Manager (OLM) v1 管理。
ClusterExtension API 简化了已安装的扩展的管理，其中包括通过 registry+v1 捆绑包格式的 Operator，通过将面向用户的 API 整合到单个对象中。管理员和 SRE 可使用 API 自动进程并使用 GitOps 原则定义所需状态。
2.3.9. 索引镜像
在 Bundle Format 中， 索引镜像是一种数据库（数据库快照）镜像，其中包含关于 Operator 捆绑包（包括所有版本的 CSV 和 CRD）的信息。此索引可以托管集群中 Operator 的历史记录，并可使用 opm CLI 工具添加或删除 Operator 来加以维护。
2.3.10. 安装计划
安装计划（install plan）是一个列出了为自动安装或升级 CSV 而需创建的资源的计算列表。
2.3.11. 多租户
Red Hat OpenShift Service on AWS 中的 租户 是为一组部署的工作负载（通常由命名空间或项目表示）共享通用访问权限和特权的用户或组。您可以使用租户在不同的组或团队之间提供一定程度的隔离。
当集群由多个用户或组共享时，它被视为 多租户 集群。
2.3.12. Operator
Operator 是一种打包、部署和管理 Kubernetes 应用程序的方法。Kubernetes 应用程序是一款 app，可在 Kubernetes 上部署，也可使用 Kubernetes API 和 kubectl 或 oc 工具进行管理。
Operator Lifecycle Manager (OLM) v1，ClusterExtension API 简化了已安装的扩展的管理，其中包括通过 registry+v1 捆绑包格式的 Operator，通过将面向用户的 API 整合到单个对象中。
2.3.13. operator 组
Operator 组将部署在同一命名空间中的所有 Operator 配置为 OperatorGroup 对象，以便在一系列命名空间或集群范围内监视其 CR。
2.3.14. 软件包
在 Bundle Format 中，软件包是一个目录，其中包含每个版本的 Operator 的发布历史记录。CSV 清单中描述了发布的 Operator 版本和 CRD。
2.3.15. 容器镜像仓库（Registry）
Registry 是一个存储了 Operator 捆绑包镜像的数据库，每个都包含所有频道的最新和历史版本。
2.3.16. Subscription
订阅（subscription） 通过跟踪软件包中的频道来保持 CSV 最新。
2.3.17. 更新图表
更新图表将 CSV 的版本关联到一起，与其他打包软件的更新图表类似。可以依次安装 Operator，也可以跳过某些版本。只有在添加新版本时，更新图表才会在频道头上扩大。
也称为更新边缘（update edges）或更新路径（update paths）。
2.4. Operator Lifecycle Manager (OLM)
2.4.1. Operator Lifecycle Manager 概念和资源
本指南概述了 Red Hat OpenShift Service on AWS 中 Operator Lifecycle Manager (OLM)的概念。
2.4.1.1. 什么是 Operator Lifecycle Manager (OLM) Classic？
Operator Lifecycle Manager (OLM) Classic 可帮助用户安装、更新和管理 Kubernetes 原生应用程序(Operator)以及在 Red Hat OpenShift Service on AWS 集群中运行的关联服务的生命周期。它是 Operator Framework 的一部分，后者是一个开源工具包，用于以有效、自动化且可扩展的方式管理 Operator。
图 2.2. OLM (Classic) 工作流
OLM 默认在 AWS 4 上的 Red Hat OpenShift Service 中运行，辅助集群管理员对集群上运行的 Operator 进行安装、升级和授予访问权。Red Hat OpenShift Service on AWS 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)代表了在 Red Hat OpenShift Service on AWS 集群中运行的 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 及其依赖项。Red Hat OpenShift Service on AWS Web 控制台中的 OperatorHub 也会显示由目录源提供的 Operator。
集群管理员可以使用 web 控制台中的 Administration → Cluster Settings → Configuration → OperatorHub 页面查看集群中已启用的目录源提供的 Operator 的完整列表。
CatalogSource 的 spec 指明了如何构造 pod，以及如何与服务于 Operator Registry gRPC API 的服务进行通信。
例 2.9. CatalogSource 对象示例
- 1
CatalogSource对象的名称。此值也用作在请求的命名空间中创建相关 pod 的名称的一部分。- 2
- 要创建目录的命名空间。要使目录在所有命名空间中都可用，请将此值设置为
openshift-marketplace。默认红帽提供的目录源也使用openshift-marketplace命名空间。否则，将值设置为特定命名空间，使 Operator 仅在该命名空间中可用。 - 3
- 可选：为避免集群升级可能会使 Operator 安装处于不受支持的状态或没有持续更新路径，您可以启用自动更改 Operator 目录的索引镜像版本作为集群升级的一部分。
将
olm.catalogImageTemplate注解设置为索引镜像名称，并使用一个或多个 Kubernetes 集群版本变量，如为镜像标签构建模板时所示。该注解会在运行时覆盖spec.image字段。如需了解更多详细信息，请参阅"用于自定义目录源的镜像模板"。 - 4
- 在 Web 控制台和 CLI 中显示目录的名称。
- 5
- 目录的索引镜像。在使用
olm.catalogImageTemplate注解时，也可以省略，该注解会在运行时设置 pull spec。 - 6
- 目录源的权重。OLM 在依赖项解析过程中使用权重进行优先级排序。权重越高，表示目录优先于轻量级目录。
- 7
- 源类型包括以下内容：
-
带有
镜像引用的grpc：OLM 拉取镜像并运行 pod，为兼容的 API 服务。 -
带有
地址字段的grpc：OLM 会尝试联系给定地址的 gRPC API。在大多数情况下不应该使用这种类型。 -
configmap：OLM 解析配置映射数据，并运行一个可以为其提供 gRPC API 的 pod。
-
带有
- 8
- 指定
legacy或restricted的值。如果没有设置该字段，则默认值为legacy。在以后的 Red Hat OpenShift Service on AWS 发行版本中，计划默认值为restricted。如果您的目录无法使用restricted权限运行，建议您手动将此字段设置为legacy。 - 9
- 可选： 对于
grpc类型目录源，请覆盖在spec.image中提供内容的 pod 的默认节点选择器（如果定义）。 - 10
- 可选： 对于
grpc类型目录源，请覆盖在spec.image中提供内容的 pod 的默认优先级类名称（如果定义）。Kubernetes 默认提供system-cluster-critical和system-node-critical优先级类。将字段设置为空 ("") 可为 pod 分配默认优先级。可以手动定义其他优先级类。 - 11
- 可选： 对于
grpc类型目录源，请覆盖spec.image中提供内容的 pod 的默认容限（如果定义）。 - 12
- 在指定的时间段内自动检查新版本以保持最新。
- 13
- 目录连接的最后观察到状态。例如：
-
READY：成功建立连接。 -
CONNECTING：连接正在尝试建立。 -
TRANSIENT_FAILURE：尝试建立连接（如超时）时发生了临时问题。该状态最终将切回到CONNECTING，然后重试。
如需了解更多详细信息，请参阅 gRPC 文档中的连接状态。
-
- 14
- 存储目录镜像的容器注册表最近轮询的时间，以确保镜像为最新版本。
- 15
- 目录的 Operator Registry 服务的状态信息。
在订阅中引用 CatalogSource 对象的名称会指示 OLM 搜索查找请求的 Operator 的位置：
例 2.10. 引用目录源的 Subscription 对象示例
2.4.1.2.2.1. 自定义目录源的镜像模板
与底层集群的 Operator 兼容性可以通过目录源以各种方式表示。其中一种用于红帽默认提供的目录源的方法是识别为特定平台发行版本（如 Red Hat OpenShift Service on AWS 4）特别创建的索引镜像的镜像标签。
在集群升级过程中，默认红帽提供的目录源的索引镜像标签由 Cluster Version Operator (CVO) 自动更新，以便 Operator Lifecycle Manager (OLM) 拉取目录的更新版本。例如，在从 Red Hat OpenShift Service on AWS 4.18 升级到 4 的过程中，redhat-operators 目录的 CatalogSource 对象中的 spec.image 字段被更新：
registry.redhat.io/redhat/redhat-operator-index:v4.19
registry.redhat.io/redhat/redhat-operator-index:v4.19改为：
registry.redhat.io/redhat/redhat-operator-index:v4.19
registry.redhat.io/redhat/redhat-operator-index:v4.19但是，CVO 不会自动更新自定义目录的镜像标签。为确保用户在集群升级后仍然安装兼容并受支持的 Operator，还应更新自定义目录以引用更新的索引镜像。
从 Red Hat OpenShift Service on AWS 4.9 开始，集群管理员可以将 CatalogSource 对象中的 olm.catalogImageTemplate 注解添加到包含模板的镜像引用中。模板中支持使用以下 Kubernetes 版本变量：
-
kube_major_version -
kube_minor_version -
kube_patch_version
您必须指定 Kubernetes 集群版本，而不是 Red Hat OpenShift Service on AWS 集群版本，因为后者目前不适用于模板。
如果您已创建并推送了带有指定更新 Kubernetes 版本标签的索引镜像，设置此注解可使自定义目录中的索引镜像版本在集群升级后自动更改。注解值用于设置或更新 CatalogSource 对象的 spec.image 字段中的镜像引用。这有助于避免集群升级，从而避免在不受支持的状态或没有持续更新路径的情况下安装 Operator。
您必须确保集群可在集群升级时访问带有更新标签的索引镜像（无论存储在哪一 registry 中）。
例 2.11. 带有镜像模板的目录源示例
如果设置了 spec.image 字段和 olm.catalogImageTemplate 注解，则 spec.image 字段会被注解中的解析值覆盖。如果注解没有解析为可用的 pull spec，目录源会回退到设置的 spec.image 值。
如果没有设置 spec.image 字段，且注解没有解析为可用的 pull spec，OLM 会停止目录源的协调，并将其设置为人类可读的错误条件。
对于 AWS 4 集群上的 Red Hat OpenShift Service，它使用 Kubernetes 1.32，上例中的 olm.catalogImageTemplate 注解会解析为以下镜像引用：
quay.io/example-org/example-catalog:v1.32
quay.io/example-org/example-catalog:v1.32
对于 Red Hat OpenShift Service on AWS 的未来发行版本，您可以为自定义目录创建更新的索引镜像，该镜像以以后的 Red Hat OpenShift Service on AWS 版本使用为目标。在升级前设置了 olm.catalogImageTemplate 注解，将集群升级到更新的 Red Hat OpenShift Service on AWS 版本，然后自动更新目录的索引镜像。
2.4.1.2.2.2. 目录健康要求
集群上的 Operator 目录可从安装解析视角进行交换； Subscription 对象可能会引用特定目录，但依赖项会根据集群中的所有目录解决。
例如，如果 Catalog A 不健康，则引用 Catalog A 的订阅可能会解析 Catalog B 中的依赖项，集群管理员可能还没有预期，因为 B 通常具有比 A 更低的目录优先级。
因此，OLM 要求所有具有给定全局命名空间的目录（例如，默认的 openshift-marketplace 命名空间或自定义全局命名空间）都健康。当目录不健康时，其共享全局命名空间中的所有 Operator 或更新操作都将因为 CatalogSourcesUnhealthy 条件而失败。如果这些操作处于不健康状态，OLM 可能会做出对集群管理员意外的解析和安装决策。
作为集群管理员，如果您观察一个不健康的目录，并希望将目录视为无效并恢复 Operator 安装，请参阅"删除自定义目录"或"Disabling the default OperatorHub 目录源"部分，以了解有关删除不健康目录的信息。
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）。
除了从 Red Hat OpenShift Service on AWS 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.12. 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 资源的 Spec.Conditions 数组中存在时，则代表存在一组会影响 OLM 管理 Operator 的支持条件。
默认情况下，OperatorCondition 对象中没有 Spec.Conditions 数组，直到由用户添加或使用自定义 Operator 逻辑的结果为止。
2.4.2. Operator Lifecycle Manager 架构
本指南概述了 Red Hat OpenShift Service on AWS 中 Operator Lifecycle Manager (OLM)的组件架构。
2.4.2.1. 组件职责
Operator Lifecycle Manager (OLM) 由两个 Operator 组成，分别为：OLM Operator 和 Catalog Operator。
OLM 和 Catalog Operator 负责管理作为 OLM 框架基础的自定义资源定义(CRD)：
| 资源 | 短名称 | 所有者 | 描述 |
|---|---|---|---|
|
|
| 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 工作流
本指南概述了 Red Hat OpenShift Service on AWS 中的 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 被分为 软件包和更新 流，称为 频道，这应该是 Red Hat OpenShift Service on AWS 或其他软件（如 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 依赖项解析
本指南概述了 Red Hat OpenShift Service on AWS 中的 Operator Lifecycle Manager (OLM)与依赖项解析和自定义资源定义(CRD)升级生命周期。
2.4.4.1. 关于依赖项解析
Operator Lifecycle Manager(OLM)管理运行 Operator 的依赖项解析和升级生命周期。在很多方面，OLM 的问题与其他系统或语言软件包管理器类似，如 yum 和 rpm。
但其中有一个限制是相似系统一般不存在而 OLM 存在的，那就是：因为 Operator 始终在运行，所以 OLM 会努力确保您所接触的 Operator 组始终相互兼容。
因此，OLM 不得创建以下情况：
- 安装一组需要无法提供的 API 的 Operator
- 更新某个 Operator 之时导致依赖该 Operator 的另一 Operator 中断
这可以通过两种类型的数据：
| Properties | 在依赖项解析器中输入构成了公共接口的 Operator 元数据。示例包括 Operator 提供的 API 的 group/version/kind(GVK)，以及 Operator 的语义版本(semver)。 |
| 约束或依赖项 | 应该对可能或还没有在目标集群中安装的其他 Operator 满足 Operator 的要求。它们充当所有可用 Operator 的查询或过滤，并在依赖项解析和安装过程中限制选择。例如，需要特定的 API 在集群中可用，或希望安装带有特定版本的特定 Operator。 |
OLM 将这些属性和约束转换为布尔值公式系统，并将其传递给 SAT solver，SAT solver 是一个处理布尔值的程序，用于确定应该安装哪些 Operator。
2.4.4.2. Operator 属性
目录中的所有 Operator 均具有以下属性：
olm.package- 包括软件包和 Operator 版本的名称
olm.gvk- 集群服务版本(CSV)中每个提供的 API 的单个属性
Operator 作者也可以在 Operator 捆绑包的 metadata/ 目录中包括 properties.yaml 文件来直接声明其他属性。
任意（arbitrary）属性示例
properties:
- type: olm.kubeversion
value:
version: "1.16.0"
properties:
- type: olm.kubeversion
value:
version: "1.16.0"2.4.4.2.1. 任意属性
Operator 作者可在 Operator 捆绑包的 metadata/ 目录中的 properties.yaml 文件中声明任意属性。这些属性转换为映射数据结构，该结构用作运行时 Operator Lifecycle Manager(OLM)解析器的输入。
这些属性对解析器不理解属性而不理解这些属性，但可以针对这些属性评估通用限制，以确定约束是否可以满足给定的属性列表。
任意属性示例
此结构可用于为通用限制构建通用表达式语言(CEL)表达式。
其他资源
2.4.4.3. Operator 依赖项
Operator 的依赖项列在捆绑包的 metadata/ 目录中的 dependencies.yaml 文件中。此文件是可选的，目前仅用于指明 Operator-version 依赖项。
依赖项列表中，每个项目包含一个 type 字段，用于指定这一依赖项的类型。支持以下 Operator 依赖项：
olm.package-
这个类型表示特定 Operator 版本的依赖项。依赖项信息必须包含软件包名称以及软件包的版本，格式为 semver。例如，您可以指定具体版本，如
0.5.2，也可指定一系列版本，如>0.5.1。 olm.gvk- 使用这个类型，作者可以使用 group/version/kind(GVK)信息指定依赖项，类似于 CSV 中现有 CRD 和基于 API 的使用量。该路径使 Operator 作者可以合并所有依赖项、API 或显式版本，使它们处于同一位置。
olm.constraint- 这个类型在任意 Operator 属性上声明通用限制。
在以下示例中，为 Prometheus Operator 和 etcd CRD 指定依赖项：
dependencies.yaml 文件示例
2.4.4.4. 通用限制
olm.constraint 属性声明特定类型的依赖项约束，区分非约束和约束属性。其 value 字段是一个包含 failureMessage 字段的对象，其中包含约束消息的字符串表。如果约束在运行时不满意，则这一消息被作为信息性提供给用户使用。
以下键表示可用的约束类型：
gvk-
其值及对其的解释与
olm.gvk类型相同的类型 package-
其值及对其的解释与
olm.package类型相同的类型 cel- Operator Lifecycle Manager(OLM)解析程序通过任意捆绑包属性和集群信息在运行时评估的通用表达式语言(CEL)表达式
all,any,not-
分别为 Conjunction, disjunction, 和 negation 约束，包括一个或多个 concrete 约束，如
gvk或一个嵌套的 compound 约束
2.4.4.4.1. 常见表达式语言(CEL)约束
cel 约束类型支持将通用表达式语言(CEL) 用作表达式语言。cel struct 有一个 rule 字段，其中包含在运行时针对 Operator 属性评估的 CEL 表达式字符串，以确定 Operator 是否满足约束。
cel 约束示例
type: olm.constraint
value:
failureMessage: 'require to have "certified"'
cel:
rule: 'properties.exists(p, p.type == "certified")'
type: olm.constraint
value:
failureMessage: 'require to have "certified"'
cel:
rule: 'properties.exists(p, p.type == "certified")'
CEL 语法支持广泛的逻辑运算符，如 AND 和 OR。因此，单个 CEL 表达式可以具有多个规则，这些条件由这些逻辑运算符链接在一起。这些规则针对来自捆绑包或任何给定源的多个不同属性的数据评估，输出可以解决单一约束内满足所有这些规则的捆绑包或 Operator。
使用多个规则的 cel 约束示例
type: olm.constraint
value:
failureMessage: 'require to have "certified" and "stable" properties'
cel:
rule: 'properties.exists(p, p.type == "certified") && properties.exists(p, p.type == "stable")'
type: olm.constraint
value:
failureMessage: 'require to have "certified" and "stable" properties'
cel:
rule: 'properties.exists(p, p.type == "certified") && properties.exists(p, p.type == "stable")'2.4.4.4.2. Compound 约束 (all, any, not)
复合约束类型按照其逻辑定义进行评估。
以下是两个软件包的 conjunctive 约束（all）的示例，以及一个 GVK。这代表，安装捆绑包都必须满足它们：
all 约束示例
以下是同一个 GVK 的三个版本的 disjunctive 约束 (any) 示例。这代表，安装捆绑包必须至少满足其中一项：
any 约束示例
以下是 GVK 的一个版本的 negation 约束（not）的示例。这代表，此 GVK 无法由结果集中的任何捆绑包提供：
not 约束示例
对于 not 约束，其中的负语义可能并不明确。这里的负语义代表指示解析器删除所有可能的解决方案，这些解决方案包括特定 GVK、特点版本的软版本，或满足结果集中的一些子复合约束。
not compound 约束不应该和 all 或 any 一起使用，因为这里的负语言在没有先选择一组可能的依赖项时是并没有意义。
2.4.4.4.3. 嵌套复合限制
一个嵌套复合约束（包括最少一个子复合约束以及零个或更多简单约束）会从底向上的顺序被评估，并根据每个前面描述的约束类型的过程进行。
以下是一个 disjunction 的 conjunctions 示例，其中一个、另一个、或两者都能满足约束：
嵌套复合约束示例
olm.constraint 类型的最大原始大小为 64KB，用于限制资源耗尽的情况。
2.4.4.5. 依赖项首选项
有很多选项同样可以满足 Operator 的依赖性。Operator Lifecycle Manager（OLM）中的依赖项解析器决定哪个选项最适合所请求 Operator 的要求。作为 Operator 作者或用户，了解这些选择非常重要，以便明确依赖项解析。
2.4.4.5.1. 目录优先级
在 Red Hat OpenShift Service on AWS 集群中，OLM 会读取目录源以了解哪些 Operator 可用于安装。
CatalogSource 对象示例
- 1
- 指定
legacy或restricted的值。如果没有设置该字段，则默认值为legacy。在以后的 Red Hat OpenShift Service on AWS 发行版本中，计划默认值为restricted。如果您的目录无法使用restricted权限运行，建议您手动将此字段设置为legacy。
CatalogSource 有一个 priority 字段，解析器使用它来知道如何为依赖关系设置首选选项。
目录首选项有两个规则：
- 优先级较高目录中的选项优先于较低优先级目录的选项。
- 与依赖项相同的目录里的选项优先于其它目录。
2.4.4.5.2. 频道排序
目录中的 Operator 软件包是用户可在 Red Hat OpenShift Service on AWS 集群中订阅的更新频道集合。可使用频道为次发行版本（1.2, 1.3）或者发行的频率（stable, fast）提供特定的更新流。
同一软件包中的 Operator 可能会满足依赖项，但可能会在不同的频道。例如，Operator 版本 1.2 可能存在于 stable 和 fast 频道中。
每个软件包都有一个默认频道，该频道总是首选非默认频道。如果默认频道中没有选项可以满足依赖关系，则会在剩余的频道中按频道名称的字母顺序考虑这些选项。
2.4.4.5.3. 频道中的顺序
一般情况下，总会有多个选项来满足单一频道中的依赖关系。例如，一个软件包和频道中的 Operator 提供了相同的 API 集。
当用户创建订阅时，它们会指示要从哪个频道接收更新。这会立即把搜索范围限制在那个频道。但是在频道中，可以会有许多 Operator 可以满足依赖项。
在频道中，应该首选考虑使用更新图中位置较高的较新的 Operator。如果某个频道的头满足依赖关系，它将会被首先尝试。
2.4.4.5.4. 其他限制
除了软件包依赖关系的限制外，OLM 还添加了其他限制来代表所需用户状态和强制实施解析变量。
2.4.4.5.4.1. 订阅约束
一个订阅（Subscription）约束会过滤可满足订阅的 Operator 集合。订阅是对依赖项解析程序用户提供的限制。它们会声明安装一个新的 Operator（如果还没有在集群中安装），或对现有 Operator 进行更新。
2.4.4.5.4.2. 软件包约束
在命名空间中，不同的两个 Operator 不能来自于同一软件包。
2.4.4.6. CRD 升级
如果自定义资源定义（CRD）属于单一集群服务版本（CSV），OLM 会立即对其升级。如果某个 CRD 被多个 CSV 拥有，则当该 CRD 满足以下所有向后兼容条件时才会升级：
- 所有已存在于当前 CRD 中的服务版本都包括在新 CRD 中。
- 在根据新 CRD 的验证模式（schema）进行验证后，与 CRD 的服务版本关联的所有现有实例或自定义资源均有效。
2.4.4.7. 依赖项最佳实践
在指定依赖项时应该考虑的最佳实践。
- 依赖于 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.8. 依赖项注意事项
当指定依赖项时，需要考虑一些注意事项。
- 没有捆绑包约束（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.9. 依赖项解析方案示例
在以下示例中，provider（供应商） 是指"拥有" CRD 或 API 服务的 Operator。
2.4.4.9.1. 示例：弃用从属 API
A 和 B 是 API（CRD）：
- A 的供应商依赖 B。
- B 的供应商有一个订阅。
- B 更新供应商提供 C，但弃用 B。
结果：
- B 不再有供应商。
- A 不再工作。
这是 OLM 通过升级策略阻止的一个案例。
2.4.4.9.2. 示例：版本死锁
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 组
本指南概述了 Red Hat OpenShift Service on AWS 中 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 组时，会生成三个集群角色。当生成集群角色时，会自动在最后添加一个哈希值，以确保每个集群角色都是唯一的。每个 Operator 组均包含一个聚会规则，后者带有一个选择器以匹配标签，如下所示：
| 集群角色 | 要匹配的标签 |
|---|---|
|
|
|
|
|
|
|
|
|
要使用 Operator 组的集群角色为资源分配基于角色的访问控制 (RBAC)，请运行以下命令获取包括集群角色和哈希值的完整名称：
oc get clusterroles | grep <operatorgroup_name>
$ oc get clusterroles | grep <operatorgroup_name>因为哈希值是在创建 Operator 组时生成的，所以在查找集群角色的完整名称前，需要先创建 Operator 组。
当 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。
默认情况下禁用 disableCopiedCSVs 字段。启用 disableCopiedCSVs 字段后，OLM 会删除集群中的现有复制的 CSV。当 disableCopiedCSVs 字段被禁用时，OLM 会再次添加复制的 CSV。
禁用
disableCopiedCSVs字段：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 启用
disableCopiedCSVs字段：Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 组的命名空间始终包含在其所选目标命名空间中。
2.4.5.9.1. 交集规则
每次活跃成员 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 管理的限制
Red Hat OpenShift Service on AWS 对在同一集群中安装不同版本的 Operator 提供了有限的支持。Operator Lifecycle Manager (OLM) 会在不同的命名空间中多次安装 Operator。其中一个限制是 Operator 的 API 版本必须相同。
Operator 是控制平面的扩展，因为它们使用了 CustomResourceDefinition 对象 (CRD)，它们是 Kubernetes 中的全局资源。一个 Operator 的不同主版本通常具有不兼容的 CRD。这使得它们不兼容，可以在集群中的不同命名空间中安装。
所有租户或命名空间共享同一集群的 control plane。因此，多租户集群中的租户也共享全局 CRD，这限制同一集群中可以并行使用同一 Operator 实例的不同 Operator 实例。
支持的场景包括：
- 提供相同 CRD 定义的不同版本的 Operator （如果版本化 CRD，则完全相同的版本）
- 没有提供 CRD 的不同版本的 Operator，并在 OperatorHub 上的单独捆绑包中提供它们的 CRD
不支持所有其他场景，因为如果不同 Operator 版本中的多个竞争或重叠 CRD 在同一集群中协调，则无法保证集群数据的完整性。
2.4.5.11. 对 Operator 组进行故障排除
2.4.5.11.1. 成员资格
安装计划的命名空间必须只包含一个 Operator 组。当尝试在命名空间中生成集群服务版本（CSV）时，安装计划会认为一个 Operator 组在以下情况下无效：
- 安装计划的命名空间中没有 Operator 组。
- 安装计划的命名空间中存在多个 Operator 组。
- 在 Operator 组中指定不正确或不存在的服务帐户名称。
如果安装计划遇到无效的 Operator 组，则不会生成 CSV，
InstallPlan资源将继续使用相关消息进行安装。例如，如果同一命名空间中存在多个 Operator 组，则会提供以下信息：attenuated service account query failed - more than one operator group(s) are managing this namespace count=2
attenuated service account query failed - more than one operator group(s) are managing this namespace count=2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中
count=指定命名空间中的 Operator 组数量。-
如果 CSV 的安装模式不支持其命名空间中 Operator 组的目标命名空间选择，CSV 会转变为故障状态，原因为
UnsupportedOperatorGroup。处于故障状态的 CSV 会在 Operator 组的目标命名空间选择变为受支持的配置后转变为待处理，或者 CSV 的安装模式被修改来支持目标命名空间选择。
2.4.6. 多租户和 Operator 共处
本指南概述了 Operator Lifecycle Manager (OLM) 中的多租户和 Operator 共处。
2.4.6.1. 命名空间中的 Operator 共处
Operator Lifecycle Manager (OLM) 处理在同一命名空间中安装的 OLM 管理的 Operator，这意味着其 Subscription 资源与相关 Operator 位于同一个命名空间中。即使它们实际不相关，OLM 会在更新其中任何一个时考虑其状态，如它们的版本和更新策略。
这个默认行为清单可以通过两种方式：
-
待处理的更新的
InstallPlan资源包括同一命名空间中的所有其他 Operator 的ClusterServiceVersion(CSV) 资源。 - 同一命名空间中的所有 Operator 都共享相同的更新策略。例如，如果一个 Operator 设置为手动更新，则所有其他 Operator 更新策略也会设置为 manual。
这些场景可能会导致以下问题：
- 很难了解有关 Operator 更新安装计划的原因，因为它们中定义了除更新 Operator 以外的更多资源。
- 在命名空间更新中，无法自动更新一些 Operator，而其他 Operator 也无法手动更新，这对集群管理员来说很常见。
这些问题通常是在使用 Red Hat OpenShift Service on AWS Web 控制台安装 Operator 时，默认行为会将支持 All namespaces 安装模式的 Operator 安装到默认的 openshift-operators 全局命名空间中。
作为集群管理员，您可以使用以下工作流手动绕过此默认行为：
- 为 Operator 的安装创建一个命名空间。
- 创建自定义 全局 Operator 组，这是监视所有命名空间的 Operator 组。通过将此 Operator 组与您刚才创建的命名空间关联，从而使安装命名空间成为全局命名空间，从而使 Operator 在所有命名空间中都可用。
- 在安装命名空间中安装所需的 Operator。
如果 Operator 具有依赖项，依赖项会在预先创建的命名空间中自动安装。因此，它对依赖项 Operator 有效，使其具有相同的更新策略和共享安装计划。具体步骤，请参阅“在自定义命名空间中安装全局 Operator"。
2.4.7. Operator 条件
本指南概述了 Operator Lifecycle Manager（OLM）如何使用 Operator 条件。
2.4.7.1. 关于 Operator 条件
作为管理 Operator 生命周期的角色的一部分，Operator Lifecycle Manager（OLM）从定义 Operator 的 Kubernetes 资源状态中推断 Operator 状态。虽然此方法提供了一定程度的保证来确定 Operator 处于给定状态，但在有些情况下，Operator 可能需要直接向 OLM 提供信息，而这些信息不能被推断出来。这些信息可以被 OLM 使用来更好地管理 Operator 的生命周期。
OLM 提供了一个名为 OperatorCondition 的自定义资源定义（CRD），它允许 Operator 与 OLM 相互通信条件信息。当在一个 OperatorCondition 资源的 Spec.Conditions 数组中存在时，则代表存在一组会影响 OLM 管理 Operator 的支持条件。
默认情况下，OperatorCondition 对象中没有 Spec.Conditions 数组，直到由用户添加或使用自定义 Operator 逻辑的结果为止。
2.4.7.2. 支持的条件
Operator Lifecycle Manager（OLM）支持以下 Operator 条件。
2.4.7.2.1. Upgradeable（可升级）条件
Upgradeable Operator 条件可防止现有集群服务版本（CSV）被 CSV 的新版本替换。这一条件在以下情况下很有用：
- Operator 即将启动关键进程，不应在进程完成前升级。
- Operator 正在执行一个自定义资源（CR）迁移，这个迁移必须在 Operator 准备进行升级前完成。
将 Upgradeable Operator 条件设置为 False 值不会避免 pod 中断。如果需要确保 pod 没有中断，请参阅"使用 pod 中断预算来指定必须在线的 pod 数量，以及 "Additional resources" 部分的 "Graceful termination"。
Upgradeable Operator 条件
2.4.8. Operator Lifecycle Manager 指标数据
2.4.8.1. 公开的指标
Operator Lifecycle Manager (OLM)会公开某些 OLM 特定资源，供基于 Prometheus 的 Red Hat OpenShift Service on AWS 集群监控堆栈使用。
| 名称 | 描述 |
|---|---|
|
| 目录源数量。 |
|
|
目录源的状态。值 |
|
|
在协调集群服务版本（CSV）时，每当 CSV 版本处于 |
|
| 成功注册的 CSV 数量。 |
|
|
在协调 CSV 时，代表 CSV 版本处于 |
|
| CSV 升级的 Monotonic 计数。 |
|
| 安装计划的数量。 |
|
| 由资源生成的警告数量（如已弃用资源）包含在安装计划中。 |
|
| 依赖项解析尝试的持续时间。 |
|
| 订阅数。 |
|
|
订阅同步的单调计数。包括 |
2.4.9. Operator Lifecycle Manager 中的 Webhook 管理
Webhook 允许 Operator 作者在资源被保存到对象存储并由 Operator 控制器处理之前，拦截、修改、接受或拒绝资源。当 webhook 与 Operator 一同提供时，Operator Lifecycle Manager（OLM）可以管理这些 webhook 的生命周期。
2.5. 了解 OperatorHub
2.5.1. 关于 OperatorHub
OperatorHub 是 Red Hat OpenShift Service on AWS 中的 Web 控制台界面，集群管理员用于发现和安装 Operator。只需单击一次，即可从其非集群源拉取 Operator，并将其安装和订阅至集群中，为工程团队使用 Operator Lifecycle Manager (OLM) 在部署环境中自助管理产品做好准备。
集群管理员可从划分为以下类别的目录进行选择：
| 类别 | 描述 |
|---|---|
| 红帽 Operator | 已由红帽打包并提供的红帽产品。受红帽支持。 |
| 经认证的 Operator | 来自主要独立软件供应商 (ISV) 的产品。红帽与 ISV 合作打包并提供。受 ISV 支持。 |
| 社区 Operator | 由 redhat-openshift-ecosystem/community-operators-prod/operators GitHub 存储库中相关代表维护的可选可见软件。无官方支持。 |
| 自定义 Operator | 您自行添加至集群的 Operator。如果您尚未添加任何自定义 Operator，则您的 OperatorHub 上 Web 控制台中便不会出现自定义类别。 |
OperatorHub 上的操作员被打包在 OLM 上运行。这包括一个称为集群服务版本（CSV）的 YAML 文件，其中包含安装和安全运行 Operator 所需的所有 CRD 、RBAC 规则、Deployment 和容器镜像。它还包含用户可见的信息，如功能描述和支持的 Kubernetes 版本。
2.5.2. OperatorHub 架构
OperatorHub UI 组件默认由 openshift-marketplace 命名空间中的 Red Hat OpenShift Service on AWS 驱动。
2.5.2.1. OperatorHub 自定义资源
Marketplace Operator 管理名为 cluster 的 OperatorHub 自定义资源（CR），用于管理 OperatorHub 提供的默认 CatalogSource 对象。您可以修改此资源以启用或禁用默认目录，这在受限网络环境中配置 Red Hat OpenShift Service on AWS 时很有用。
OperatorHub 自定义资源示例
2.6. 红帽提供的 Operator 目录
红帽提供几个默认包含在 Red Hat OpenShift Service on AWS 中的 Operator 目录。
从 Red Hat OpenShift Service on AWS 4.11 开始，默认的红帽提供的 Operator 目录以基于文件的目录格式发布。通过以过时的 SQLite 数据库格式发布的 4.10，Red Hat OpenShift Service on AWS 4.6 的默认红帽提供的 Operator 目录。
与 SQLite 数据库格式相关的 opm 子命令、标志和功能已被弃用，并将在以后的版本中删除。功能仍被支持，且必须用于使用已弃用的 SQLite 数据库格式的目录。
许多 opm 子命令和标志都用于 SQLite 数据库格式，如 opm index prune，它们无法使用基于文件的目录格式。有关使用基于文件的目录的更多信息，请参阅管理自定义目录和 Operator Framework 打包格式。
2.6.1. 关于 Operator 目录
Operator 目录是 Operator Lifecycle Manager（OLM）可以查询的元数据存储库，以在集群中发现和安装 Operator 及其依赖项。OLM 始终从目录的最新版本安装 Operator。
基于 Operator Bundle Format 的索引镜像是目录的容器化快照。这是一个不可变的工件，包含指向一组 Operator 清单内容的指针数据库。目录可以引用索引镜像来获取集群中 OLM 的内容。
随着目录的更新，Operator 的最新版本会发生变化，旧版本可能会被删除或修改。另外，当 OLM 在受限网络环境中的 Red Hat OpenShift Service on AWS 集群上运行时，它无法直接从互联网访问目录来拉取最新的内容。
作为集群管理员，您可以根据红帽提供的目录或从头创建自己的自定义索引镜像，该镜像可用于提供集群中的目录内容。创建和更新您自己的索引镜像提供了一种方法来自定义集群上可用的一组 Operator，同时避免了上面提到的受限网络环境中的问题。
Kubernetes 定期弃用后续版本中删除的某些 API。因此，从使用删除 API 的 Kubernetes 版本的 Red Hat OpenShift Service on AWS 开始，Operator 无法使用删除的 API。
在 Red Hat OpenShift Service on AWS 4.8 及更高版本中删除了对 Operator 的传统软件包清单格式的支持，包括使用传统格式的自定义目录。
在创建自定义目录镜像时，使用 oc adm catalog build 命令需要 Red Hat OpenShift Service on AWS 4 的早期版本，它已在几个版本中被弃用，现在已被删除。从 Red Hat OpenShift Service on AWS 4.6 开始，红帽提供的索引镜像可用后，目录构建器必须使用 opm index 命令来管理索引镜像。
2.6.2. 关于红帽提供的 Operator 目录
在 openshift-marketplace 命名空间中默认安装红帽提供的目录源，从而使目录在所有命名空间中都可用。
以下 Operator 目录由红帽发布：
| 目录 | 索引镜像 | 描述 |
|---|---|---|
|
|
| 已由红帽打包并提供的红帽产品。受红帽支持。 |
|
|
| 来自主要独立软件供应商 (ISV) 的产品。红帽与 ISV 合作打包并提供。受 ISV 支持。 |
|
|
| 由 redhat-openshift-ecosystem/community-operators-prod/operators GitHub 仓库中相关代表维护的软件。无官方支持。 |
在集群升级过程中，默认红帽提供的目录源的索引镜像标签由 Cluster Version Operator (CVO) 自动更新，以便 Operator Lifecycle Manager (OLM) 拉取目录的更新版本。例如，在从 Red Hat OpenShift Service on AWS 4.8 升级到 4.9 的过程中，redhat-operators 目录的 CatalogSource 对象中的 spec.image 字段被更新：
registry.redhat.io/redhat/redhat-operator-index:v4.8
registry.redhat.io/redhat/redhat-operator-index:v4.8改为：
registry.redhat.io/redhat/redhat-operator-index:v4.9
registry.redhat.io/redhat/redhat-operator-index:v4.92.7. 多租户集群中的 Operator
Operator Lifecycle Manager (OLM) 的默认行为旨在简化 Operator 的安装过程。但是，此行为可能会缺少灵活性，特别是在多租户集群中。为了使 Red Hat OpenShift Service on AWS 集群上的多个租户使用 Operator，OLM 的默认行为要求管理员以 All namespaces 模式安装 Operator，这可被视为违反最小特权的原则。
请考虑以下场景，以确定哪个 Operator 安装工作流最适合您的环境和要求。
2.7.1. 默认 Operator 安装模式和行为
当以管理员身份使用 Web 控制台安装 Operator 时，通常会根据 Operator 的功能，对安装模式有两个选择：
- 单个命名空间
- 在所选命名空间中安装 Operator，并发出 Operator 请求在该命名空间中提供的所有权限。
- 所有命名空间
-
将 Operator 安装至默认
openshift-operators命名空间，以便供集群中的所有命名空间监视和使用。进行所有命名空间中 Operator 请求的所有权限。在某些情况下，Operator 作者可以定义元数据，为用户授予该 Operator 建议的命名空间的第二个选项。
此选择还意味着受影响命名空间中的用户可以访问 Operator API，该 API 可以利用他们拥有的自定义资源 (CR)，具体取决于命名空间中的角色：
-
namespace-admin和namespace-edit角色可以对 Operator API 进行读/写，这意味着他们可以使用它们。 -
namespace-view角色可以读取该 Operator 的 CR 对象。
对于 Single namespace 模式，因为 Operator 本身安装在所选命名空间中，所以其 pod 和服务帐户也位于那里。对于 All namespaces 模式，Operator 的权限会自动提升到集群角色，这意味着 Operator 在所有命名空间中都有这些权限。
2.7.2. 多租户集群的建议解决方案
虽然 Multinamespace 安装模式存在，但只有少数 Operator 支持它。作为标准 All namespaces 和 Single namespace 安装模式之间的中间解决方案，您可以使用以下工作流安装同一 Operator 的多个实例，每个租户一个实例：
- 为租户 Operator 创建命名空间，与租户的命名空间分开。
- 为租户 Operator 创建 Operator 组，范围仅限于租户的命名空间。
- 在租户 Operator 命名空间中安装 Operator。
因此，Operator 驻留在租户 Operator 命名空间中，并监视租户命名空间，但 Operator 的 pod 及其服务帐户都无法被租户可见或可用。
此解决方案以资源使用量成本提供更好的租户分离，以及确保满足约束的额外编配功能。如需详细步骤，请参阅"为多租户集群准备 Operator 的多个实例"。
限制和注意事项
只有在满足以下限制时，这个解决方案才可以正常工作：
- 同一 Operator 的所有实例都必须是相同的版本。
- Operator 无法依赖于其他 Operator。
- Operator 无法提供 CRD 转换 Webhook。
您不能在同一集群中使用相同的 Operator 的不同版本。最后，当 Operator 的安装满足以下条件时，会阻断另一个 Operator 实例：
- 实例不是 Operator 的最新版本。
- 该实例提供了一个较老的 CRD 修订，它缺少新修订版本已在集群中使用的信息或版本。
作为管理员，在允许非集群管理员自行安装 Operator 时请小心，如"允许非集群管理员安装 Operator"中所述。这些租户应只能访问已知没有依赖项的 Operator 策展目录。这些租户也必须强制使用 Operator 的同一版本行，以确保 CRD 不会改变。这需要使用命名空间范围的目录，并可能会禁用全局默认目录。
2.7.3. Operator 共处和 Operator 组
Operator Lifecycle Manager (OLM) 处理在同一命名空间中安装的 OLM 管理的 Operator，这意味着其 Subscription 资源与相关 Operator 位于同一个命名空间中。即使它们实际不相关，OLM 会在更新其中任何一个时考虑其状态，如它们的版本和更新策略。
如需有关 Operator 共处和使用 Operator 组的更多信息，请参阅 Operator Lifecycle Manager (OLM)→ Multitenancy 和 Operator colocation。
2.8. CRD
2.8.1. 管理自定义资源定义中的资源
本指南向开发人员介绍了如何管理来自自定义资源定义 (CRD) 的自定义资源 (CR)。
2.8.1.1. 自定义资源定义
在 Kubernetes API 中，resource（资源）是存储某一类 API 对象集的端点。例如，内置 Pod 资源包含一组 Pod 对象。
自定义资源定义（CRD）对象在集群中定义一个新的、唯一的对象类型，称为 kind，并允许 Kubernetes API 服务器处理其整个生命周期。
自定义资源 (CR) 对象由集群管理员通过集群中已添加的 CRD 创建，并支持所有集群用户在项目中增加新的资源类型。
Operator 会通过将 CRD 与任何所需 RBAC 策略和其他软件特定逻辑打包到一起来利用 CRD。
2.8.1.2. 通过文件创建自定义资源
将自定义资源定义 (CRD) 添加至集群后，可使用 CLI 按照自定义资源 (CR) 规范通过文件创建 CR。
流程
为 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.8.1.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 创建应用程序
本指南向开发人员介绍了使用 Red Hat OpenShift Service on AWS Web 控制台从已安装的 Operator 创建应用程序的示例。
3.1.1. 使用 Operator 创建 etcd 集群
本流程介绍了如何通过由 Operator Lifecycle Manager (OLM) 管理的 etcd Operator 来新建一个 etcd 集群。
先决条件
- 访问 AWS 4 集群上的 Red Hat OpenShift Service。
- 管理员已在集群范围内安装了 etcd Operator。
流程
-
为此，在 Red Hat OpenShift Service on AWS 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 运行不畅，或在集群中的节点之间迁移时，该集群将对故障做出反应并重新平衡数据。最重要的是，具有适当访问权限的集群管理员或开发人员现在可轻松将该数据库用于其应用程序。
第 4 章 管理员任务
4.1. 在集群中添加 Operator
通过使用 Operator Lifecycle Manager (OLM)，具有 dedicated-admin 角色的管理员可以将基于 OLM 的 Operator 安装到 Red Hat OpenShift Service on AWS 集群中。
如需有关 OLM 如何处理在同一命名空间中并置安装的 Operator 的更新，以及使用自定义全局 Operator 组安装 Operator 的替代方法，请参阅多租户和 Operator 共处。
4.1.1. 关于使用 OperatorHub 安装 Operator
OperatorHub 是一个发现 Operator 的用户界面，它与 Operator Lifecycle Manager（OLM）一起工作，后者在集群中安装和管理 Operator。
作为集群管理员，您可以使用 Red Hat OpenShift Service on AWS 从 OperatorHub 安装 Operator
安装过程中，您必须为 Operator 确定以下初始设置：
- 更新频道
- 如果某个 Operator 可通过多个频道获得，则可任选您想要订阅的频道。例如，要通过 stable 频道部署（如果可用），则从列表中选择这个选项。
- 批准策略
您可以选择自动或者手动更新。
如果选择自动更新某个已安装的 Operator，则当所选频道中有该 Operator 的新版本时，Operator Lifecycle Manager（OLM）将自动升级 Operator 的运行实例，而无需人为干预。
如果选择手动更新，则当有新版 Operator 可用时，OLM 会创建更新请求。作为集群管理员，您必须手动批准该更新请求，才可将 Operator 更新至新版本。
4.1.2. 使用 Web 控制台，从 OperatorHub 安装
您可以使用 Red Hat OpenShift Service on AWS Web 控制台从 OperatorHub 安装并订阅 Operator。
先决条件
- 使用具有以下的帐户访问 Red Hat OpenShift Service on AWS 集群
流程
- 在 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 的特定版本，请从列表中选择 Update channel 和 Version。您可以在可能具有的任何频道中浏览 Operator 的不同版本，查看该频道和版本的元数据，然后选择您要安装的确切版本。
注意版本选择默认为所选频道的最新版本。如果选择了频道的最新版本，则默认启用 Automatic 批准策略。如果没有为所选频道安装最新版本，则需要手动批准。
使用手动批准安装 Operator 会导致命名空间中安装的所有 Operator 并使用 Manual 批准策略和所有 Operator 一起更新。如果要独立更新 Operator，将 Operator 安装到单独的命名空间中。
确认 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 安装至默认
对于启用了令牌身份验证的云供应商上的集群：
- 如果集群在 web 控制台中使用 AWS 安全令牌服务(STS Mode )，在角色 ARN 字段中输入服务帐户的 AWS IAM 角色的 Amazon Resource Name ( ARN )。要创建角色的 ARN，请按照 准备 AWS 帐户 中所述的步骤进行操作。
- 如果集群使用 Microsoft Entra Workload ID (Web 控制台中的Workload Identity / Federated Identity Mode )，请在适当的项中添加客户端 ID、租户 ID 和订阅 ID。
- 如果集群使用 Google Cloud Platform Workload Identity (GCP Workload Identity / Federated Identity Mode )，请在适当的字段中添加项目号、池 ID、供应商 ID 和服务帐户电子邮件。
对于 更新批准，请选择 Automatic 或 Manual 批准策略。
重要如果 Web 控制台显示集群使用 AWS STS、Microsoft Entra Workload ID 或 GCP Workload Identity，您必须将 Update approval 设置为 Manual。
不建议使用具有自动批准更新的订阅，因为在更新前可能会进行权限更改。具有手动批准更新的订阅可确保管理员有机会验证后续版本的权限，执行任何必要的步骤，然后进行更新。
点 Install 使 Operator 可供此 Red Hat OpenShift Service on AWS 集群上的所选命名空间使用：
如果选择了手动批准策略，订阅的升级状态将保持在 Upgrading 状态，直至您审核并批准安装计划。
在 Install Plan 页面批准后，订阅的升级状态将变为 Up to date。
- 如果选择了 Automatic 批准策略，升级状态会在不用人工参与的情况下变为 Up to date。
验证
在订阅的升级状态变为 Up to date 后，选择 Operators → Installed Operators 来验证已安装 Operator 的集群服务版本(CSV)是否最终出现了。状态 最终会在相关命名空间中变为 Succeeded。
注意对于 All namespaces… 安装模式，状态会在
openshift-operators命名空间中解析为 Succeeded，但如果检查其他命名空间，则状态为 Copied。如果没有：
-
检查
openshift-operators项目（如果选择了 A specific namespace… 安装模式）中的 openshift-operators 项目中的 pod 的日志，这会在 Workloads → Pods 页面中报告问题以便进一步排除故障。
-
检查
安装 Operator 时，元数据会指示安装了哪个频道和版本。
注意此目录上下文中仍可使用 Channel 和 Version 下拉菜单查看其他版本元数据。
4.1.3. 使用 CLI 从 OperatorHub 安装
您可以使用 CLI 从 OperatorHub 安装 Operator，而不必使用 Red Hat OpenShift Service on AWS Web 控制台。使用 oc 命令来创建或更新一个订阅对象。
对于 SingleNamespace 安装模式，还必须确保相关命名空间中存在适当的 Operator 组。一个 Operator 组（由 OperatorGroup 对象定义），在其中选择目标命名空间，在其中为与 Operator 组相同的命名空间中的所有 Operator 生成所需的 RBAC 访问权限。
在大多数情况下，使用 Web 控制台是首选的方法，因为它会在后台自动执行任务，比如在选择 SingleNamespace 模式时自动处理 OperatorGroup 和 Subscription 对象的创建。
先决条件
- 使用具有以下的帐户访问 Red Hat OpenShift Service on AWS 集群
-
已安装 OpenShift CLI(
oc)。
流程
查看 OperatorHub 中集群可用的 Operator 列表：
oc get packagemanifests -n openshift-marketplace
$ oc get packagemanifests -n openshift-marketplaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例 4.1. 输出示例
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 例 4.2. 输出示例
提示您可以运行以下命令来以 YAML 格式打印 Operator 的版本和频道信息：
oc get packagemanifests <operator_name> -n <catalog_namespace> -o yaml
$ oc get packagemanifests <operator_name> -n <catalog_namespace> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 如果在命名空间中安装多个目录，请运行以下命令从特定目录中查找 Operator 的可用版本和频道：
oc get packagemanifest \ --selector=catalog=<catalogsource_name> \ --field-selector metadata.name=<operator_name> \ -n <catalog_namespace> -o yaml
$ oc get packagemanifest \ --selector=catalog=<catalogsource_name> \ --field-selector metadata.name=<operator_name> \ -n <catalog_namespace> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要如果没有指定 Operator 的目录，运行
oc get packagemanifest和oc describe packagemanifest命令可能会在满足以下条件时从一个意料外的目录中返回一个软件包：- 在同一命名空间中安装多个目录。
- 目录包含具有相同名称的相同 Operator 或 Operator。
如果要安装的 Operator 支持
AllNamespaces安装模式，而您选择使用这个模式，请跳过这一步，因为openshift-operators命名空间默认有一个适当的 Operator 组，称为global-operators。如果要安装的 Operator 支持
SingleNamespace安装模式，而选择使用此模式，您必须确保相关命名空间中存在适当的 Operator 组。如果不存在，您可以按照以下步骤创建一个：重要每个命名空间只能有一个 Operator 组。如需更多信息，请参阅 "Operator 组"。
为
SingleNamespace安装模式创建一个OperatorGroup对象 YAML 文件，如operatorgroup.yaml：SingleNamespace安装模式的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对象来订阅一个命名空间到 Operator：为
Subscription对象创建一个 YAML 文件，如subscription.yaml：注意如果要订阅 Operator 的特定版本，请将
startCSV字段设置为所需的版本，并将installPlanApproval字段设置为Manual，以防止 Operator 在目录中有更新的版本时自动升级。详情请参阅以下 "ExampleSubscriptionobject with a specific starting Operator version"。例 4.3.
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 中必须存在的卷挂载列表。如果volumeMount引用不存在的卷，OLM 无法部署 Operator。- 10
tolerations参数为 OLM 创建的 pod 定义容限列表。- 11
resources参数为 OLM 创建的 pod 中所有容器定义资源限制。- 12
nodeSelector参数为 OLM 创建的 pod 定义NodeSelector。
对于启用了令牌身份验证的云供应商的集群，如 Amazon Web Services (AWS)安全令牌服务(STS)、Microsoft Entra Workload ID 或 Google Cloud Platform Workload Identity，按照以下步骤配置您的
Subscription对象：确保
Subscription对象被设置为手动更新批准：例 4.5. 带有手动更新批准的
Subscription对象示例kind: Subscription # ... spec: installPlanApproval: Manual
kind: Subscription # ... spec: installPlanApproval: Manual1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 不建议具有自动批准更新的订阅，因为在更新前可能会进行权限更改。具有手动批准更新的订阅可确保管理员有机会验证后续版本的权限，执行任何必要的步骤，然后更新。
在
Subscription对象的config部分包括相关的云供应商相关字段：如果集群处于 AWS STS 模式，请包含以下字段：
例 4.6. 使用 AWS STS 变量的
Subscription对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 包含角色 ARN 详情。
如果集群处于 Workload ID 模式，请包含以下字段：
例 4.7. 带有 Workload ID 变量的
Subscription对象示例如果集群处于 GCP Workload Identity 模式，请包括以下字段：
例 4.8. 带有 GCP Workload Identity 变量的
Subscription对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中：
<audience>当管理员设置 GCP Workload Identity 时，在 GCP 中创建，
AUDIENCE 值必须是以下格式的 URL：//iam.googleapis.com/projects/<project_number>/locations/global/workloadIdentityPools/<pool_id>/providers/<provider_id>
//iam.googleapis.com/projects/<project_number>/locations/global/workloadIdentityPools/<pool_id>/providers/<provider_id>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <service_account_email>SERVICE_ACCOUNT_email 值是在 Operator 操作过程中模拟的 GCP 服务帐户电子邮件，例如：<service_account_name>@<project_id>.iam.gserviceaccount.com
<service_account_name>@<project_id>.iam.gserviceaccount.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
运行以下命令来创建
Subscription对象：oc apply -f subscription.yaml
$ oc apply -f subscription.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
如果将
installPlanApproval字段设置为Manual，请手动批准待处理的安装计划以完成 Operator 安装。如需更多信息，请参阅"手动批准待处理的 Operator 更新"。
此时，OLM 已了解所选的 Operator。Operator 的集群服务版本（CSV）应出现在目标命名空间中，由 Operator 提供的 API 应可用于创建。
验证
运行以下命令，检查已安装的 Operator 的
Subscription对象状态：oc describe subscription <subscription_name> -n <namespace>
$ oc describe subscription <subscription_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您为
SingleNamespace安装模式创建了 Operator 组，请运行以下命令检查OperatorGroup对象的状态：oc describe operatorgroup <operatorgroup_name> -n <namespace>
$ oc describe operatorgroup <operatorgroup_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.4. 为多租户集群准备多个 Operator 实例
作为集群管理员，您可以添加多个 Operator 实例以用于多租户集群。这是使用标准 All namespaces 安装模式的替代解决方案，可被视为违反最小特权的原则，或 Multinamespace 模式（没有被广泛采用）。如需更多信息，请参阅"多租户集群中的Operator"。
在以下步骤中，租户 是为一组部署的工作负载共享通用访问和特权的用户或组。租户 Operator 是 Operator 实例，仅用于由该租户使用。
前提条件
您要安装的 Operator 的所有实例都必须在给定集群中相同。
重要有关这个限制和其他限制的更多信息，请参阅"多租户集群中的Operator"。
流程
在安装 Operator 前，为租户 Operator 创建一个命名空间，该 Operator 与租户的命名空间分开。例如，如果租户的命名空间是
team1，您可以创建一个team1-operator命名空间：定义
Namespace资源并保存 YAML 文件，如team1-operator.yaml：apiVersion: v1 kind: Namespace metadata: name: team1-operator
apiVersion: v1 kind: Namespace metadata: name: team1-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令创建命名空间：
oc create -f team1-operator.yaml
$ oc create -f team1-operator.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
为租户 Operator 创建 Operator 组，范围到租户的命名空间，只有
spec.targetNamespaces列表中有一个命名空间条目：定义
OperatorGroup资源并保存 YAML 文件，如team1-operatorgroup.yaml：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来创建 Operator 组：
oc create -f team1-operatorgroup.yaml
$ oc create -f team1-operatorgroup.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
后续步骤
在租户 Operator 命名空间中安装 Operator。通过在 Web 控制台中使用 OperatorHub 而不是 CLI 来更轻松地执行此任务；有关详细的流程，"使用 Web 控制台从 OperatorHub 安装"。
注意完成 Operator 安装后，Operator 驻留在租户 Operator 命名空间中，并监视租户命名空间，但 Operator 的 pod 及其服务帐户都无法被租户可见或可用。
4.1.5. 在自定义命名空间中安装全局 Operator
当使用 Red Hat OpenShift Service on AWS Web 控制台安装 Operator 时，默认行为会将支持 All namespaces 安装模式的 Operator 安装到默认的 openshift-operators 全局命名空间中。这可能导致与命名空间中所有 Operator 共享安装计划和更新策略相关的问题。有关这些限制的详情，请参阅 "Multitenancy 和 Operator colocation"。
作为集群管理员，您可以通过创建自定义全局命名空间并使用该命名空间安装单个或范围 Operator 及其依赖项来手动绕过此默认行为。
前提条件
-
您可以使用具有
cluster-admin角色的用户访问集群。
流程
在安装 Operator 前，为所需 Operator 安装创建一个命名空间。此安装命名空间将成为自定义全局命名空间：
定义
Namespace资源并保存 YAML 文件，如global-operators.yaml：apiVersion: v1 kind: Namespace metadata: name: global-operators
apiVersion: v1 kind: Namespace metadata: name: global-operatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令创建命名空间：
oc create -f global-operators.yaml
$ oc create -f global-operators.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
创建自定义 全局 Operator 组，这是监视所有命名空间的 Operator 组：
定义
OperatorGroup资源并保存 YAML 文件，如global-operatorgroup.yaml。省略spec.selector和spec.targetNamespaces字段，使其成为一个全局 Operator 组，该组选择所有命名空间：apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: global-operatorgroup namespace: global-operators
apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: global-operatorgroup namespace: global-operatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意创建的全局 OperatorGroup 的
status.namespace包含空字符串 ("")，而该字符串会向正在使用的 Operator 发出信号，要求其监视所有命名空间。运行以下命令来创建 Operator 组：
oc create -f global-operatorgroup.yaml
$ oc create -f global-operatorgroup.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
后续步骤
在自定义全局命名空间中安装所需的 Operator。因为 web 控制台在使用自定义全局命名空间的 Operator 安装过程中不会填充 Installed Namespace 菜单，所以安装任务只能通过 OpenShift CLI (
oc)来执行。如需详细的安装过程，请参阅"使用 CLI 安装 OperatorHub"。注意启动 Operator 安装时，如果 Operator 有依赖项，依赖项也会自动安装到自定义全局命名空间中。因此，它对依赖项 Operator 有效，使其具有相同的更新策略和共享安装计划。
4.1.6. 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.1.7. 控制安装 Operator 的位置
默认情况下，当安装 Operator 时，Red Hat OpenShift Service on AWS 会随机将 Operator pod 安装到其中一个 worker 节点。然而，在某些情况下，您可能希望该 pod 调度到特定节点或一组节点上。
以下示例描述了您可能希望将 Operator pod 调度到特定节点或一组节点的情况：
-
如果 Operator 需要特定的平台，如
amd64或arm64 - 如果 Operator 需要特定的操作系统，如 Linux 或 Windows
- 如果您希望 Operator 在同一个主机上或位于同一机架的主机上工作
- 如果您希望 Operator 在整个基础架构中分散，以避免因为网络或硬件问题而停机
您可以通过在 Operator 的 Subscription 对象中添加节点关联性、pod 关联性或 pod 反关联性限制来控制 Operator pod 的安装位置。节点关联性是由调度程序用来确定 pod 的可放置位置的一组规则。pod 关联性允许您确保将相关的 pod 调度到同一节点。通过 Pod 反关联性，您可以防止 pod 调度到节点上。
以下示例演示了如何使用节点关联性或 pod 反关联性将自定义 Metrics Autoscaler Operator 实例安装到集群中的特定节点：
将 Operator pod 放置到特定节点的节点关联性示例
- 1
- 要求 Operator 的 pod 调度到名为
ip-10-0-163-94.us-west-2.compute.internal的节点关联性。
将 Operator pod 放置到带有特定平台的节点关联性示例
- 1
- 要求 Operator 的 pod 调度到具有
kubernetes.io/arch=arm64和kubernetes.io/os=linux标签的节点上。
将 Operator pod 放置到一个或多个特定节点的 Pod 关联性示例
- 1
- 将 Operator 的 pod 放置到具有
app=test标签的 pod 的节点上的 pod 关联性。
防止 Operator pod 来自一个或多个特定节点的 Pod 反关联性示例
- 1
- 一个 pod 反关联性，它可防止 Operator 的 pod 调度到具有
cpu=high标签的 pod 的节点上。
流程
要控制 Operator pod 的放置，请完成以下步骤：
- 照常安装 Operator。
- 如果需要，请确保您的节点已标记为正确响应关联性。
编辑 Operator
Subscription对象以添加关联性：Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 添加
nodeAffinity、podAffinity或podAntiAffinity。有关创建关联性的详情，请参考下面的附加资源部分。
验证
要确保 pod 部署到特定的节点上，请运行以下命令：
$ oc get pods -o wide
$ oc get pods -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES custom-metrics-autoscaler-operator-5dcc45d656-bhshg 1/1 Running 0 50s 10.131.0.20 ip-10-0-185-229.ec2.internal <none> <none>
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES custom-metrics-autoscaler-operator-5dcc45d656-bhshg 1/1 Running 0 50s 10.131.0.20 ip-10-0-185-229.ec2.internal <none> <none>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2. 更新安装的 Operator
作为具有 dedicated-admin 角色的管理员，您可以更新之前使用 Red Hat OpenShift Service on AWS 集群上的 Operator Lifecycle Manager (OLM)安装的 Operator。
如需有关 OLM 如何处理在同一命名空间中并置安装的 Operator 的更新，以及使用自定义全局 Operator 组安装 Operator 的替代方法，请参阅多租户和 Operator 共处。
4.2.1. 准备 Operator 更新
已安装的 Operator 的订阅指定一个更新频道，用于跟踪和接收 Operator 的更新。您可以更改更新频道，以开始跟踪并从更新频道接收更新。
订阅中更新频道的名称可能会因 Operator 而异，但应遵守给定 Operator 中的常规约定。例如，频道名称可能会遵循 Operator 提供的应用程序的次发行版本更新流（1.2、1.3）或发行的频率（stable、fast）。
您不能将已安装的 Operator 更改为比当前频道旧的频道。
红帽客户门户网站 Labs 包括以下应用程序，可帮助管理员准备更新其 Operator：
您可以使用应用程序搜索基于 Operator Lifecycle Manager 的 Operator，并在 AWS 上的不同版本的 Red Hat OpenShift Service 中验证每个更新频道的可用 Operator 版本。不包含基于 Cluster Version Operator 的 Operator。
4.2.2. 更改 Operator 的更新频道
您可以使用 Red Hat OpenShift Service on AWS Web 控制台更改 Operator 的更新频道。
如果订阅中的批准策略被设置为 Automatic，则更新过程会在所选频道中提供新的 Operator 版本时立即启动。如果批准策略设为 Manual，则必须手动批准待处理的更新。
前提条件
- 之前使用 Operator Lifecycle Manager（OLM）安装的 Operator。
流程
- 在 web 控制台的 Administrator 视角中，导航到 Operators → Installed Operators。
- 点击您要更改更新频道的 Operator 名称。
- 点 Subscription 标签页。
- 点 Update channel 下的更新频道名称。
- 点要更改的更新频道，然后点 Save。
对于带有 自动批准策略 的订阅，更新会自动开始。返回到 Operators → Installed Operators 页面，以监控更新的进度。完成后，状态会变为 Succeeded 和 Up to date。
对于采用手动批准策略的订阅，您可以从 Subscription 选项卡中手动批准更新。
4.2.3. 手动批准待处理的 Operator 更新
如果已安装的 Operator 的订阅被设置为 Manual，则当其当前更新频道中发布新更新时，在开始安装前必须手动批准更新。
先决条件
- 之前使用 Operator Lifecycle Manager（OLM）安装的 Operator。
流程
- 在 Red Hat OpenShift Service on AWS 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
下面介绍如何删除或卸载之前使用 Red Hat OpenShift Service on AWS 集群上的 Operator Lifecycle Manager (OLM)安装的 Operator。
在尝试重新安装同一 Operator 前，您必须已成功并完全卸载了 Operator。没有正确地完全卸载 Operator 可能会留下一些资源，如项目或命名空间，处于"Terminating"状态，并导致尝试重新安装 Operator 时观察到 "error resolving resource" 消息。
4.3.1. 使用 Web 控制台从集群中删除 Operator
集群管理员可以使用 Web 控制台从所选命名空间中删除已安装的 Operator。
前提条件
-
您可以使用具有
dedicated-admin权限的账户访问 Red Hat OpenShift Service on AWS 集群 Web 控制台。
流程
- 进入到 Operators → Installed Operators 页面。
- 在 Filter by name 字段中滚动或输入关键字以查找您要删除的 Operator。然后点它。
在 Operator Details 页面右侧，从 Actions 列表中选择 Uninstall Operator。
此时会显示 Uninstall Operator? 对话框。
选择 Uninstall 来删除 Operator、Operator 部署和 pod。按照此操作，Operator 将停止运行，不再接收更新。
注意此操作不会删除 Operator 管理的资源，包括自定义资源定义 (CRD) 和自定义资源 (CR) 。Web 控制台和继续运行的集群资源启用的仪表板和导航项可能需要手动清理。要在卸载 Operator 后删除这些，您可能需要手动删除 Operator CRD。
4.3.2. 使用 CLI 从集群中删除 Operator
集群管理员可以使用 CLI 从所选命名空间中删除已安装的 Operator。
前提条件
- 您可以使用具有以下的帐户访问 Red Hat OpenShift Service on AWS 集群
-
OpenShift CLI (
oc)安装在您的工作站上。
流程
确保在
currentCSV字段中标识了订阅 Operator 的最新版本（如serverless-operator）。oc get subscription.operators.coreos.com serverless-operator -n openshift-serverless -o yaml | grep currentCSV
$ oc get subscription.operators.coreos.com serverless-operator -n openshift-serverless -o yaml | grep currentCSVCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
currentCSV: serverless-operator.v1.28.0
currentCSV: serverless-operator.v1.28.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 删除订阅（如
serverless-operator）：oc delete subscription.operators.coreos.com serverless-operator -n openshift-serverless
$ oc delete subscription.operators.coreos.com serverless-operator -n openshift-serverlessCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
subscription.operators.coreos.com "serverless-operator" deleted
subscription.operators.coreos.com "serverless-operator" deletedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用上一步中的
currentCSV值来删除目标命名空间中相应 Operator 的 CSV：oc delete clusterserviceversion serverless-operator.v1.28.0 -n openshift-serverless
$ oc delete clusterserviceversion serverless-operator.v1.28.0 -n openshift-serverlessCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
clusterserviceversion.operators.coreos.com "serverless-operator.v1.28.0" deleted
clusterserviceversion.operators.coreos.com "serverless-operator.v1.28.0" 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 中配置代理支持
如果在 AWS 集群上的 Red Hat OpenShift Service 上配置了全局代理，Operator Lifecycle Manager (OLM)会自动配置使用集群范围代理管理的 Operator。但是，您也可以配置已安装的 Operator 来覆盖全局代理服务器或注入自定义 CA 证书。
4.4.2. 注入自定义 CA 证书
当集群管理员使用配置映射向集群添加自定义 CA 证书时，Cluster Network Operator 会将用户提供的证书和系统 CA 证书合并为一个捆绑包（bundle）。您可以将这个合并捆绑包注入 Operator Lifecycle Manager (OLM) 上运行的 Operator 中，如果您有一个中间人（man-in-the-middle）HTTPS 代理，这将会有用。
先决条件
- 使用具有以下的帐户访问 Red Hat OpenShift Service on AWS 集群
- 使用配置映射添加自定义 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 注意Operator 的部署可能无法验证颁发机构，并显示
x509 certificate signed by unknown authority错误。即使在使用 Operator 订阅时注入自定义 CA，也会发生这个错误。在这种情况下，您可以使用 Operator 的订阅将mountPath设置为 trusted-ca 的/etc/ssl/certs。
4.5. 查看 Operator 状态
了解 Operator Lifecycle Manager (OLM) 中的系统状态，对于决定和调试已安装 Operator 的问题来说非常重要。OLM 可让您了解订阅和相关目录源的状态以及执行的操作。这样有助于用户更好地理解 Operator 的运行状况。
4.5.1. operator 订阅状况类型
订阅可报告以下状况类型：
| 状况 | 描述 |
|---|---|
|
| 用于解析的一个或多个目录源不健康。 |
|
| 缺少订阅的安装计划。 |
|
| 订阅的安装计划正在安装中。 |
|
| 订阅的安装计划失败。 |
|
| 订阅的依赖项解析失败。 |
默认 Red Hat OpenShift Service on AWS 集群 Operator 由 Cluster Version Operator (CVO)管理，它们没有 Subscription 对象。应用程序 Operator 由 Operator Lifecycle Manager（OLM）管理，它们具有 Subscription 对象。
4.5.2. 使用 CLI 查看 Operator 订阅状态
您可以使用 CLI 查看 Operator 订阅状态。
先决条件
-
您可以使用具有
dedicated-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
默认 Red Hat OpenShift Service on AWS 集群 Operator 由 Cluster Version Operator (CVO)管理，它们没有 Subscription 对象。应用程序 Operator 由 Operator Lifecycle Manager（OLM）管理，它们具有 Subscription 对象。
4.5.3. 使用 CLI 查看 Operator 目录源状态
您可以使用 CLI 查看 Operator 目录源的状态。
先决条件
-
您可以使用具有
dedicated-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 输出示例
NAME DISPLAY TYPE PUBLISHER AGE certified-operators Certified Operators grpc Red Hat 55m community-operators Community Operators grpc Red Hat 55m example-catalog Example Catalog grpc Example Org 2m25s redhat-operators Red Hat Operators grpc Red Hat 55m
NAME DISPLAY TYPE PUBLISHER AGE certified-operators Certified Operators grpc Red Hat 55m community-operators Community Operators grpc Red Hat 55m example-catalog Example Catalog grpc Example Org 2m25s redhat-operators Red Hat Operators grpc Red Hat 55mCopy 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 条件
作为具有 dedicated-admin 角色的管理员，您可以使用 Operator Lifecycle Manager (OLM) 管理 Operator 条件。
4.6.1. 覆盖 Operator 条件
作为集群管理员，您可能想要忽略由 Operator 报告的、支持的 Operator 条件。当存在时，Spec.Overrides 阵列中的 Operator 条件会覆盖 Spec.Conditions 阵列中的条件，以便集群管理员可以处理 Operator 向 Operator Lifecycle Manager（OLM）报告了不正确状态的情况。
默认情况下，OperatorCondition 对象中不存在 Spec.Overrides 数组，直到集群管理员添加为止。Spec.Conditions 数组还不存在，直到被用户添加或因为自定义 Operator 逻辑而添加为止。
例如，一个 Operator 的已知版本，它始终会告知它是不可升级的。在这种情况下，尽管报告是不可升级的，您仍然希望升级 Operator。这可以通过在 OperatorCondition 对象的 Spec.Overrides 阵列中添加 type 和 status 来覆盖 Operator 条件来实现。
先决条件
-
您可以使用具有
cluster-admin角色的用户访问集群。 -
具有
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 条件页面。
4.6.2.1. 设置默认值
为了保持向后兼容，OLM 认为在没有 OperatorCondition 时代表不使用条件。因此，要使用 Operator 条件的 Operator，在将 pod 的就绪探测设置为 true 前应设置默认条件。这为 Operator 提供了一个宽限期，用于将条件更新为正确的状态。
4.7. 管理自定义目录
具有 dedicated-admin 角色和 Operator 目录维护人员的管理员可以创建和管理使用 Red Hat OpenShift Service on AWS 的 Operator Lifecycle Manager (OLM)中 捆绑的自定义目录。
Kubernetes 定期弃用后续版本中删除的某些 API。因此，从使用删除 API 的 Kubernetes 版本的 Red Hat OpenShift Service on AWS 开始，Operator 无法使用删除的 API。
4.7.1. 先决条件
4.7.2. 基于文件的目录
基于文件的目录是 Operator Lifecycle Manager (OLM) 中目录格式的最新迭代。它是基于纯文本（JSON 或 YAML）和早期 SQLite 数据库格式的声明式配置演变，并且完全向后兼容。
从 Red Hat OpenShift Service on AWS 4.11 开始，默认的红帽提供的 Operator 目录以基于文件的目录格式发布。通过以过时的 SQLite 数据库格式发布的 4.10，Red Hat OpenShift Service on AWS 4.6 的默认红帽提供的 Operator 目录。
与 SQLite 数据库格式相关的 opm 子命令、标志和功能已被弃用，并将在以后的版本中删除。功能仍被支持，且必须用于使用已弃用的 SQLite 数据库格式的目录。
许多 opm 子命令和标志都用于 SQLite 数据库格式，如 opm index prune，它们无法使用基于文件的目录格式。有关使用基于文件的目录的更多信息，请参阅 Operator Framework 打包格式。
4.7.2.1. 创建基于文件的目录镜像
您可以使用 opm CLI 创建一个目录镜像，它使用纯文本（基于文件的目录）格式（JSON 或 YAML），替换已弃用的 SQLite 数据库格式。
先决条件
-
已安装
opmCLI。 -
您有
podman版本 1.9.3+。 - 已构建捆绑包镜像并推送到支持 Docker v2-2 的 registry。
流程
初始化目录：
运行以下命令，为目录创建一个目录：
mkdir <catalog_dir>
$ mkdir <catalog_dir>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行
opm generate dockerfile命令生成可构建目录镜像的 Dockerfile：opm generate dockerfile <catalog_dir> \ -i registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4 -i registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4$ opm generate dockerfile <catalog_dir> \ -i registry.redhat.io/openshift4/ose-operator-registry-rhel9:v41 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 使用
-i标志指定官方红帽基础镜像，否则 Dockerfile 使用默认的上游镜像。
Dockerfile 必须与您在上一步中创建的目录目录位于相同的父目录中：
目录结构示例
. ├── <catalog_dir> └── <catalog_dir>.Dockerfile
.1 ├── <catalog_dir>2 └── <catalog_dir>.Dockerfile3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行
opm init命令，使用 Operator 的软件包定义填充目录：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 此命令在指定的目录配置文件中生成
olm.package声明性配置 blob。
运行
opm render命令向目录添加捆绑包：opm render <registry>/<namespace>/<bundle_image_name>:<tag> \ --output=yaml \ >> <catalog_dir>/index.yaml$ opm render <registry>/<namespace>/<bundle_image_name>:<tag> \1 --output=yaml \ >> <catalog_dir>/index.yaml2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意频道必须至少包含一个捆绑包。
为捆绑包添加频道条目。例如，根据您的规格修改以下示例，并将其添加到
<catalog_dir>/index.yaml文件中：频道条目示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 确定在
<operator_name>之后、版本v中包含句点 (.)。否则，条目无法传递opm validate命令。
验证基于文件的目录：
针对目录目录运行
opm validate命令：opm validate <catalog_dir>
$ opm validate <catalog_dir>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 检查错误代码是否为
0:echo $?
$ echo $?Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
0
0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
运行
podman build命令构建目录镜像：podman build . \ -f <catalog_dir>.Dockerfile \ -t <registry>/<namespace>/<catalog_image_name>:<tag>$ podman build . \ -f <catalog_dir>.Dockerfile \ -t <registry>/<namespace>/<catalog_image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将目录镜像推送到 registry：
如果需要，运行
podman login命令与目标 registry 进行身份验证：podman login <registry>
$ podman login <registry>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行
podman push命令来推送目录镜像：podman push <registry>/<namespace>/<catalog_image_name>:<tag>
$ podman push <registry>/<namespace>/<catalog_image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7.3. 基于 SQLite 的目录
Operator 目录的 SQLite 数据库格式是一个弃用的功能。弃用的功能仍然包含在 Red Hat OpenShift Service on AWS 中，并且仍然被支持。但是，弃用的功能可能会在以后的发行版本中被删除，且不建议在新的部署中使用。
有关 Red Hat OpenShift Service on AWS 中已弃用或删除的主要功能的最新列表，请参阅 Red Hat OpenShift Service on AWS 发行注记中已弃用和删除的功能 部分。
4.7.3.1. 创建基于 SQLite 的索引镜像
您可以使用 opm CLI 根据 SQLite 数据库格式创建索引镜像。
前提条件
-
已安装
opmCLI。 -
您有
podman版本 1.9.3+。 - 已构建捆绑包镜像并推送到支持 Docker v2-2 的 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>/<index_image_name>:<tag>
$ podman push <registry>/<namespace>/<index_image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7.3.2. 更新基于 SQLite 的索引镜像
在将 OperatorHub 配置为使用引用自定义索引镜像的目录源后，集群管理员可通过将捆绑包镜像添加到索引镜像来保持其集群上的可用 Operator 最新状态。
您可以使用 opm index add 命令来更新存在的索引镜像。
前提条件
-
已安装
opmCLI。 -
您有
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。 <updated_tag>-
指定要应用到更新的索引镜像的镜像标签，如
4.1。
示例命令
opm index add \ --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \ --from-index mirror.example.com/abc/abc-redhat-operator-index:4 \ --tag mirror.example.com/abc/abc-redhat-operator-index:4.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 \ --tag mirror.example.com/abc/abc-redhat-operator-index:4.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.7.3.3. 过滤基于 SQLite 的索引镜像
基于 Operator Bundle Format 的索引镜像是 Operator 目录的容器化快照。您可以过滤或 prune（修剪）除指定的软件包列表以外的所有索引，创建只包含您想要的 Operator 的源索引副本。
前提条件
-
您有
podman版本 1.9.3+。 -
您有
grpcurl（第三方命令行工具）。 -
已安装
opmCLI。 - 您可以访问支持 Docker v2-2 的 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$ podman run -p50051:50051 \ -it registry.redhat.io/redhat/redhat-operator-index:v4Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4... 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... 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 \ -p advanced-cluster-management,jaeger-product,quay-operator \ [-i registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4] \ -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4$ opm index prune \ -f registry.redhat.io/redhat/redhat-operator-index:v4 \1 -p advanced-cluster-management,jaeger-product,quay-operator \2 [-i registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4] \3 -t <target_registry>:<port>/<namespace>/redhat-operator-index:v44 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令将新索引镜像推送到目标 registry:
podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4
$ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中
<namespace>是 registry 上的任何现有命名空间。
4.7.4. 目录源和 pod 安全准入
Red Hat OpenShift Service on AWS 4.11 中引入了 Pod 安全准入，以确保 pod 安全标准。使用基于 SQLite 的目录格式构建的目录源，并在 Red Hat OpenShift Service on AWS 4.11 无法在受限 pod 安全强制下运行 opm CLI 工具的版本。
在 Red Hat OpenShift Service on AWS 4 中，命名空间默认没有受限 pod 安全强制，默认的目录源安全模式设置为 legacy。
计划在以后的 Red Hat OpenShift Service on AWS 发行版本中包括所有命名空间的默认限制强制。当发生受限强制时，目录源 pod 规格的安全上下文必须与受限 pod 安全标准匹配。如果您的目录源镜像需要不同的 pod 安全标准，则必须明确设置命名空间的 pod 安全准入标签。
如果您不想以受限方式运行基于 SQLite 的目录源 pod，则不需要更新 Red Hat OpenShift Service on AWS 4 中的目录源。
但是，建议您采取措施来确保目录源在受限 pod 安全强制下运行。如果您不采取措施来确保目录源在受限 pod 安全强制下运行，您的目录源可能不会在以后的 Red Hat OpenShift Service on AWS 版本中运行。
作为目录作者，您可以通过完成以下任一操作来启用与受限 pod 安全强制的兼容性：
- 将您的目录迁移到基于文件的目录格式。
-
使用 Red Hat OpenShift Service on AWS 4.11 或更高版本的
opmCLI 工具版本更新您的目录镜像。
SQLite 数据库目录格式已弃用，但仍然被红帽支持。在以后的发行版本中，不支持 SQLite 数据库格式，目录将需要迁移到基于文件的目录格式。从 Red Hat OpenShift Service on AWS 4.11 开始，默认的红帽提供的 Operator 目录以基于文件的目录格式发布。基于文件的目录与受限 pod 安全强制兼容。
如果您不想更新 SQLite 数据库目录镜像，或将目录迁移到基于文件的目录格式，您可以将目录配置为使用升级的权限运行。
4.7.4.2. 重建 SQLite 数据库目录镜像
您可以使用您的 Red Hat OpenShift Service on AWS 版本发布的 opm CLI 工具的最新版本重建 SQLite 数据库目录镜像。
前提条件
- 您有一个 SQLite 数据库目录源。
-
您可以使用具有
cluster-admin角色的用户访问集群。 -
您有工作站上 Red Hat OpenShift Service on AWS 4 发布的
opmCLI 工具的最新版本。
流程
运行以下命令，使用
opmCLI 工具的最新版本重建目录：opm index add --binary-image \ registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4 \ --from-index <your_registry_image> \ --bundles "" -t \<your_registry_image>
$ opm index add --binary-image \ registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4 \ --from-index <your_registry_image> \ --bundles "" -t \<your_registry_image>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7.4.3. 配置目录以使用升级的权限运行
如果您不想更新 SQLite 数据库目录镜像，或将目录迁移到基于文件的目录格式，您可以执行以下操作以确保目录源在默认 pod 安全强制更改为受限时运行：
- 在目录源定义中手动将目录安全模式设置为 legacy。此操作可确保您的目录使用旧权限运行，即使默认目录安全模式更改为 restricted。
- 为基准或特权 pod 安全强制标记目录源命名空间。
SQLite 数据库目录格式已弃用，但仍然被红帽支持。在以后的发行版本中，不支持 SQLite 数据库格式，目录将需要迁移到基于文件的目录格式。基于文件的目录与受限 pod 安全强制兼容。
前提条件
- 您有一个 SQLite 数据库目录源。
-
您可以使用具有
cluster-admin角色的用户访问集群。 -
您有一个目标命名空间，它支持运行带有提升的 pod 安全准入标准
baseline或privileged的 pod。
流程
通过将
spec.grpcPodConfig.securityContextConfig标签设置为legacy来编辑CatalogSource定义，如下例所示：CatalogSource定义示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 提示在 Red Hat OpenShift Service on AWS 4 中，
spec.grpcPodConfig.securityContextConfig字段默认设置为legacy。在以后的 Red Hat OpenShift Service on AWS 发行版本中，计划默认设置将更改为restricted。如果您的目录无法在受限强制下运行，建议您手动将此字段设置为legacy。编辑
<namespace>.yaml文件，将升级的 pod 安全准入标准添加到目录源命名空间中，如下例所示：<namespace>.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7.5. 在集群中添加目录源
在 Red Hat OpenShift Service on AWS 集群中添加目录源可为用户发现和安装 Operator。集群管理员可以创建一个 CatalogSource 对象来引用索引镜像。OperatorHub 使用目录源来填充用户界面。
或者，您可以使用 Web 控制台管理目录源。在 Administration → Cluster Settings → Configuration → OperatorHub 页面中，点 Sources 选项卡，您可以在其中创建、更新、删除、禁用和启用单独的源。
前提条件
- 构建并推送索引镜像到 registry。
-
您可以使用具有
cluster-admin角色的用户访问集群。
流程
创建一个
CatalogSource对象来引用索引镜像。根据您的规格修改以下内容，并将它保存为
catalogSource.yaml文件：Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 如果您希望目录源对所有命名空间中的用户全局可用，请指定
openshift-marketplace命名空间。否则，您可以指定一个不同的命名空间来对目录进行作用域并只对该命名空间可用。 - 2
- 可选：将
olm.catalogImageTemplate注解设置为索引镜像名称，并使用一个或多个 Kubernetes 集群版本变量，如为镜像标签构建模板时所示。 - 3
- 指定
legacy或restricted的值。如果没有设置该字段，则默认值为legacy。在以后的 Red Hat OpenShift Service on AWS 发行版本中，计划默认值受到限制。如果您的目录无法使用restricted权限运行，建议您手动将此字段设置为legacy。 - 4
- 指定索引镜像。如果您在镜像名称后指定了标签，如
:v4，则目录源 Pod 会使用镜像 pull 策略Always，这意味着 pod 始终在启动容器前拉取镜像。如果您指定了摘要，如@sha256:<id>，则镜像拉取策略为IfNotPresent，这意味着仅在节点上不存在的镜像时才拉取镜像。 - 5
- 指定发布目录的名称或机构名称。
- 6
- 目录源可以自动检查新版本以保持最新。
使用该文件创建
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
现在，您可以在 Red Hat OpenShift Service on AWS Web 控制台中通过 OperatorHub 安装 Operator。
4.7.6. 删除自定义目录
作为具有 dedicated-admin 角色的管理员，您可以通过删除相关的目录源来删除之前添加到集群中的自定义 Operator 目录。
先决条件
-
您可以使用具有
dedicated-admin角色的用户访问集群。
流程
- 在 Web 控制台的 Administrator 视角中，进入到 Home → Search。
- 从 Project: 列表中选择一个项目。
- 从 Resources 列表中选择 CatalogSource。
-
选择您要删除的目录的 Options 菜单
，然后点 Delete CatalogSource。
4.8. 目录源 pod 调度
当源类型 grpc 的 Operator Lifecycle Manager (OLM) 目录源定义 spec.image 时，Catalog Operator 会创建一个提供定义的镜像内容的 pod。默认情况下，此 pod 在规格中定义以下内容：
-
只有
kubernetes.io/os=linux节点选择器。 -
默认优先级类名称：
system-cluster-critical。 - 没有容限。
作为管理员，您可以通过修改 CatalogSource 对象的可选 spec.grpcPodConfig 部分中的字段来覆盖这些值。
Marketplace Operator openshift-marketplace 负责管理默认的 OperatorHub 自定义资源 (CR)。此 CR 管理 CatalogSource 对象。如果您试图修改 CatalogSource 对象的 spec.grpcPodConfig 部分中的字段，则 Marketplace Operator 会自动恢复这些修改。默认情况下，如果您修改了 CatalogSource 对象的 spec.grpcPodConfig 部分中的字段，则 Marketplace Operator 会自动恢复这些更改。
要将持久性更改应用到 CatalogSource 对象，您必须首先禁用一个默认的 CatalogSource 对象。
4.8.1. 在本地级别禁用默认 CatalogSource 对象
您可以通过禁用默认的 CatalogSource 对象，对 CatalogSource 对象（如目录源 pod）应用到本地级别。当默认 CatalogSource 对象的配置不符合您的机构需求时，请考虑默认配置。默认情况下，如果您修改 CatalogSource 对象的 spec.grpcPodConfig 部分中的字段，Marketplace Operator 会自动恢复这些更改。
Marketplace Operator openshift-marketplace 负责管理 OperatorHub 的默认自定义资源 (CR)。OperatorHub 管理 CatalogSource 对象。
要将持久性更改应用到 CatalogSource 对象，您必须首先禁用一个默认的 CatalogSource 对象。
流程
要在本地级别禁用所有默认
CatalogSource对象，请输入以下命令：oc patch operatorhub cluster -p '{"spec": {"disableAllDefaultSources": true}}' --type=merge$ oc patch operatorhub cluster -p '{"spec": {"disableAllDefaultSources": true}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意您还可以将默认
OperatorHubCR 配置为禁用所有CatalogSource对象或禁用特定对象。
4.8.2. 覆盖目录源 pod 的节点选择器
先决条件
-
源类型的
CatalogSource对象，定义了spec.image
流程
编辑
CatalogSource对象并添加或修改spec.grpcPodConfig部分，使其包含以下内容：grpcPodConfig: nodeSelector: custom_label: <label>grpcPodConfig: nodeSelector: custom_label: <label>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中
<label>是您希望目录源 pod 用于调度的节点选择器的标签。
4.8.3. 覆盖目录源 pod 的优先级类名称
先决条件
-
源类型的
CatalogSource对象，定义了spec.image
流程
编辑
CatalogSource对象并添加或修改spec.grpcPodConfig部分，使其包含以下内容：grpcPodConfig: priorityClassName: <priority_class>grpcPodConfig: priorityClassName: <priority_class>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中
<priority_class>是以下之一：-
Kubernetes 提供的默认优先级类之一：
system-cluster-critical或system-node-critical -
用于分配默认优先级的空集合 (
"") - 预先存在的和自定义优先级类
-
Kubernetes 提供的默认优先级类之一：
在以前的版本中，唯一可以被覆盖的 pod 调度参数是 priorityClassName。这可以通过将 operatorframework.io/priorityclass 注解添加到 CatalogSource 对象来实现。例如：
如果 CatalogSource 对象同时定义了注解和 spec.grpcPodConfig.priorityClassName，注解优先于配置参数。
4.8.4. 覆盖目录源 pod 的容限
先决条件
-
源类型的
CatalogSource对象，定义了spec.image
流程
编辑
CatalogSource对象并添加或修改spec.grpcPodConfig部分，使其包含以下内容：Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.9. Troubleshooting Operator 的问题
如果遇到 Operator 问题，请验证 Operator 订阅状态。检查集群中的 Operator pod 健康状况，并收集 Operator 日志以进行诊断。
4.9.1. operator 订阅状况类型
订阅可报告以下状况类型：
| 状况 | 描述 |
|---|---|
|
| 用于解析的一个或多个目录源不健康。 |
|
| 缺少订阅的安装计划。 |
|
| 订阅的安装计划正在安装中。 |
|
| 订阅的安装计划失败。 |
|
| 订阅的依赖项解析失败。 |
默认 Red Hat OpenShift Service on AWS 集群 Operator 由 Cluster Version Operator (CVO)管理，它们没有 Subscription 对象。应用程序 Operator 由 Operator Lifecycle Manager（OLM）管理，它们具有 Subscription 对象。
4.9.2. 使用 CLI 查看 Operator 订阅状态
您可以使用 CLI 查看 Operator 订阅状态。
先决条件
-
您可以使用具有
dedicated-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
默认 Red Hat OpenShift Service on AWS 集群 Operator 由 Cluster Version Operator (CVO)管理，它们没有 Subscription 对象。应用程序 Operator 由 Operator Lifecycle Manager（OLM）管理，它们具有 Subscription 对象。
4.9.3. 使用 CLI 查看 Operator 目录源状态
您可以使用 CLI 查看 Operator 目录源的状态。
先决条件
-
您可以使用具有
dedicated-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 输出示例
NAME DISPLAY TYPE PUBLISHER AGE certified-operators Certified Operators grpc Red Hat 55m community-operators Community Operators grpc Red Hat 55m example-catalog Example Catalog grpc Example Org 2m25s redhat-operators Red Hat Operators grpc Red Hat 55m
NAME DISPLAY TYPE PUBLISHER AGE certified-operators Certified Operators grpc Red Hat 55m community-operators Community Operators grpc Red Hat 55m example-catalog Example Catalog grpc Example Org 2m25s redhat-operators Red Hat Operators grpc Red Hat 55mCopy 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.9.4. 查询 Operator pod 状态
您可以列出集群中的 Operator pod 及其状态。您还可以收集详细的 Operator pod 概述。
先决条件
-
您可以使用具有
dedicated-admin角色的用户访问集群。 - API 服务仍然可以正常工作。
-
已安装 OpenShift CLI(
oc)。
流程
列出集群中运行的 Operator。输出包括 Operator 版本、可用性和运行时间信息：
oc get clusteroperators
$ oc get clusteroperatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 列出在 Operator 命名空间中运行的 Operator pod，以及 pod 状态、重启和年龄：
oc get pod -n <operator_namespace>
$ oc get pod -n <operator_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出详细的 Operator pod 概述：
oc describe pod <operator_pod_name> -n <operator_namespace>
$ oc describe pod <operator_pod_name> -n <operator_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.9.5. 收集 Operator 日志
如果遇到 Operator 问题，您可以从 Operator pod 日志中收集详细诊断信息。
先决条件
-
您可以使用具有
dedicated-admin角色的用户访问集群。 - API 服务仍然可以正常工作。
-
已安装 OpenShift CLI(
oc)。 - 您有 control plane 或 control plane 机器的完全限定域名。
流程
列出在 Operator 命名空间中运行的 Operator pod，以及 pod 状态、重启和年龄：
oc get pods -n <operator_namespace>
$ oc get pods -n <operator_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 检查 Operator pod 的日志：
oc logs pod/<pod_name> -n <operator_namespace>
$ oc logs pod/<pod_name> -n <operator_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果 Operator pod 具有多个容器，则上述命令将会产生一个错误，其中包含每个容器的名称。从独立容器查询日志：
oc logs pod/<operator_pod_name> -c <container_name> -n <operator_namespace>
$ oc logs pod/<operator_pod_name> -c <container_name> -n <operator_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Legal Notice
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}