Der Netapp Architektur Sind
Änderungen vorschlagen
PDFs
Obwohl Red hat OpenShift und Trident, die von NetApp ONTAP unterstützt werden, standardmäßig keine Isolierung zwischen Workloads bieten, bieten sie eine breite Palette von Funktionen, die für die Konfiguration von Mandantenfähigkeit verwendet werden können. Um ein besseres Verständnis für das Design einer mandantenfähigen Lösung auf einem Red hat OpenShift-Cluster mit Trident, das von NetApp ONTAP unterstützt wird, zu erhalten, betrachten wir ein Beispiel mit einer Reihe von Anforderungen und skizzieren die entsprechende Konfiguration.
Nehmen wir einmal an, dass ein Unternehmen zwei seiner Workloads auf einem Red hat OpenShift-Cluster ausführt. Dies ist Teil von zwei Projekten, an denen zwei verschiedene Teams arbeiten. Die Daten für diese Workloads befinden sich in PVCs, die von Trident auf einem NetApp ONTAP NAS-Backend dynamisch bereitgestellt werden. Das Unternehmen muss für diese beiden Workloads eine mandantenfähige Lösung entwerfen und die Ressourcen für diese Projekte isolieren, um sicherzustellen, dass Sicherheit und Performance erhalten bleiben. Dabei geht es vor allem um die Daten, die die Applikationen unterstützen.
Die folgende Abbildung zeigt die mandantenfähige Lösung auf einem Red hat OpenShift-Cluster mit Trident, der von NetApp ONTAP unterstützt wird.
Technologieanforderungen erfüllt
-
NetApp ONTAP Storage-Cluster
-
Red hat OpenShift-Cluster
-
Trident
Red hat OpenShift – Clusterressourcen
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".
NetApp ONTAP
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.
Trident
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".
Red hat OpenShift – Speicherressourcen
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.