多租户集群中的 Operators - 了解 Operators | Operators | OpenShift Container Platform 4.17

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

Operator Lifecycle Manager (OLM) 的默认行为旨在简化 Operator 安装过程。但是，这种行为可能缺乏灵活性，尤其是在多租户集群中。为了让 OpenShift Container Platform 集群上的多个租户使用 Operator，OLM 的默认行为要求管理员以**所有命名空间**模式安装 Operator，这可能会被认为违反了最小权限原则。

请考虑以下场景，以确定哪种 Operator 安装工作流最适合您的环境和需求。

其他资源

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

当管理员使用 Web 控制台安装 Operator 时，通常根据 Operator 的功能，您有两个安装模式选择

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

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

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

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

其他资源

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

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

为租户 Operator 创建一个与租户命名空间分开的命名空间。
为租户 Operator 创建一个仅限于租户命名空间的操作符组。
在租户 Operator 命名空间中安装 Operator。

因此，Operator 驻留在租户 Operator 命名空间中并监视租户命名空间，但租户看不到或无法使用 Operator 的 Pod 或其服务帐户。

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

限制和注意事项

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

同一 Operator 的所有实例必须是同一版本。
Operator 不能依赖于其他 Operator。
Operator 不能提供 CRD 转换 Webhook。

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

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

作为管理员，请谨慎允许非集群管理员自行安装 Operator，如“允许非集群管理员安装 Operator”中所述。这些租户只能访问已知没有依赖关系的经过审核的操作符目录。还必须强制这些租户使用同一版本的 Operator，以确保 CRD 不发生更改。这需要使用命名空间范围的目录，并且可能需要禁用全局默认目录。

其他资源

操作符同域部署和操作符组

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

有关操作符同域部署和有效使用操作符组的更多信息，请参阅Operator Lifecycle Manager (OLM) → 多租户和操作符同域部署。