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 ausgewogenes Verhältnis zwischen effizienter Ressourcennutzung, Isolation von Arbeitslasten und einfacher Bedienung.
Organisationen für die physische und logische Isolation zwischen Kunden entwerfen
Die Ressource Organization ist die Stammressource für alle Ressourcen, die einem einzelnen Kunden gehören. Eine detaillierte Zugriffssteuerung zwischen Arbeitslasten innerhalb einer Organisation kann über Rollenbindungen und Netzwerkrichtlinien definiert werden. Weitere Informationen finden Sie unter Identity and Access Management.
Jede Organisation innerhalb einer GDC-Zone bietet physische Isolation für die Computing-Infrastruktur und logische Isolation für Netzwerk, Speicher und andere Dienste. Nutzer in einer Organisation haben keinen Zugriff auf Ressourcen in einer anderen Organisation, es sei denn, ihnen wurde explizit Zugriff gewährt. Netzwerkverbindungen von einer Organisation zu einer anderen sind standardmäßig nicht zulässig, es sei denn, sie sind explizit so konfiguriert, dass die ausgehende Datenübertragung von einer Organisation und die eingehende Datenübertragung zu einer anderen Organisation zulässig sind.
Umfang der Arbeitslasten definieren, die eine Organisation gemeinsam nutzen können
Der Umfang einer Organisation in Ihrem Unternehmenskontext kann je nachdem, wie Ihr Unternehmen Vertrauensgrenzen definiert, variieren. Einige Unternehmen möchten möglicherweise mehrere Organisationsressourcen für verschiedene Entitäten im Unternehmen erstellen. Beispielsweise kann jede Abteilung eines Unternehmens ein unabhängiger Kunde von GDC 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 freigegebene Datenquelle, eine Verbindung zwischen Arbeitslasten oder ein freigegebenes Monitoring-Tool sein.
- Arbeitslasten können einen administrativen 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 teilen, sofern eine ausreichende logische Trennung vorhanden ist.
- Der gleiche Budgetinhaber ist für die Arbeitslastbudgets insgesamt verantwortlich. Weitere Informationen zum Aufrufen 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 Hochverfügbarkeitsanforderungen für die Entfernung zwischen mehreren Zonen entsprechen.
Projekte für die logische Isolation zwischen Arbeitslasten entwerfen
Wir empfehlen, innerhalb einer Organisation 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 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. 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 bestimmten 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 unterliegt der Rollenbindung. 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 Netzwerkrichtlinien den Zugriff zwischen Projekten verwalten.
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 können alle Ressourcen innerhalb eines einzelnen Projekts im internen Netzwerk miteinander kommunizieren. Eine Ressource in einem Projekt kann jedoch 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 von anderen Projekten zuzulassen. Das folgende Diagramm zeigt eine benutzerdefinierte ProjectNetworkPolicy-Ressource, die für Backend Project definiert ist, um die eingehende Datenübertragung von Frontend Project und Database Project zu ermöglichen.
Darüber hinaus werden im Monitoring-Stack Messwerte für die gesamte Organisation erfasst. Sie können 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
Wir empfehlen, für jede Arbeitslast 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önnten beispielsweise Softwareentwicklungsumgebungen für Tests, Entwicklung und Produktion haben. Durch die Trennung Ihrer Softwareentwicklungsumgebungen können Sie Rollenbindungen und Netzwerkrichtlinien detailliert definieren, sodass Änderungen in einem Projekt, das für eine Nicht-Produktionsumgebung verwendet wird, keine Auswirkungen auf die Produktionsumgebung haben.
Rollenbindungen auf Ressourcenebene in Projekten gewähren
Je nach Teamstruktur und Anforderungen können Sie Entwicklern erlauben, jede Ressource innerhalb des von ihnen verwalteten Projekts zu ändern, oder Sie benötigen eine detailliertere Zugriffssteuerung. Innerhalb eines Projekts weisen Sie detaillierte Rollenbindungen zu, 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, während die Softwareentwickler im Team keine Berechtigung zum Ändern der Datenbank haben dürfen.
Cluster für die logische Isolation 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. Kubernetes-Cluster und Projekte haben 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.