Du point de vue du cluster Red Hat OpenShift, la ressource de niveau supérieur par laquelle commencer est le projet. Un projet OpenShift peut être considéré comme une ressource de cluster qui divise l’ensemble du cluster OpenShift en plusieurs clusters virtuels. Par conséquent, l’isolement au niveau du projet fournit une base pour la configuration de la multilocation.

L'étape suivante consiste à configurer le RBAC dans le cluster. La bonne pratique consiste à regrouper tous les développeurs travaillant sur un même projet ou une même charge de travail au sein d'un seul groupe d'utilisateurs dans le fournisseur d'identité (IdP). Red Hat OpenShift permet l'intégration de l'IdP et la synchronisation des groupes d'utilisateurs, ce qui permet d'importer les utilisateurs et groupes de l'IdP dans le cluster. Cela aide les administrateurs du cluster à segmenter l'accès aux ressources du cluster dédiées à un projet pour un ou plusieurs groupes d'utilisateurs travaillant sur ce projet, restreignant ainsi tout accès non autorisé à des ressources du cluster. Pour en savoir plus sur l'intégration de l'IdP avec Red Hat OpenShift, consultez "Comprendre les fournisseurs d'identité".

Il est important d'isoler le stockage partagé servant de fournisseur de stockage persistant pour un cluster Red Hat OpenShift afin de garantir que les volumes créés sur le stockage pour chaque projet apparaissent aux hôtes comme s'ils étaient créés sur un stockage séparé. Pour ce faire, créez autant de SVM (machines virtuelles de stockage) sur NetApp ONTAP qu'il y a de projets ou de charges de travail, et dédiez chaque SVM à une charge de travail.

Après avoir créé différentes SVM pour différents projets sur NetApp ONTAP, vous devez associer chaque SVM à un backend Trident différent. La configuration du backend sur Trident détermine l’allocation du stockage persistant aux ressources du cluster OpenShift, et elle requiert les informations de la SVM à associer. Il doit s’agir au minimum du pilote de protocole pour le backend. En option, cela vous permet de définir la manière dont les volumes sont provisionnés sur le stockage et de fixer des limites concernant la taille des volumes ou l’utilisation des agrégats, etc. Des informations détaillées concernant la définition des backends Trident peuvent être trouvées dans "Configurer les backends".

Après avoir configuré les backends Trident, l’étape suivante consiste à configurer les StorageClasses. Configurez autant de classes de stockage qu’il y a de backends, en veillant à ce que chaque classe de stockage permette de créer des volumes uniquement sur un seul backend. Nous pouvons associer la StorageClass à un backend Trident particulier en utilisant le paramètre storagePools lors de la définition de la classe de stockage. Les détails pour définir une classe de stockage se trouvent dans "Créer une classe de stockage". Ainsi, il existe une correspondance un-à-un entre la StorageClass et le backend Trident, qui pointe vers une seule SVM. Cela garantit que toutes les demandes de stockage via la StorageClass attribuée à ce projet sont servies uniquement par la SVM dédiée à ce projet.

Les classes de stockage n'étant pas des ressources d'espace de noms, comment garantir que les demandes de stockage adressées à une classe de stockage d'un projet par des pods d'un autre espace de noms ou projet soient rejetées ? La solution consiste à utiliser ResourceQuotas. ResourceQuotas sont des objets qui contrôlent l'utilisation totale des ressources par projet. Ils permettent de limiter le nombre ainsi que la quantité totale de ressources pouvant être consommées par les objets du projet. Presque toutes les ressources d'un projet peuvent être limitées grâce à ResourceQuotas et une utilisation efficace de ces objets permet aux organisations de réduire les coûts et les interruptions de service dues au surprovisionnement ou à la surconsommation de ressources. Consultez "Définition de quotas de ressources par projet" pour plus d'informations.

Pour ce cas d'utilisation, nous devons empêcher les pods d'un projet particulier de réclamer du stockage à partir de classes de stockage qui ne sont pas dédiées à leur projet. Pour ce faire, nous devons limiter les revendications de volume persistant pour d’autres classes de stockage en définissant <storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims à 0. De plus, un administrateur de cluster doit s’assurer que les développeurs d’un projet ne doivent pas avoir accès à la modification des ResourceQuotas.