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 wird RBAC im Cluster konfiguriert. Die Best Practice besteht darin, alle Entwickler, die an einem einzelnen Projekt oder einer einzelnen Workload arbeiten, in einer einzigen Benutzergruppe im Identity Provider (IdP) zu konfigurieren. Red Hat OpenShift ermöglicht die IdP-Integration und die Synchronisierung von Benutzergruppen, sodass Benutzer und Gruppen aus dem IdP in den Cluster importiert werden können. Dies unterstützt die Clusteradministratoren dabei, den Zugriff auf die für ein Projekt vorgesehenen Clusterressourcen auf eine Benutzergruppe oder mehrere Benutzergruppen zu beschränken, die an diesem Projekt arbeiten, wodurch unbefugter Zugriff auf beliebige Clusterressourcen eingeschränkt wird. Weitere Informationen zur IdP-Integration mit Red Hat OpenShift sind unter "Identitätsanbieter" zu finden.

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 verschiedene SVMs für unterschiedliche Projekte auf NetApp ONTAP erstellt haben, muss jede SVM einem anderen Trident Backend zugeordnet werden. Die Backend-Konfiguration auf Trident steuert die Zuweisung von persistentem Speicher zu OpenShift Cluster-Ressourcen und erfordert die Details der SVM, der zugeordnet werden soll. Dies sollte mindestens der Protokolltreiber für das Backend sein. Optional besteht die Möglichkeit zu definieren, wie die Volumes auf dem Speicher bereitgestellt werden und Grenzwerte für die Größe der Volumes oder die Nutzung von Aggregaten usw. festzulegen. Details zur Definition der Trident Backends sind in "Backends konfigurieren" zu finden.

Nach der Konfiguration der Trident-Backends besteht der nächste Schritt darin, StorageClasses zu konfigurieren. Es sollten so viele Speicherklassen konfiguriert werden, wie Backends vorhanden sind, wobei jede Speicherklasse nur Zugriff auf das Erstellen von Volumes auf einem Backend erhält. Die Zuordnung der StorageClass zu einem bestimmten Trident-Backend erfolgt durch das Verwenden des storagePools-Parameters bei der Definition der Speicherklasse. Die Details zur Definition einer Speicherklasse sind in "Erstellen einer Speicherklasse" zu finden. Somit besteht eine Eins-zu-eins-Zuordnung von StorageClass zu Trident-Backend, das wiederum auf eine SVM verweist. Dadurch wird sichergestellt, dass alle Speicheranforderungen über die StorageClass, die diesem Projekt zugewiesen ist, ausschließlich von der ausschließlich diesem Projekt zugeordneten SVM bedient werden.

Da Speicherklassen keine namespaceten Ressourcen sind, wie wird sichergestellt, dass Speicheranforderungen von Pods in einem anderen Namespace oder Projekt an die Speicherklasse eines Projekts abgelehnt werden? Die Antwort ist die Verwendung von ResourceQuotas. ResourceQuotas sind Objekte, die die Gesamtnutzung von Ressourcen pro Projekt steuern. Damit kann sowohl die Anzahl als auch die Gesamtmenge der von Objekten im Projekt verbrauchten Ressourcen begrenzt werden. Nahezu alle Ressourcen eines Projekts können mit ResourceQuotas begrenzt werden, und eine effiziente Nutzung kann Unternehmen helfen, Kosten und Ausfälle durch Überprovisionierung oder übermäßigen Ressourcenverbrauch zu vermeiden. Weitere Informationen sind unter "Festlegung von Ressourcenquoten pro Projekt" zu finden.

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.