In diesem Dokument wird die Ressourcenhierarchie von Google Distributed Cloud (GDC) mit Air Gap beschrieben und erläutert, wie Ressourcen in einer Instanz mit Air Gap verwaltet werden. Konzepte zum Verwalten von Ressourcen in mehreren Zonen finden Sie in der Übersicht zu mehreren 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 zur Verwaltung von Entitäten 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 festzulegen, z. B. Identity and Access Management (IAM), 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 oberste Ressource. Auf der untersten Ebene stellen Dienstressourcen die grundlegenden Komponenten aller GDC-Dienste dar.
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 freigegebene Kubernetes-Cluster sind auf Organisationsebene verfügbar. Sie können miteinander verknüpft 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 gewidmet ist. Ebenso kann sich ein freigegebener Cluster über mehrere Projekte erstrecken.
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 Elemente.
Das folgende Diagramm zeigt ein Beispiel für eine GDC-Ressourcenhierarchie:
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 zusammen verwaltet werden sollen, damit Nutzer Anwendungsarbeitslasten 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 ihren 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 Erteilen von organisationsweiten Richtlinien und Berechtigungen finden Sie in den Abschnitten zu Organisationsrichtlinien und IAM.
Projekt
Ein Projekt ist eine Mandanteneinheit, in die jeder 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 in einem Projekt können niemals länger als das Projekt selbst bestehen oder zwischen Projekten verschoben werden. So ist die Kontrolle über den gesamten Lebenszyklus einer Ressource gewährleistet. Daher müssen Sie Ressourcen eines beliebigen Typs in einem Projektnamespace bereitstellen.
Ein Projekt gilt als ordnungsgemäßer Kubernetes-Namespace, der sich über mehrere freigegebene Cluster in einer Organisation erstreckt. Bei der Namespace-Gleichheit werden alle Namespaces mit einem bestimmten Namen für alle freigegebenen Cluster innerhalb derselben Organisation als derselbe Namespace betrachtet. Der einzelne Namespace hat für alle freigegebenen Cluster denselben Inhaber. Dienstanbieter erstellen Dienste auf Projektebene, indem sie Komponenten der Steuerungsebene und der Datenebene im Namespace erstellen.
Der Namespace für ein Projekt hostet Folgendes:
- Dienst-APIs auf Projektebene.
- 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 containerisierte Arbeitslasten in diesen freigegebenen Clustern innerhalb eines Projektnamespace bereitstellen. Das Konzept der Namespace-Gleichheit gilt für den Projektnamespace in diesen freigegebenen Clustern. Namespace-bezogene Richtlinien wie 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 Übersicht zu Projekten.
Freigegebener Kubernetes-Cluster
Ein Kubernetes-Cluster ist eine Gruppe von Knoten, auf denen containerisierte Arbeitslasten als Teil von GKE on GDC ausgeführt werden. Sie können Kubernetes-Cluster bereitstellen, um die Rechenanforderungen Ihrer Anwendungen zu erfüllen.
Ein freigegebener Cluster ist eine Clusterkonfiguration, die auf Organisationsebene verfügbar ist 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 betrachtet wird. Diese Kubernetes-Clusterkonfigurationen sind so konzipiert, dass sie eine Kubernetes-Architektur erstellen, die Optionen für die Containerverwaltung in verschiedenen Softwareentwicklungsumgebungen bietet, z. B. für Tests, Entwicklung und Produktion. 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.
Freigegebene Cluster unterteilen Infrastrukturressourcen in isolierte Pools, die von Projekten innerhalb einer Organisation genutzt werden können. Cluster sind auch logisch voneinander getrennt, um verschiedene Fehlerbereiche und Isolationsgarantien zu bieten. Die Durchsetzung von Richtlinien pro Organisation sorgt dafür, dass freigegebene Cluster von mehreren Teams und Nutzern gemeinsam genutzt werden können, während gleichzeitig Leistungs- und Ressourcengarantien eingehalten werden. Darüber hinaus ermöglichen Organisationsrichtlinien, dass VM-Arbeitslasten neben Containerarbeitslasten ausgeführt werden können, ohne die betriebliche Komplexität zu erhöhen.
Cluster sind in Fällen von Vorteil, in denen Sie containerisierte Arbeitslasten bereitstellen müssen. Da Sie jedoch auch VM-basierte Arbeitslasten bereitstellen können, ist das Vorhandensein eines Kubernetes-Clusters in GDC nicht erforderlich.
Cluster sind nur eine zonale Ressource und können sich nicht über mehrere Zonen erstrecken. Wenn Sie Cluster in einer Bereitstellung mit mehreren Zonen verwenden möchten, müssen Sie Cluster manuell in jeder Zone bereitstellen.
Weitere Informationen zu Kubernetes-Clustern finden Sie in der Übersicht zu Kubernetes-Clustern.
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 in einem Projekt niemals länger als das Projekt selbst bestehen können. So ist die Kontrolle über den gesamten Lebenszyklus 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 mit einer Organisationsrichtlinie deaktiviert werden.