Desde el punto de vista del clúster Red Hat OpenShift, el recurso de nivel superior con el que comenzar es el proyecto. Un proyecto OpenShift puede verse como un recurso de clúster que divide todo el clúster OpenShift en múltiples clústeres virtuales. Por lo tanto, el aislamiento a nivel de proyecto proporciona una base para configurar la multitenencia.

El siguiente paso es configurar el RBAC en el clúster. La mejor práctica consiste en que todos los desarrolladores que trabajen en un mismo proyecto o carga de trabajo estén configurados en un único grupo de usuarios en el proveedor de identidad (IdP). Red Hat OpenShift permite la integración con el IdP y la sincronización de grupos de usuarios, lo que permite importar los usuarios y grupos del IdP al clúster. Esto ayuda a los administradores del clúster a segregar el acceso a los recursos del clúster dedicados a un proyecto para uno o varios grupos de usuarios que trabajen en ese proyecto, restringiendo así el acceso no autorizado a cualquier recurso del clúster. Para obtener más información sobre la integración del IdP con Red Hat OpenShift, consulta "Comprender los proveedores de identidad".

Es importante aislar el almacenamiento compartido que funciona como proveedor de almacenamiento persistente para un clúster de Red Hat OpenShift para asegurarse de que los volúmenes creados en el almacenamiento para cada proyecto aparezcan para los hosts como si se hubieran creado en un almacenamiento separado. Para ello, cree tantas SVM (máquinas virtuales de almacenamiento) en NetApp ONTAP como proyectos o cargas de trabajo y dedique cada SVM a una carga de trabajo.

Una vez que has creado diferentes SVM para distintos proyectos en NetApp ONTAP, debes asignar cada SVM a un backend de Trident diferente. La configuración del backend en Trident determina la asignación de almacenamiento persistente a los recursos del clúster de OpenShift y requiere los detalles de la SVM a la que se va a asignar. Como mínimo, este debe ser el controlador de protocolo para el backend. Opcionalmente, te permite definir cómo se aprovisionan los volúmenes en el almacenamiento y establecer límites para el tamaño de los volúmenes o el uso de agregados, entre otras cosas. Los detalles sobre la definición de los backends de Trident se pueden encontrar en "Configura backends".

Tras configurar los backends de Trident, el siguiente paso es configurar StorageClasses. Configura tantas clases de almacenamiento como backends haya, asegurándote de que cada clase de almacenamiento solo pueda crear volúmenes en un único backend. Podemos asignar la clase de almacenamiento StorageClass a un backend concreto de Trident utilizando el parámetro storagePools al definir la clase de almacenamiento. Los detalles para definir una clase de almacenamiento se pueden consultar en "Crear una clase de almacenamiento". De este modo, existe una correspondencia uno a uno entre StorageClass y el backend de Trident, que a su vez apunta a un único SVM. Esto garantiza que todas las solicitudes de almacenamiento a través de StorageClass asignadas a ese proyecto sean atendidas exclusivamente por el SVM dedicado a dicho proyecto.

Dado que las clases de almacenamiento no son recursos con espacio de nombres, ¿cómo nos aseguramos de que se rechacen las solicitudes de almacenamiento para una clase de almacenamiento de un proyecto por parte de pods en otro espacio de nombres o proyecto? La respuesta es usar ResourceQuotas. ResourceQuotas son objetos que controlan el uso total de recursos por proyecto. Puede limitar tanto el número como la cantidad total de recursos que pueden consumir los objetos en el proyecto. Casi todos los recursos de un proyecto pueden limitarse usando ResourceQuotas y usar esto de manera eficiente puede ayudar a las organizaciones a reducir costes y caídas por aprovisionamiento o consumo excesivo de recursos. Consulta "Establecer cuotas de recursos por proyecto" para más información.

Para este caso de uso, necesitamos limitar que los pods de un proyecto en particular reclamen almacenamiento de clases de almacenamiento que no están dedicadas a su proyecto. Para hacer eso, necesitamos limitar las reclamaciones de volumen persistente para otras clases de almacenamiento configurando <storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims a 0. Además, un administrador de clúster debe asegurarse de que los desarrolladores de un proyecto no tengan acceso para modificar las ResourceQuotas.