2.7. 多租户集群中的 Operator
Operator Lifecycle Manager (OLM) 的默认行为旨在简化 Operator 的安装过程。但是，此行为可能会缺少灵活性，特别是在多租户集群中。为了让 OpenShift Container Platform 集群上的多个租户使用 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。
