In diesem Dokument wird die Ressourcenhierarchie von Google Distributed Cloud (GDC) mit Air Gap beschrieben und wie Ressourcen in einer Instanz mit Air Gap verwaltet werden. Informationen zum Verwalten von Ressourcen über mehrere Zonen hinweg finden Sie in der Übersicht über mehrere Zonen.
Die GDC-Ressourcenhierarchie dient zwei Zwecken:
- 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 verwendet wird, um Entitäten hierarchisch zu organisieren und zu verwalten. Im Allgemeinen ist jeder Ressource genau ein Element übergeordnet. Diese hierarchische Organisation von Ressourcen ermöglicht es Ihnen, Richtlinien für die Zugriffssteuerung wie Identity and Access Management (IAM) 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 Entitäten 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 niedrigsten Ebene sind Dienstressourcen die grundlegenden Komponenten, aus denen alle GDC-Dienste bestehen.
Eine Organisation ist die oberste Ebene der GDC-Ressourcenhierarchie. Alle Ressourcen, die zu einer Organisation gehören, werden unter der Organisationsressource gruppiert. Dies bietet eine zentrale Übersicht und Kontrolle über alle Ressourcen, die zu einer Organisation gehören.
Sowohl Projekte als auch freigegebene Kubernetes-Cluster sind auf Organisationsebene beschränkt. Sie können aneinander angehängt werden, um Dienstressourcen zu organisieren. Projekte und freigegebene Cluster funktionieren jedoch unabhängig voneinander. Diese Flexibilität bietet viele verschiedene Möglichkeiten, Dienste und Arbeitslasten zu organisieren. Sie können beispielsweise einen freigegebenen Cluster haben, der einem einzelnen Projekt zugeordnet ist. Ebenso kann ein freigegebener Cluster mehrere Projekte umfassen.
Dienstressourcen sind Entitäten, die zu einem Projekt gehören müssen und nicht projektübergreifend freigegeben werden können. Beispiele für Dienstressourcen sind virtuelle Maschinen (VMs), Standard-Kubernetes-Cluster, Datenbanken, Storage-Buckets und Sicherungen. Die meisten dieser untergeordneten Ressourcen haben Projektressourcen als übergeordnete Ressourcen.
Im folgenden Diagramm ist ein Beispiel für die GDC-Ressourcenhierarchie dargestellt:
Weitere Informationen zu Best Practices für die Organisation Ihrer Ressourcenhierarchie für eine optimale Workload-Verwaltung finden Sie unter Trennung von Nutzerarbeitslasten entwerfen.
Organisation
Die Organisationsressource stellt eine Verwaltungseinheit oder eine Geschäftsfunktion dar, z. B. ein Unternehmen, und ist die Ressource auf oberster Ebene in der GDC-Ressourcenhierarchie. Eine Organisation definiert eine Sicherheitsgrenze, die Infrastrukturressourcen umfasst, die gemeinsam verwaltet werden sollen, damit Nutzer Anwendungslasten bereitstellen können. Organisationen sind global und umfassen alle Zonen in einem Universum. Innerhalb einer Organisation werden Dienstressourcen wie VMs und Speicher-Volumes logisch nach Projekten gruppiert.
Alle Projekte, Cluster und Dienstressourcen gehören Ihrer Organisation und nicht den Erstellern. Das bedeutet, dass Ressourcentypen für eine Organisation nicht gelöscht werden, wenn der Nutzer, der sie erstellt hat, die Organisation verlässt. Stattdessen folgen alle Ressourcentypen dem Lebenszyklus der Organisation in GDC.
Die IAM-Zugriffssteuerungsrichtlinien für die Organisationsressource gelten innerhalb der Hierarchie für alle Ressourcen in 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, die in jeden Dienst eingebunden 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. Dienstressourcen innerhalb eines Projekts können nie länger als das Projekt selbst bestehen oder zwischen Projekten verschoben werden. So ist die Kontrolle über die gesamte Lebensdauer einer Ressource gewährleistet. Daher müssen Sie Ressourcen aller Typen innerhalb eines Projekt-Namespace bereitstellen.
Ein Projekt wird als ein Kubernetes-Namespace betrachtet, der sich über mehrere freigegebene Cluster in einer Organisation erstreckt. Bei der Namespace-Gleichheit werden alle Namespaces mit einem bestimmten Namen als derselbe Namespace für alle freigegebenen Cluster innerhalb derselben Organisation betrachtet. Der einzelne Namespace hat einen einheitlichen Inhaber für alle freigegebenen Cluster. Dienstanbieter erstellen projektspezifische Dienste, indem sie Komponenten der Steuerungsebene und Datenebene im Namespace erstellen.
Der Namespace für ein Projekt hostet Folgendes:
- Projektbezogene Dienst-APIs.
- Richtlinienkonfigurationen auf Projektebene, z. B. Rollen und Rollenbindungen.
Sie können ein Projekt nur an eine Teilmenge der freigegebenen Cluster in einer Organisation anhängen. Sie können Containerarbeitslasten in diesen freigegebenen Clustern innerhalb eines Projekt-Namespace bereitstellen. Das Konzept der Namespace-Gleichheit gilt für den Projekt-Namespace in diesen freigegebenen Clustern. Richtlinien auf Namespace-Ebene, 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.
Gemeinsam genutzter Kubernetes-Cluster
Ein Kubernetes-Cluster ist eine Gruppe von Knoten, die containerisierte Arbeitslasten als Teil von GKE on GDC ausführen. Sie können Kubernetes-Cluster bereitstellen, um die Rechenanforderungen Ihrer Anwendungen zu erfüllen.
Ein freigegebener Cluster ist eine Clusterkonfiguration, die auf Organisationsebene gilt und an ein oder mehrere Projekte angehängt werden muss. Der Standardcluster ist eine weitere Clusterkonfiguration, die nur innerhalb eines einzelnen Projekts funktioniert, aber in der Ressourcenhierarchie als Dienstressource gilt. Diese Kubernetes-Clusterkonfigurationen sind für die Erstellung einer Kubernetes-Architektur konzipiert, die Containerverwaltungsoptionen für Softwareentwicklungsumgebungen wie Test, Entwicklung und Produktion bietet. Weitere Informationen zu Best Practices für die Trennung von Containerarbeitslasten finden Sie unter Arbeitslasttrennung entwerfen.
Weitere Informationen zu den verschiedenen Clustertypen in GDC finden Sie unter Kubernetes-Clusterkonfigurationen.
In freigegebenen Clustern werden Infrastrukturressourcen in isolierte Pools unterteilt, die von Projekten innerhalb einer Organisation genutzt werden können. Cluster sind auch logisch voneinander getrennt, um verschiedene Fehlerdomains und Isolationsgarantien zu bieten. Durch die Durchsetzung von Richtlinien pro Organisation wird sichergestellt, dass freigegebene Cluster von Teams und Nutzern gemeinsam verwendet werden können, während gleichzeitig die Leistung und Ressourcen garantiert werden. Darüber hinaus ermöglichen Organisationsrichtlinien, dass VM-Arbeitslasten zusammen mit Containerarbeitslasten ausgeführt werden, ohne dass die operative Komplexität erhöht wird.
Cluster sind nützlich, wenn Sie containerisierte Arbeitslasten bereitstellen müssen. Mit der Option, VM-basierte Arbeitslasten bereitzustellen, ist jedoch kein Kubernetes-Cluster in GDC 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 unter Kubernetes-Cluster – Übersicht.
Dienstressource
Dienstressourcen umfassen viele Entitäten, z. B.:
- VMs
- Standard-Kubernetes-Cluster
- Datenbanken
- Storage-Buckets
- Containerisierte Arbeitslasten
- Sicherungen
Dienstressourcen müssen zu einem Projekt gehören und können nicht projektübergreifend freigegeben werden. Dieser projektspezifische Lebenszyklus bedeutet, dass Dienstressourcen innerhalb eines Projekts nie länger als das Projekt selbst bestehen. So ist die Kontrolle über die gesamte Lebensdauer der Ressource gewährleistet.
Dienstressourcen können je nach Typ global oder zonal bereitgestellt werden. Informationen zu Bereitstellungsoptionen für mehrere Zonen finden Sie in der Dokumentation des jeweiligen Dienstes. Dienstressourcen sind standardmäßig aktiviert und können mithilfe einer Organisationsrichtlinie deaktiviert werden.