Aus Sicht des Red Hat OpenShift-Clusters ist das Projekt die Ressource der obersten Ebene, mit der man beginnen sollte. Ein OpenShift-Projekt kann als Clusterressource betrachtet werden, die den gesamten OpenShift-Cluster in mehrere virtuelle Cluster aufteilt. Daher bietet die Isolation auf Projektebene eine Grundlage für die Konfiguration der Mandantenfähigkeit.

Als Nächstes muss RBAC im Cluster konfiguriert werden. Die beste Vorgehensweise besteht darin, alle Entwickler, die an einem einzelnen Projekt oder einer einzelnen Arbeitslast arbeiten, in einer einzelnen Benutzergruppe im Identitätsanbieter (IdP) zu konfigurieren. Red Hat OpenShift ermöglicht die IdP-Integration und Benutzergruppensynchronisierung, sodass die Benutzer und Gruppen vom IdP in den Cluster importiert werden können. Dies hilft den Cluster-Administratoren, den Zugriff auf die einem Projekt zugewiesenen Cluster-Ressourcen auf eine oder mehrere Benutzergruppen zu beschränken, die an diesem Projekt arbeiten, und so den unbefugten Zugriff auf Cluster-Ressourcen zu unterbinden. Weitere Informationen zur IdP-Integration mit Red Hat OpenShift finden Sie in der Dokumentation "hier," .

Es ist wichtig, den gemeinsam genutzten Speicher zu isolieren, der als persistenter Speicheranbieter für einen Red Hat OpenShift-Cluster dient, um sicherzustellen, dass die auf dem Speicher für jedes Projekt erstellten Volumes den Hosts so erscheinen, als wären sie auf einem separaten Speicher erstellt worden. Erstellen Sie dazu auf NetApp ONTAP so viele SVMs (Storage Virtual Machines), wie Projekte oder Workloads vorhanden sind, und weisen Sie jede SVM einem Workload zu.

Nachdem Sie unterschiedliche SVMs für unterschiedliche Projekte auf NetApp ONTAP erstellt haben, müssen Sie jedes SVM einem anderen Trident Backend zuordnen. Die Backend-Konfiguration auf Trident steuert die Zuweisung von persistentem Speicher zu OpenShift-Clusterressourcen und erfordert die Details der SVM, der eine Zuordnung erfolgen soll. Dies sollte mindestens der Protokolltreiber für das Backend sein. Optional können Sie definieren, wie die Volumes auf dem Speicher bereitgestellt werden, und Grenzwerte für die Größe der Volumes oder die Verwendung von Aggregaten usw. festlegen. Details zur Definition der Trident -Backends finden Sie "hier," .

Nach der Konfiguration der Trident -Backends besteht der nächste Schritt darin, StorageClasses zu konfigurieren. Konfigurieren Sie so viele Speicherklassen wie Backends vorhanden sind und gewähren Sie jeder Speicherklasse Zugriff auf das Hochfahren von Volumes nur auf einem Backend. Wir können die StorageClass einem bestimmten Trident Backend zuordnen, indem wir beim Definieren der Speicherklasse den Parameter storagePools verwenden. Die Details zur Definition einer Speicherklasse finden Sie "hier," . Daher gibt es eine Eins-zu-eins-Zuordnung von StorageClass zum Trident Backend, die auf eine SVM zurückverweist. Dadurch wird sichergestellt, dass alle Speicheransprüche über die diesem Projekt zugewiesene StorageClass nur von der SVM bedient werden, die diesem Projekt gewidmet ist.

Da Speicherklassen keine Namespace-Ressourcen sind, wie stellen wir sicher, dass Speicheransprüche auf die Speicherklasse eines Projekts durch Pods in einem anderen Namespace oder Projekt abgelehnt werden? Die Antwort ist die Verwendung von ResourceQuotas. ResourceQuotas sind Objekte, die die Gesamtnutzung von Ressourcen pro Projekt steuern. Es kann sowohl die Anzahl als auch die Gesamtmenge der Ressourcen begrenzen, die von Objekten im Projekt verbraucht werden können. Fast alle Ressourcen eines Projekts können mithilfe von ResourceQuotas begrenzt werden. Durch die effiziente Nutzung dieser Ressourcen können Unternehmen Kosten senken und Ausfälle aufgrund von Überbereitstellung oder übermäßigem Ressourcenverbrauch vermeiden. Weitere Informationen finden Sie in der Dokumentation "hier," für weitere Informationen.

Für diesen Anwendungsfall müssen wir die Pods in einem bestimmten Projekt daran hindern, Speicher von Speicherklassen zu beanspruchen, die nicht für ihr Projekt bestimmt sind. Dazu müssen wir die persistenten Volume-Ansprüche für andere Speicherklassen begrenzen, indem wir <storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims auf 0. Darüber hinaus muss ein Clusteradministrator sicherstellen, dass die Entwickler in einem Projekt keinen Zugriff auf die Änderung der ResourceQuotas haben.