In diesem Dokument werden Best Practices für das Entwerfen der Hierarchie und Trennung von Arbeitslasten in Google Distributed Cloud (GDC) Air-Gapped mithilfe von Organisationen, Projekten und Kubernetes-Clustern vorgestellt. Diese Anleitung berücksichtigt die effiziente Ressourcennutzung, die Isolation von Arbeitslasten und die einfache Bedienung.
Organisationen für die physische und logische Isolation zwischen Kunden entwerfen
Die Organization-Ressource ist der Stamm für alle Ressourcen, die einem einzelnen Kunden gehören. Die detaillierte Zugriffssteuerung zwischen Arbeitslasten innerhalb einer Organisation kann über Rollenbindungen und Netzwerkrichtlinien definiert werden. Weitere Informationen finden Sie unter Identitäts- und Zugriffsverwaltung.
Jede Organisation in einer GDC-Zone bietet physische Isolation für die Compute-Infrastruktur und logische Isolation für Netzwerk-, Speicher- und andere Dienste. Nutzer in einer Organisation haben keinen Zugriff auf Ressourcen in einer anderen Organisation, sofern ihnen nicht ausdrücklich Zugriff gewährt wurde. Die Netzwerkverbindung von einer Organisation zu einer anderen ist standardmäßig nicht zulässig, sofern nicht explizit konfiguriert ist, dass Daten von einer Organisation übertragen und in eine andere übertragen werden dürfen.
Umfang der Arbeitslasten definieren, die eine Organisation gemeinsam nutzen können
Der Umfang einer Organisation in Ihrem Unternehmenskontext kann je nach Definition der Vertrauensgrenzen durch Ihr Unternehmen variieren. Einige Unternehmen erstellen möglicherweise mehrere Organisationsressourcen für verschiedene Einheiten im Unternehmen. Beispielsweise kann jede Unternehmensabteilung ein unabhängiger GDC-Kunde mit einer unabhängigen Organisation sein, wenn die Abteilungen eine vollständige physische und administrative Trennung ihrer Arbeitslasten erfordern.
Im Allgemeinen empfehlen wir, mehrere Arbeitslasten anhand der folgenden Signale in einer einzelnen Organisation zu gruppieren:
- Arbeitslasten können Abhängigkeiten gemeinsam nutzen. Das kann beispielsweise eine gemeinsame Datenquelle, die Konnektivität zwischen Arbeitslasten oder ein gemeinsames Monitoring-Tool sein.
- Arbeitslasten können eine administrative Root of Trust gemeinsam nutzen. Derselbe Administrator kann mit privilegiertem Zugriff auf alle Arbeitslasten in der Organisation betraut werden.
- Arbeitslasten dürfen die zugrunde liegende physische Infrastruktur mit anderen Arbeitslasten in derselben Organisation gemeinsam nutzen, sofern eine ausreichende logische Trennung vorhanden ist.
- Derselbe Budgetinhaber ist für die Arbeitslastbudgets insgesamt verantwortlich. Details zum Aufrufen der Gesamtkosten für die Organisation oder zur detaillierten Analyse nach Arbeitslast finden Sie auf der Seite Abrechnung.
- Die Anforderungen an die Verfügbarkeit von Arbeitslasten müssen Ihren Anforderungen an die Hochverfügbarkeit für die Distanz zwischen mehreren Zonen entsprechen.
Projekte für die logische Isolation zwischen Arbeitslasten entwerfen
Innerhalb einer Organisation empfehlen wir, mehrere Projekte bereitzustellen, um eine logische Trennung zwischen Ressourcen zu schaffen. Projekte in derselben Organisation können sich die zugrunde liegende physische Infrastruktur teilen. Projekte werden jedoch verwendet, um Arbeitslasten mit einer logischen Grenze basierend auf IAM-Richtlinien (Identity and Access Management) und Netzwerkrichtlinien zu trennen.
Berücksichtigen Sie beim Festlegen von Projektgrenzen die größte Menge an Funktionen, die von Ressourcen gemeinsam genutzt werden können, z. B. Rollenbindungen, Netzwerkrichtlinien oder Anforderungen an die Beobachtbarkeit. Gruppieren Sie die Ressourcen, die diese Funktion gemeinsam nutzen können, in einem Projekt und verschieben Sie Ressourcen, die diese Funktion nicht gemeinsam nutzen können, in ein anderes Projekt.
In Kubernetes-Begriffen ist ein Projekt ein Kubernetes-Namespace, der für alle Cluster in einer Organisation reserviert ist. Auch wenn ein Namespace in mehreren Clustern reserviert ist, bedeutet das nicht, dass ein Pod automatisch in allen Clustern geplant wird. Ein Pod, der für einen bestimmten Cluster geplant ist, bleibt für diesen Cluster geplant.
Das folgende Diagramm zeigt, wie eine Rollenbindung auf ein Projekt angewendet wird, das sich über mehrere Cluster erstreckt.
Rollenbindungen werden auf Projektebene festgelegt, um zu definieren, wer was mit welchem Ressourcentyp tun kann. Arbeitslasten wie VMs oder Pods werden in einem Projekt bereitgestellt und der Zugriff auf diese Arbeitslasten wird durch die Rollenbindung geregelt. Die Rollenbindung gilt einheitlich für VM-basierte und containerbasierte Arbeitslasten, unabhängig davon, in welchem Cluster sie bereitgestellt werden.
Das folgende Diagramm zeigt, wie der Zugriff zwischen Projekten durch Netzwerkrichtlinien verwaltet wird.
Die projektübergreifende Kommunikation zwischen Backend Project, Frontend Project und Database Project ist deaktiviert. Ressourcen innerhalb eines Projekts können jedoch miteinander kommunizieren.
Netzwerkrichtlinien werden auf Projektebene festgelegt, um den Netzwerkzugriff zwischen Ressourcen selektiv zuzulassen. Standardmäßig dürfen alle Ressourcen innerhalb eines Projekts über das interne Netzwerk miteinander kommunizieren. Eine Ressource in einem Projekt kann nicht mit einer Ressource in einem anderen Projekt kommunizieren. Dieses Verhalten für Netzwerkrichtlinien gilt unabhängig davon, ob Ressourcen im selben Cluster bereitgestellt werden oder nicht.
Sie können auch eine benutzerdefinierte ProjectNetworkPolicy-Ressource definieren, um die projektübergreifende Kommunikation zu ermöglichen. Diese Richtlinie wird für jedes Projekt definiert, um eingehenden Traffic aus anderen Projekten zuzulassen. Das folgende Diagramm veranschaulicht eine benutzerdefinierte Ressource ProjectNetworkPolicy, die für Backend Project definiert ist, um die Datenübertragung von Frontend Project und Database Project zu ermöglichen.
Außerdem werden mit dem Monitoring-Stack Messwerte in der gesamten Organisation erfasst. Sie können jedoch auf verschiedenen Ebenen der Ressourcenhierarchie filtern und Abfragen ausführen. Sie können Messwerte mit Entitäten wie einem Cluster oder Namespace abfragen.
Projekte pro Bereitstellungsumgebung erstellen
Wir empfehlen, für jede Arbeitslast separate Projekte für die Produktion, die Entwicklung und alle anderen erforderlichen Bereitstellungsumgebungen zu erstellen. Wenn Sie Ihre Produktions- und Entwicklungsbereitstellungsumgebungen trennen, können Sie Rollenbindungen und Netzwerkrichtlinien detailliert definieren. So wirken sich Änderungen, die in einem für die Entwicklung verwendeten Projekt vorgenommen werden, nicht auf die Produktionsumgebung aus.
Rollenbindungen auf Ressourcenebene in Projekten gewähren
Je nach Teamstruktur und Anforderungen können Sie Entwicklern erlauben, alle Ressourcen in dem von ihnen verwalteten Projekt zu ändern, oder eine detailliertere Zugriffssteuerung erforderlich machen. Innerhalb eines Projekts können Sie detaillierte Rollenbindungen gewähren, damit einzelne Entwickler auf einige, aber nicht alle Ressourcen im Projekt zugreifen können. Ein Team kann beispielsweise einen Datenbankadministrator haben, der die Datenbank verwalten, aber keine anderen Ressourcen ändern darf. Die Softwareentwickler im Team dürfen die Datenbank nicht ändern.
Cluster für die logische Isolierung von Kubernetes-Vorgängen entwerfen
Ein Kubernetes-Cluster ist keine harte Mandantengrenze, da Rollenbindungen und Netzwerkrichtlinien für Projekte und nicht für Kubernetes-Cluster gelten. Zwischen Kubernetes-Clustern und Projekten besteht eine m:n-Beziehung. Sie können mehrere Kubernetes-Cluster in einem einzelnen Projekt oder einen einzelnen Kubernetes-Cluster haben, der sich über mehrere Projekte erstreckt.