架构
虽然Red Hat OpenShift和NetApp ONTAP支持的Trident在默认情况下无法在工作负载之间进行隔离、但它们提供了多种功能、可用于配置多租户。为了更好地了解如何在采用Trident并由NetApp ONTAP提供支持的Red Hat OpenShift集群上设计多租户解决方案、我们来考虑一个具有一系列要求的示例、并概括介绍相关配置。
假设一个组织在一个 Red Hat OpenShift 集群上运行两个工作负载,作为两个不同团队正在处理的两个项目的一部分。这些工作负载的数据驻留在NetApp ONTAP NAS后端由Trident动态配置的PVC上。该组织需要为这两个工作负载设计多租户解决方案,并隔离用于这些项目的资源,以确保保持安全性和性能,主要侧重于为这些应用程序提供服务的数据。
下图展示了Red Hat OpenShift集群上的多租户解决方案、该集群使用NetApp ONTAP作为后盾的Trident。
技术要求
-
NetApp ONTAP 存储集群
-
Red Hat OpenShift 集群
-
Trident
Red Hat OpenShift —集群资源
从 Red Hat OpenShift 集群的角度来看,要开始使用的顶级资源是项目。OpenShift 项目可以视为将整个 OpenShift 集群划分为多个虚拟集群的集群资源。因此,项目级别的隔离为配置多租户提供了基础。
下一步是在集群中配置 RBAC 。最佳做法是,将处理单个项目或工作负载的所有开发人员配置到身份提供程序( IdP )中的单个用户组中。Red Hat OpenShift 允许 IdP 集成和用户组同步,从而允许将 IdP 中的用户和组导入到集群中。这样可以帮助集群管理员将项目专用集群资源的访问权限隔离给一个或多个处理该项目的用户组,从而限制对任何集群资源的未授权访问。要了解有关 IdP 与 Red Hat OpenShift 集成的详细信息,请参见相关文档 "此处"。
NetApp ONTAP
必须隔离用作 Red Hat OpenShift 集群永久性存储提供程序的共享存储,以确保在存储上为每个项目创建的卷在主机上显示为它们,就像在单独的存储上创建一样。为此,请在 NetApp ONTAP 上创建与项目或工作负载数量相同的 SVM ( Storage Virtual Machine ),并将每个 SVM 专用于一个工作负载。
Trident
在 NetApp ONTAP 上为不同项目创建不同的 SVM 之后,必须将每个 SVM 映射到不同的 Trident 后端。Trident 上的后端配置会将永久性存储分配给 OpenShift 集群资源,并且需要将 SVM 的详细信息映射到。此驱动程序至少应为后端的协议驱动程序。或者,您也可以通过它定义如何在存储上配置卷,并设置卷大小或聚合使用量等限制。有关 Trident 后端定义的详细信息,请参见 "此处"。
Red Hat OpenShift —存储资源
配置 Trident 后端后,下一步是配置 StorageClasses 。配置与后端相同数量的存储类,为每个存储类提供访问权限,以便仅在一个后端启动卷。在定义存储类时,我们可以使用 storagePools 参数将 StorageClass 映射到特定的 Trident 后端。可以找到用于定义存储类的详细信息 "此处"。因此,从 StorageClass 到 Trident 后端存在一对一映射,这种映射可指向一个 SVM 。这样可以确保通过分配给该项目的 StorageClass 处理的所有存储请求仅由专用于该项目的 SVM 处理。
由于存储类不是命名空间资源,我们如何确保拒绝另一命名空间或项目中的 Pod 向一个项目的存储类声明?问题解答将使用 ResourceQuotas 。ResourceQuotas 是控制每个项目资源总使用量的对象。它可以限制项目中的对象可以使用的资源数量以及总资源量。使用 ResourceQuotas 几乎可以限制项目中的所有资源,而高效地使用此功能可以帮助组织降低因过度配置或过度消耗资源而导致的成本和中断。请参见文档 "此处" 有关详细信息 …
对于这种使用情形,我们需要限制特定项目中的 Pod 从非专用于其项目的存储类中申请存储。为此,我们需要通过将 ` <storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` 设置为 0 来限制其他存储类的永久性卷请求。此外,集群管理员必须确保项目中的开发人员不应有权修改 ResourceQuotas 。