多租户集群中的 Operators - 理解 Operators | Operators | OpenShift Dedicated

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

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

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

其他资源

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

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

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

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

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

对于单命名空间模式，由于 Operator 本身安装在选定的命名空间中，其 Pod 和 Service Account 也位于该命名空间。对于所有命名空间模式，Operator 的权限将自动提升到集群角色，这意味着 Operator 在所有命名空间中都具有这些权限。

其他资源

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

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

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

因此，Operator 驻留在租户 Operator 命名空间中并监控租户命名空间，但租户无法查看或使用 Operator 的 Pod 或其 Service Account。

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

限制和注意事项

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

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

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

该实例不是 Operator 的最新版本。
该实例包含旧版本的 CRD，这些 CRD 缺少信息或版本，而这些信息或版本在新版本中已经存在并且正在集群中使用。

其他资源

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

Operator 同处和 Operator 组

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

有关 Operator 同处和有效使用 Operator 组的更多信息，请参阅 Operator Lifecycle Manager (OLM) → 多租户和 Operator 同处。