In diesem Dokument werden Best Practices für das Entwerfen der Hierarchie und Trennung von Arbeitslasten in Google Distributed Cloud (GDC) mit Air-Gap mithilfe von Organisationen, Projekten und Kubernetes-Clustern vorgestellt. Diese Anleitung bietet ein Gleichgewicht zwischen effizienter Ressourcennutzung, Isolation von Arbeitslasten und einfacher Bedienung.
Organisationen für die physische und logische Isolation zwischen Kunden entwerfen
Die Ressource Organization ist das Stammverzeichnis 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 Netzwerke, Speicher und andere Dienste. Nutzer in einer Organisation haben keinen Zugriff auf Ressourcen in einer anderen Organisation, es sei denn, sie haben ausdrücklich Zugriff erhalten. Die Netzwerkverbindung von einer Organisation zu einer anderen ist standardmäßig nicht zulässig, es sei denn, sie ist ausdrücklich so konfiguriert, dass die Datenübertragung von einer Organisation und die Datenübertragung zu einer anderen Organisation zulässig ist.
Umfang der Arbeitslasten definieren, die eine Organisation gemeinsam nutzen können
Der Umfang einer Organisation im Kontext Ihres Unternehmens kann je nachdem variieren, wie Ihr Unternehmen Vertrauensgrenzen definiert. Einige Unternehmen erstellen möglicherweise mehrere Organisationsressourcen für verschiedene Entitäten 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 benötigen.
Im Allgemeinen empfehlen wir, mehrere Arbeitslasten anhand der folgenden Signale in einer einzigen Organisation zu gruppieren:
- Arbeitslasten können Abhängigkeiten gemeinsam nutzen. Dies kann beispielsweise eine gemeinsame Datenquelle, eine Verbindung zwischen Arbeitslasten oder ein gemeinsames Überwachungstool sein.
- Arbeitslasten können eine gemeinsame administrative Vertrauensbasis haben. Derselbe Administrator kann mit privilegiertem Zugriff auf alle Arbeitslasten in der Organisation vertraut 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 Anzeigen der Gesamtkosten für die Organisation oder zur detaillierten Analyse pro 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 den Abstand 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 die zugrunde liegende physische Infrastruktur gemeinsam nutzen. 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 Entwerfen von Projektgrenzen die größte Gruppe von 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. Obwohl ein Namespace für mehrere Cluster reserviert ist, bedeutet das nicht, dass ein Pod automatisch für alle Cluster 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 mehrere Cluster umfasst.
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 gesteuert. 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 mit Netzwerkrichtlinien verwaltet wird.
Die projektübergreifende Kommunikation zwischen dem Backend Project, dem Frontend Project und dem Database Project ist deaktiviert. Ressourcen innerhalb der einzelnen Projekte können jedoch miteinander kommunizieren.
Netzwerkrichtlinien werden auf Projektebene festgelegt, um den Netzwerk zugriff zwischen Ressourcen selektiv zuzulassen. Standardmäßig dürfen alle Ressourcen innerhalb eines einzelnen Projekts im internen 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 Ressource vom Typ ProjectNetworkPolicy definieren, um die projektübergreifende Kommunikation zu aktivieren. Diese Richtlinie wird für jedes Projekt definiert, um eingehenden Traffic von anderen Projekten zuzulassen. Das folgende Diagramm zeigt eine benutzerdefinierte Ressource vom Typ ProjectNetworkPolicy, die für das Backend Project definiert wurde, um die Datenübertragung vom Frontend Project und Database Project zu ermöglichen.
Außerdem werden mit dem Überwachungsstack Messwerte in der gesamten Organisation erfasst. Sie können sie jedoch auf verschiedenen Ebenen der Ressourcenhierarchie filtern und abfragen. Sie können Messwerte mit Entitäten wie einem Cluster oder Namespace abfragen.
Projekte pro Softwareentwicklungsumgebung erstellen
Für jede Arbeitslast empfehlen wir, separate Projekte für jede Softwareentwicklungsumgebung zu erstellen. Eine Softwareentwicklungsumgebung ist ein Bereich in Ihrem GDC-Universum, der für alle Vorgänge vorgesehen ist, die einer bestimmten Lebenszyklusphase entsprechen. Sie können beispielsweise Softwareentwicklungsumgebungen für Tests, Entwicklung und Produktion haben. Durch die Trennung Ihrer Softwareentwicklungsumgebungen können Sie Rollenbindungen und Netzwerkrichtlinien detailliert definieren, sodass sich Änderungen in einem Projekt, das für eine Nichtproduktionsumgebung verwendet wird, nicht auf die Produktionsumgebung auswirken.
Rollenbindungen auf Ressourcenebene innerhalb von Projekten gewähren
Je nach Teamstruktur und Anforderungen können Sie Entwicklern erlauben, jede Ressource in dem von ihnen verwalteten Projekt zu ändern, oder Sie benötigen eine detailliertere Zugriffssteuerung. Innerhalb eines Projekts gewähren Sie detaillierte Rollenbindungen, 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 Isolation von Kubernetes-Vorgängen entwerfen
Ein Kubernetes-Cluster ist keine feste 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 mehrere Projekte umfasst.