In diesem Dokument wird die Ressourcenhierarchie von Google Distributed Cloud (GDC) in einer Air-Gap-Umgebung beschrieben und es wird erläutert, wie Ressourcen in einer Air-Gap-Instanz verwaltet werden. Informationen zum Verwalten von Ressourcen in mehreren Zonen finden Sie in der Übersicht über mehrere Zonen.
Die GDC-Ressourcenhierarchie hat zwei Ziele:
- Sie stellt eine Hierarchie von Inhaberschaften zur Verfügung, in der der Lebenszyklus einer Ressource an das in der Hierarchie unmittelbar übergeordnete Element gebunden ist.
- Sie ermöglicht das Zuweisen und Übernehmen von Zugriffssteuerungs- und Organisationsrichtlinien.
Die GDC-Ressourcenhierarchie ähnelt dem Dateisystem, das in Betriebssystemen zur hierarchischen Organisation und Verwaltung von Elementen verwendet wird. Im Allgemeinen hat jede Ressource genau ein übergeordnetes Element. Diese hierarchische Organisation von Ressourcen ermöglicht es Ihnen, Richtlinien für die Zugriffssteuerung wie IAM (Identity and Access Management) festzulegen, die von untergeordneten Ressourcen übernommen werden.
Weitere Informationen zu Best Practices für die Organisation Ihrer Zugriffsgrenzen finden Sie unter Zugriffsgrenzen zwischen Ressourcen entwerfen.
Ressourcenstruktur im Detail
Die folgenden Einheiten sind Ressourcentypen, die in der GDC-Ressourcenhierarchie erkannt werden:
GDC-Ressourcen sind hierarchisch organisiert. Die meisten Ressourcen in der Ressourcenhierarchie haben genau ein übergeordnetes Element. Die Ausnahme gilt nur für die höchste Ressource. Auf der untersten Ebene sind Dienstressourcen die grundlegenden Komponenten aller GDC-Dienste.
Eine Organisation ist die oberste Ebene der GDC-Ressourcenhierarchie. Alle Ressourcen, die zu einer Organisation gehören, sind unter der Organisationsressource gruppiert. Dies ermöglicht die zentralisierte Sichtbarkeit und Steuerung aller Ressourcen einer Organisation.
Sowohl Projekte als auch Cluster sind organisationsbezogen. Sie können aneinander angehängt werden, um Dienstressourcen zu organisieren. Projekte und Cluster funktionieren jedoch unabhängig voneinander. Diese Flexibilität bietet viele verschiedene Möglichkeiten, Dienste und Arbeitslasten zu organisieren. Sie können beispielsweise einen Cluster für ein einzelnes Projekt haben. Ebenso kann sich ein Cluster über mehrere Projekte erstrecken.
Dienstressourcen sind Einheiten, die zu einem Projekt oder einem Cluster gehören müssen und nicht projekt- oder clusterübergreifend freigegeben werden können. Beispiele für Dienstressourcen sind virtuelle Maschinen (VMs), Datenbanken, Storage-Buckets und Back-ups. Die meisten dieser untergeordneten Ressourcen haben Projektressourcen als übergeordnete Elemente.
Im folgenden Diagramm ist ein Beispiel für die GDC-Ressourcenhierarchie dargestellt:
Weitere Informationen zu Best Practices für die Organisation Ihrer Ressourcenhierarchie zur optimalen Arbeitslastverwaltung finden Sie unter Trennung von Nutzerarbeitslasten entwerfen.
Organisation
Die Organisationsressource stellt eine Verwaltungseinheit oder eine Geschäftsfunktion wie ein Unternehmen dar und ist die Ressource der obersten Ebene in der GDC-Ressourcenhierarchie. Eine Organisation definiert eine Sicherheitsgrenze, die Infrastrukturressourcen umfasst, die gemeinsam verwaltet werden sollen, damit Nutzer Anwendungs-Workloads bereitstellen können. Organisationen sind global und umfassen alle Zonen in einem Universum. Innerhalb einer Organisation werden Dienstressourcen wie VMs und Speichervolumes logisch nach Projekten gruppiert.
Alle Projekte, Cluster und Dienstressourcen gehören Ihrer Organisation und nicht den Erstellern. Das bedeutet, dass kein Ressourcentyp für eine Organisation gelöscht wird, wenn der Nutzer, der ihn erstellt hat, die Organisation verlässt. Stattdessen folgen alle Ressourcentypen dem Lebenszyklus der Organisation in GDC.
Die auf die Organisationsressource angewendeten IAM-Zugriffssteuerungsrichtlinien gelten innerhalb der gesamten Hierarchie für alle Ressourcen der Organisation. Weitere Informationen zum Gewähren von organisationsweiten Richtlinien und Berechtigungen finden Sie in den Abschnitten Organisationsrichtlinien und IAM.
Projekt
Ein Projekt ist eine Mandanteneinheit, in die jeder Dienst integriert werden muss. Projekte bieten eine logische Gruppierung von Dienstressourcen. Projekte sind global und umfassen alle Zonen in einem Universum.
Projekte ermöglichen die Segmentierung von Dienstressourcen innerhalb einer Organisation und bieten eine Lebenszyklus- und Richtliniengrenze für die Verwaltung von Ressourcen. Diensteressourcen in einem Projekt können niemals länger als das Projekt selbst bestehen oder zwischen Projekten verschoben werden. So ist die Kontrolle über die gesamte Lebensdauer einer Ressource hinweg gewährleistet. Daher müssen Sie Ressourcen eines beliebigen Typs in einem Projekt-Namespace bereitstellen.
Ein Projekt gilt als richtiger Kubernetes-Namespace, der sich über mehrere Cluster in einer Organisation erstreckt. Bei Namespace-Gleichheit werden alle Namespaces mit einem bestimmten Namen als derselbe Namespace für alle Cluster innerhalb derselben Organisation betrachtet. Der einzelne Namespace hat in allen Clustern denselben Inhaber. Dienstanbieter erstellen projektbezogene Dienste, indem sie Komponenten der Steuerungsebene und der Datenebene im Namespace erstellen.
Der Namespace für ein Projekt enthält Folgendes:
- Projektbezogene Dienst-APIs.
- Richtlinienkonfigurationen auf Projektebene, z. B. Rollen und Rollenbindungen.
Sie können ein Projekt nur an eine Teilmenge von Clustern in einer Organisation anhängen. Sie können containerisierte Arbeitslasten in diesen Clustern in einem Projektnamespace bereitstellen. Das Konzept der Namespace-Gleichheit gilt für den Projektnamespace in diesen Clustern. Richtlinien mit Namespace-Bereich, z. B. Richtlinien für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC), gelten für alle diese Namespaces.
Weitere Informationen zu Projekten finden Sie in der Projektübersicht.
Kubernetes-Cluster
Ein Kubernetes-Cluster ist eine Gruppe von Knoten, auf denen containerisierte Arbeitslasten als Teil von GKE auf GDC ausgeführt werden. Sie können Kubernetes-Cluster bereitstellen, um die Rechenanforderungen Ihrer Anwendungen zu erfüllen. Cluster sind organisationsbezogen und müssen mit einem oder mehreren Projekten verknüpft sein.
In Clustern werden Infrastrukturressourcen in isolierte Pools unterteilt, die von Projekten innerhalb einer Organisation genutzt werden können. Cluster sind auch logisch voneinander getrennt, um unterschiedliche Fehlerdomains und Isolierungsgarantien zu bieten. Die Durchsetzung von Richtlinien pro Organisation sorgt dafür, dass Cluster von Teams und Nutzern gemeinsam genutzt werden können, während gleichzeitig Leistungs- und Ressourcengarantien eingehalten werden. Außerdem ermöglichen Organisationsrichtlinien, dass VM-Arbeitslasten neben Containerarbeitslasten ausgeführt werden können, ohne dass die betriebliche Komplexität zunimmt.
Cluster sind für Instanzen von Vorteil, in denen Sie containerisierte Arbeitslasten bereitstellen müssen. Da jedoch die Möglichkeit besteht, VM-basierte Arbeitslasten bereitzustellen, ist das Vorhandensein eines Kubernetes-Clusters in GDC nicht erforderlich.
Cluster sind nur zonale Ressourcen und können nicht mehrere Zonen umfassen. Wenn Sie Cluster in einer Bereitstellung mit mehreren Zonen betreiben möchten, müssen Sie Cluster in jeder Zone manuell bereitstellen.
Weitere Informationen zu Kubernetes-Clustern finden Sie im Abschnitt Kubernetes-Cluster verwalten.
Serviceressource
Zu den Dienstressourcen gehören viele Einheiten, z. B.:
- VMs
- Datenbanken
- Storage-Buckets
- Containerisierte Arbeitslasten
- Sicherungen
Dienstressourcen müssen zu einem Projekt oder optional zu einem Cluster für containerisierte Arbeitslasten gehören und können nicht projektübergreifend freigegeben werden. Das bedeutet, dass Dienstressourcen in einem Projekt niemals länger als das Projekt selbst bestehen können. So ist sichergestellt, dass die Kontrolle über die gesamte Lebensdauer der Ressource verfügbar ist.
Diensteressourcen können je nach Typ global oder zonal bereitgestellt werden. Informationen zu Optionen für die Bereitstellung in mehreren Zonen finden Sie in der Dokumentation des jeweiligen Diensts. Diensteressourcen sind standardmäßig aktiviert und können mit einer Organisationsrichtlinie deaktiviert werden.