Dal punto di vista del cluster Red Hat OpenShift, la risorsa di primo livello da cui partire è il progetto. Un progetto OpenShift può essere visto come una risorsa cluster che divide l'intero cluster OpenShift in più cluster virtuali. Pertanto, l'isolamento a livello di progetto fornisce una base per la configurazione del multi-tenancy.

Il passo successivo consiste nel configurare RBAC nel cluster. La best practice prevede che tutti gli sviluppatori che lavorano su un singolo progetto o carico di lavoro siano configurati in un unico gruppo di utenti nell'Identity Provider (IdP). Red Hat OpenShift consente l'integrazione con l'IdP e la sincronizzazione dei gruppi di utenti, permettendo così di importare utenti e gruppi dall'IdP nel cluster. Questo aiuta gli amministratori del cluster a separare l'accesso alle risorse del cluster dedicate a un progetto per uno o più gruppi di utenti che lavorano su quel progetto, limitando così l'accesso non autorizzato a qualsiasi risorsa del cluster. Per saperne di più sull'integrazione dell'IdP con Red Hat OpenShift, vedi "Capire i provider di identità".

È importante isolare lo storage condiviso che funge da provider di storage persistente per un cluster Red Hat OpenShift per garantire che i volumi creati sullo storage per ciascun progetto appaiano agli host come se fossero stati creati su uno storage separato. Per fare ciò, crea tante SVM (macchine virtuali di storage) su NetApp ONTAP quanti sono i progetti o i carichi di lavoro e dedica ogni SVM a un carico di lavoro.

Dopo aver creato diverse SVM per diversi progetti su NetApp ONTAP, devi mappare ciascuna SVM a un backend Trident differente. La configurazione del backend su Trident gestisce l'allocazione dello storage persistente alle risorse del cluster OpenShift e richiede i dettagli della SVM da mappare. Come minimo, questo dovrebbe essere il driver di protocollo per il backend. Facoltativamente, ti permette di definire come vengono forniti i volumi sullo storage e di impostare limiti per le dimensioni dei volumi o l'utilizzo degli aggregati e così via. I dettagli relativi alla definizione dei backend Trident sono disponibili in "Configura i backend".

Dopo aver configurato i backend Trident, il passaggio successivo è configurare le StorageClasses. Configura tante classi di storage quanti sono i backend, consentendo a ciascuna classe di storage di avviare volumi solo su un backend. Puoi mappare la StorageClass a uno specifico backend Trident usando il parametro storagePools durante la definizione della classe di storage. I dettagli per definire una classe di storage si trovano in "Creare una classe di archiviazione". Quindi, esiste una mappatura uno a uno da StorageClass a backend Trident che punta a un SVM. Questo garantisce che tutte le richieste di storage tramite la StorageClass assegnata a quel progetto vengano gestite solo dall'SVM dedicato a quel progetto.

Poiché le classi di storage non sono risorse con namespace, come puoi garantire che le richieste di storage alla classe di storage di un progetto da parte di pod in un altro namespace o progetto vengano rifiutate? La risposta è usare ResourceQuotas. ResourceQuotas sono oggetti che controllano l'utilizzo totale delle risorse per progetto. Possono limitare sia il numero sia la quantità totale di risorse che possono essere consumate dagli oggetti nel progetto. Quasi tutte le risorse di un progetto possono essere limitate usando ResourceQuotas e un uso efficiente di questi può aiutare le organizzazioni a ridurre i costi e le interruzioni dovute a sovra-allocazione o sovra-consumo di risorse. Consulta "Impostazione delle quote di risorse per progetto" per ulteriori informazioni.

Per questo caso d'uso, dobbiamo impedire ai pod di un particolare progetto di richiedere spazio di archiviazione da classi di archiviazione non dedicate al loro progetto. Per fare ciò, dobbiamo limitare le richieste di volume persistente per altre classi di archiviazione impostando <storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims a 0. Inoltre, un amministratore di cluster deve garantire che gli sviluppatori di un progetto non abbiano accesso per modificare ResourceQuotas.