多租户集群中的 Operators - 理解 Operators | Operators | Red Hat OpenShift Service on AWS

默认操作符安装模式和行为
多租户集群的推荐解决方案
操作符同址和操作符组

操作符生命周期管理器 (OLM) 的默认行为旨在简化操作符安装。但是，这种行为可能缺乏灵活性，尤其是在多租户集群中。为了让 AWS 集群上的 Red Hat OpenShift 服务上的多个租户使用操作符，OLM 的默认行为要求管理员以**所有命名空间**模式安装操作符，这可以被认为违反了最小权限原则。

考虑以下场景以确定哪个操作符安装工作流最适合您的环境和需求。

其他资源

编辑

默认操作符安装模式和行为

作为管理员使用 Web 控制台安装操作符时，根据操作符的功能，您通常有两种安装模式选择

单个命名空间: 将操作符安装在选择的单个命名空间中，并在该命名空间中提供操作符请求的所有权限。
所有命名空间: 将操作符安装在默认的 `openshift-operators` 命名空间中，以监视并使其可用于集群中的所有命名空间。在所有命名空间中提供操作符请求的所有权限。在某些情况下，操作符作者可以定义元数据，为用户提供操作符建议命名空间的第二个选项。

此选择还意味着受影响命名空间中的用户可以访问操作符 API，这可以利用他们拥有的自定义资源 (CR)，具体取决于他们在命名空间中的角色。

`namespace-admin` 和 `namespace-edit` 角色可以读写操作符 API，这意味着他们可以使用它们。
`namespace-view` 角色可以读取该操作符的 CR 对象。

对于**单个命名空间**模式，由于操作符本身安装在选择的命名空间中，因此它的 Pod 和服务帐户也位于那里。对于**所有命名空间**模式，操作符的所有权限都会自动提升为集群角色，这意味着操作符在所有命名空间中都拥有这些权限。

其他资源

编辑

多租户集群的推荐解决方案

虽然存在**多命名空间**安装模式，但它仅受少数操作符支持。作为标准**所有命名空间**和**单个命名空间**安装模式之间的折中解决方案，您可以使用以下工作流安装同一操作符的多个实例，每个租户一个。

为租户操作符创建一个与租户命名空间分开的命名空间。您可以通过创建一个项目来完成此操作。
为租户操作符创建一个操作符组，该组仅限于租户的命名空间。
将操作符安装在租户操作符命名空间中。

因此，操作符驻留在租户操作符命名空间中并监视租户命名空间，但租户既看不到操作符的 Pod 也无法使用它。

此解决方案以资源使用和确保约束得到满足的额外编排为代价，提供了更好的租户隔离和最小权限原则。有关详细步骤，请参阅“为多租户集群准备操作符的多个实例”。

限制和注意事项

此方案仅在满足以下约束条件时有效

所有相同 Operator 的实例必须是同一版本。
Operator 无法依赖其他 Operator。
Operator 无法交付 CRD 转换 webhook。

您不能在同一集群上使用相同 Operator 的不同版本。最终，当满足以下条件时，另一个 Operator 实例的安装将被阻止

该实例不是 Operator 的最新版本。
该实例交付了较旧版本的 CRD，这些 CRD 缺少信息或版本，而较新版本已经在集群中使用。

其他资源

为多租户集群准备多个 Operator 实例

编辑

Operator 同处和 Operator 组

Operator 生命周期管理器 (OLM) 处理安装在同一命名空间中的 OLM 托管 Operator，这意味着它们的 Subscription 资源与相关 Operator 同处在同一命名空间中。即使它们实际上并不相关，OLM 也会在其中任何一个更新时考虑它们的状态，例如它们的版本和更新策略。

有关 Operator 同处和有效使用 Operator 组的更多信息，请参阅 Operator 生命周期管理器 (OLM) → 多租户和 Operator 同处。