Aus der Clusteransicht des Red hat OpenShift ist das Projekt die Ressource auf oberster Ebene. Ein OpenShift-Projekt kann als Clusterressource betrachtet werden, die das gesamte OpenShift-Cluster in mehrere virtuelle Cluster unterteilt. Daher bildet die Isolierung auf Projektebene eine Grundlage für die Konfiguration der Mandantenfähigkeit.

Anschließend können Sie die RBAC im Cluster konfigurieren. Es empfiehlt sich, dass alle Entwickler an einem einzelnen Projekt oder Workload in einer einzelnen Benutzergruppe im Identitätsanbieter (IdP) konfiguriert werden. Red hat OpenShift ermöglicht die IdP-Integration und die Synchronisierung von Benutzergruppen. So können Benutzer und Gruppen aus dem IdP in das Cluster importiert werden. So können Cluster-Administratoren den Zugriff auf die für ein Projekt dedizierten Cluster-Ressourcen für eine Benutzergruppe oder -Gruppe, die an diesem Projekt arbeitet, trennen und dadurch unberechtigten Zugriff auf Cluster-Ressourcen einschränken. 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. Dadurch muss sichergestellt werden, dass die auf dem Speicher für jedes Projekt erstellten Volumes den Hosts so angezeigt werden, als ob sie in einem separaten Speicher erstellt werden. Erstellen Sie dazu auf NetApp ONTAP so viele SVMs (Storage Virtual Machines), wie es Projekte oder Workloads gibt, und weisen Sie jede SVM einem Workload zu.

Nachdem Sie für verschiedene Projekte, die auf NetApp ONTAP erstellt wurden, unterschiedliche SVMs vorhanden sind, müssen Sie jede SVM einem anderen Trident-Back-End zuordnen. Die Back-End-Konfiguration auf Trident treibt die Zuweisung von persistentem Storage zu OpenShift-Cluster-Ressourcen an. Außerdem sind Details der SVM zu zugeordnet. Dies sollte mindestens der Protokolltreiber für das Backend sein. Optional können Sie damit definieren, wie die Volumes im Storage bereitgestellt werden, und Grenzen für die Größe von Volumes oder die Nutzung von Aggregaten festlegen. Details zur Definition der Trident Back-Ends finden sich "Hier".

Nach der Konfiguration der Trident Back-Ends wird als nächster Schritt die Konfiguration von StorageClasses durchgeführt. Konfigurieren Sie so viele Storage-Klassen wie Back-Ends, wobei jede Storage-Klasse Zugriff erlaubt, Volumes nur an einem Back-End zu erweitern. Wir können die StorageClass einem bestimmten Trident Back-End zuordnen, indem wir während der Definition der Storage-Klasse den StoragePools Parameter verwenden. Die Details zur Definition einer Storage-Klasse sind verfügbar "Hier". Somit gibt es eine 1:1-Zuordnung von StorageClass zu Trident Back-End, die auf eine SVM verweist. So wird sichergestellt, dass alle Storage-Anforderungen über die StorageClass, die diesem Projekt zugewiesen ist, von der für dieses Projekt dedizierten SVM bedient werden.

Da Storage-Klassen keine Ressourcen mit Namespaces sind, wie stellen wir sicher, dass Storage-Forderungen für eine Storage-Klasse eines Projekts durch Pods in einem anderen Namespace oder Projekt abgelehnt werden? Die Antwort ist die Verwendung von ResourceQuotas. ResourceQuotas sind Objekte, die die Gesamtauslastung von Ressourcen pro Projekt steuern. Sie kann die Anzahl und die Gesamtanzahl der Ressourcen begrenzen, die von Objekten im Projekt verbraucht werden können. Mithilfe von ResourceQuotas lassen sich nahezu alle Ressourcen eines Projekts beschränken. Mit dieser effizienten Nutzung können Unternehmen Kosten und Ausfälle aufgrund von überdimensionierten Ressourcen oder überhöhten Ressourcen senken. Siehe Dokumentation "Hier" Finden Sie weitere Informationen.

Bei diesem Anwendungsfall müssen wir die Pods in einem bestimmten Projekt beschränken, wenn wir Storage aus Storage-Klassen beanspruchen, die nicht für ihr Projekt reserviert sind. Um dies zu erreichen, müssen wir die Anforderungen für persistente Volumes für andere Speicherklassen durch Festlegung begrenzen <storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims Bis 0. Darüber hinaus muss ein Clusteradministrator sicherstellen, dass die Entwickler in einem Projekt keinen Zugriff haben, um die ResourceQuotas zu ändern.