Desde el punto de vista del clúster de Red Hat OpenShift, el recurso de nivel superior con el que empezar es el proyecto. Un proyecto de OpenShift se puede ver como un recurso de clúster que divide todo el clúster de OpenShift en varios clústeres virtuales. Por lo tanto, el aislamiento a nivel de proyecto proporciona una base para configurar multi-tenancy.

El siguiente está para configurar RBAC en el clúster. La práctica recomendada es tener todos los desarrolladores trabajando en un único proyecto o carga de trabajo configurados en un único grupo de usuarios en el proveedor de identidades (IDP). Red Hat OpenShift permite la integración de IDP y la sincronización de grupos de usuarios, lo que permite importar al clúster los usuarios y grupos del IDP. Esto ayuda a los administradores del clúster a segregar el acceso de los recursos del clúster dedicados a un proyecto a un grupo de usuarios o grupos que trabajan en ese proyecto, restringiendo de este modo el acceso no autorizado a cualquier recurso del clúster. Para obtener más información sobre la integración de IDP con Red Hat OpenShift, consulte la documentación "aquí".

Es importante aislar el almacenamiento compartido que sirve como proveedor de almacenamiento persistente para un clúster de Red Hat OpenShift con el fin de garantizar que los volúmenes creados en el almacenamiento de cada proyecto aparecen en los hosts como si se crean en un almacenamiento separado. Para ello, cree tantos SVM (máquinas virtuales de almacenamiento) en ONTAP de NetApp como haya proyectos o cargas de trabajo, y dedique cada SVM a una carga de trabajo.

Después de haber establecido diferentes SVM para diferentes proyectos creados en ONTAP de NetApp, debe asignar cada SVM a un back-end de Trident diferente. La configuración de back-end en Trident impulsa la asignación de almacenamiento persistente a recursos de clúster de OpenShift y requiere los detalles de la SVM a la que se va a asignar. Este debe ser el controlador de protocolo para el back-end como mínimo. De manera opcional, le 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, etc. Se pueden encontrar detalles sobre la definición de los back-ends de Trident "aquí".

Después de configurar los back-ends de Trident, el siguiente paso es configurar StorageClasses. Configure tantas clases de almacenamiento como sean los back-ends, proporcionando acceso a cada clase de almacenamiento para activar volúmenes solo en un back-end. Podemos asignar este tipo de almacenamiento a un back-end de Trident concreto mediante el parámetro Storage Pools mientras se define la clase de almacenamiento. Se pueden encontrar los detalles para definir una clase de almacenamiento "aquí". Por ello, hay una asignación uno a uno desde el back-end de StorageClass a Trident que señala a una SVM. De este modo, se garantiza que todas las solicitudes de almacenamiento que realiza el clases de almacenamiento asignadas a ese proyecto sean atendidas por la SVM dedicada exclusivamente a dicho proyecto.

Debido a que los tipos de almacenamiento no son recursos namesped, ¿cómo podemos garantizar que las afirmaciones sobre el almacenamiento a la clase de almacenamiento de un proyecto por POD en otro espacio de nombres o proyecto sean rechazadas? La respuesta es utilizar ResourceQuotas. ResourceQuotas son objetos que controlan el uso total de recursos por proyecto. Puede limitar el número así como la cantidad total de recursos que pueden consumir los objetos del proyecto. Casi todos los recursos de un proyecto pueden limitarse utilizando ResourceQuotas y el uso eficaz de este recurso puede ayudar a las organizaciones a reducir los costes y las interrupciones debido al sobreaprovisionamiento o al sobreconsumo de recursos. Consulte la documentación "aquí" si quiere más información.

Para este caso de uso, es necesario limitar los pods de un proyecto en concreto de solicitar almacenamiento a clases de almacenamiento que no estén dedicadas a su proyecto. Para ello, hemos de limitar las reclamaciones por volumen persistente para otros tipos de almacenamiento al establecer <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 ResourceQuotas.