Steuerelemente für Entwicklerplattformen

In diesem Abschnitt werden die in der Entwicklerplattform verwendeten Steuerelemente beschrieben.

Plattformidentität, Rollen und Gruppen

Für den Zugriff auf Google Cloud Dienste sind Google Cloud Identitäten erforderlich. Im Blueprint wird die Workload Identity-Föderation für Flotten für GKE verwendet, um die Kubernetes-Dienstkonten, die als Identitäten für Pods verwendet werden, denGoogle Cloud -Dienstkonten zuzuordnen, die den Zugriff auf Google Cloud-Dienste steuern. Um vor umgebungsübergreifenden Eskalierungen zu schützen, hat jede Umgebung einen separaten Identitätspool (eine Reihe vertrauenswürdiger Identitätsanbieter) für ihre Konten für die Identitätsföderation von Arbeitslasten für GKE.

Plattformidentitäten

Wenn Sie den Blueprint bereitstellen, erstellen Sie drei Arten von Nutzergruppen: ein Entwicklerplattformteam, ein Anwendungsteam (ein Team pro Anwendung) und ein Security Operations-Team.

Das Entwicklerplattformteam ist für die Entwicklung und Verwaltung der Entwicklerplattform verantwortlich. Die Mitglieder dieses Teams sind:

  • Entwickler der Entwicklerplattform:Diese Teammitglieder erweitern den Blueprint und integrieren ihn in bestehende Systeme. Dieses Team erstellt auch neue Anwendungsvorlagen.
  • Administrator der Entwicklerplattform:Dieses Team ist für Folgendes verantwortlich:
    • Genehmigung der Erstellung neuer Teams für Mandanten.
    • Ausführen geplanter und ungeplanter Aufgaben, die sich auf mehrere Mandanten auswirken, einschließlich der folgenden:
    • Genehmigung der Übertragung von Anwendungen in die Nicht-Produktionsumgebung und die Produktionsumgebung.
    • Koordinieren von Infrastrukturupdates
    • Kapazitätspläne auf Plattformebene erstellen

Ein Mandant der Entwicklerplattform ist ein einzelnes Softwareentwicklungsteam und die für den Betrieb dieser Software Verantwortlichen. Das Mandantenteam besteht aus zwei Gruppen: Anwendungsentwicklern und Anwendungsoperatoren. Die Aufgaben der beiden Gruppen des Mandantenteams sind wie folgt:

  • Anwendungsentwickler: Dieses Team schreibt und behebt Anwendungscode. Sie werden manchmal auch als Softwareentwickler oder Full-Stack-Entwickler bezeichnet. Zu ihren Aufgaben gehören:
    • Tests und Qualitätssicherung für eine Anwendungskomponente durchführen, wenn sie in der Entwicklungsumgebung bereitgestellt wird.
    • Verwaltung von Cloud-Ressourcen, die der Anwendung gehören (z. B. Datenbanken und Storage-Buckets), in der Entwicklungsumgebung.
    • Entwerfen von Datenbank- oder Speicherschemas für die Verwendung durch Anwendungen.
  • Anwendungsoperatoren oder Site Reliability Engineers (SREs): Dieses Team verwaltet die Zuverlässigkeit von Anwendungen, die in den Produktionsumgebungen ausgeführt werden, sowie die sichere Weiterentwicklung von Änderungen an der Anwendungsentwicklern in die Produktion. Sie werden manchmal auch als Dienstanbieter, Systemtechniker oder Systemadministratoren bezeichnet. Zu ihren Aufgaben gehören folgende:
    • Planung des Kapazitätsbedarfs auf Anwendungsebene.
    • Benachrichtigungsrichtlinien erstellen und Service Level Objectives (SLOs) für Dienste festlegen.
    • Diagnose von Dienstproblemen mithilfe von Logs und Messwerten, die für diese Anwendung spezifisch sind.
    • Auf Benachrichtigungen und Seiten reagieren, z. B. wenn ein Dienst seine SLOs nicht erfüllt.
    • Sie arbeiten mit einer oder mehreren Gruppen von Anwendungsentwicklern zusammen.
    • Genehmigung der Bereitstellung neuer Versionen in der Produktion.
    • Verwaltung von Cloud-Ressourcen, die der Anwendung gehören, in der Nicht-Produktions- und Produktionsumgebung (z. B. Back-ups und Schemaaktualisierungen).

Organisationsstruktur der Plattform

Der Blueprint für Unternehmensanwendungen verwendet die Organisationsstruktur, die vom Blueprint für Unternehmensgrundlagen bereitgestellt wird. Das folgende Diagramm zeigt, wie die Projekte des Enterprise Application Blueprint in die Struktur des Foundation Blueprint passen.

Die Blueprint-Projekte und ‑Ordner.

Plattformprojekte

In der folgenden Tabelle werden die zusätzlichen Projekte beschrieben, die über die im Fundament-Blueprint bereitgestellten Projekte hinaus für die Bereitstellung von Ressourcen, Konfigurationen und Anwendungen im Anwendungs-Blueprint erforderlich sind.

Ordner Projekt Beschreibung

common

eab-infra-cicd

Enthält die Infrastruktur-Pipeline für mehrere Mandanten zum Bereitstellen der Mandanteninfrastruktur.

eab-app-factory

Enthält die Anwendungs-Factory , mit der Single-Tenant-Anwendungsarchitekturen und CI/CD-Pipelines (Continuous Integration und Continuous Deployment) erstellt werden. Dieses Projekt enthält auch Config Sync, das für die Konfiguration des GKE-Cluster verwendet wird.

eab-{tenant}-cicd

Enthält die CI/CD-Pipelines der Anwendung, die sich in unabhängigen Projekten befinden, um eine Trennung zwischen den Entwicklungsteams zu ermöglichen. Für jede Anwendung gibt es eine Pipeline.

development,
nonproduction,
production

eab-gke

Enthält die GKE-Cluster für die Entwicklerplattform und die Logik, die zum Registrieren von Clustern für die Flottenverwaltung verwendet wird.

eab-{tenant}

(1-n)

Enthält alle Single-Tenant-Anwendungsdienste wie Datenbanken oder andere verwaltete Dienste, die von einem Anwendungsteam verwendet werden.

Plattformclusterarchitektur

Mit dem Blueprint werden Anwendungen in drei Umgebungen bereitgestellt: Entwicklung, Nicht-Produktion und Produktion. Jede Umgebung ist einer Flotte zugeordnet. In diesem Blueprint ist eine Flotte ein Projekt, das einen oder mehrere Cluster enthält. Flotten können jedoch auch mehrere Projekte gruppieren. Eine Flotte bietet eine logische Sicherheitsgrenze für die administrative Steuerung. Eine Flotte bietet eine Möglichkeit, Kubernetes-Cluster logisch zu gruppieren und zu normalisieren, was die Verwaltung der Infrastruktur erleichtert.

Das folgende Diagramm zeigt zwei GKE-Cluster, die in jeder Umgebung zum Bereitstellen von Anwendungen erstellt werden. Die beiden Cluster fungieren als identische GKE-Cluster in zwei verschiedenen Regionen, um für multiregionale Ausfallsicherheit zu sorgen. Um die Flottenfunktionen nutzen zu können, verwendet der Blueprint das Konzept der Gleichheit für Namespace-Objekte, Dienste und Identität.

Blueprint-Cluster.

Der Blueprint der Unternehmensanwendung verwendet GKE-Cluster mit privaten Bereichen, die über den Private Service Connect-Zugriff auf die Steuerungsebene und private Knotenpools aktiviert sind, um potenzielle Angriffsflächen aus dem Internet zu entfernen. Weder die Clusterknoten noch die Steuerungsebene haben einen öffentlichen Endpunkt. Die Clusterknoten führen Container-Optimized OS aus, um ihre Angriffsfläche zu begrenzen, und die Clusterknoten verwenden Shielded GKE-Knoten, um die Fähigkeit eines Angreifer zu reduzieren, die Identität eines Knotens zu übernehmen.

Der Administratorzugriff auf die GKE-Cluster wird über das Connect-Gateway aktiviert. Im Rahmen der Bereitstellung des Blueprints wird für jede Umgebung eine Cloud NAT-Instanz verwendet, um Pods und Config Sync einen Mechanismus für den Zugriff auf Ressourcen im Internet wie GitHub zu bieten. Der Zugriff auf die GKE-Cluster wird durch die Kubernetes RBAC-Autorisierung gesteuert, die auf Google Groups for GKE basiert. Mit Gruppen können Sie Identitäten mithilfe eines zentralen Identitätsverwaltungssystems steuern, das von Identitätsadministratoren gesteuert wird.

GKE-Plattformkomponenten

Die Entwicklerplattform verwendet GKE und zugehörige Komponenten, damit Sie den Lebenszyklus Ihrer Anwendungen erstellen, bereitstellen und verwalten können.

Die GKE-Komponenten, die in der Blueprint-Bereitstellung verwendet werden, sind die folgenden:

  • GKE für die Containerverwaltung
  • Policy Controller für die Richtlinienverwaltung und ‑erzwingung

Die zugehörigen Komponenten, die in der Blueprint-Bereitstellung verwendet werden, sind die folgenden:

Plattformflottenmanagement

Mit Flotten können Sie mehrere GKE-Cluster auf einheitliche Weise verwalten. Die Flottenteamverwaltung erleichtert es Plattformadministratoren, Infrastrukturressourcen für Mandanten der Entwicklerplattform bereitzustellen und zu verwalten. Mandanten haben eingeschränkte Kontrolle über Ressourcen in ihrem eigenen Namespace, einschließlich ihrer Anwendungen, Protokolle und Messwerte.

Administratoren können Teambereiche verwenden, um Teilmengen von Flottenressourcen für einzelne Teams bereitzustellen. Mit Teambereichen können Sie Teilmengen von Flottenressourcen für jedes Team definieren, wobei jeder Teambereich einem oder mehreren Clustern der Flottenmitglieder zugeordnet ist.

Mit Flotten-Namespaces können Sie steuern, wer Zugriff auf bestimmte Namespaces in Ihrer Flotte hat. Die Anwendung verwendet zwei GKE-Cluster, die in einer Flotte bereitgestellt werden, mit drei Teambereichen und einem Flotten-Namespace für jeden Bereich.

Das folgende Diagramm zeigt die Flotten- und Bereichsressourcen, die den Beispielclustern in einer Umgebung entsprechen, wie sie vom Blueprint implementiert werden.

Blueprint-Flotten- und ‑Bereichsressourcen.

Plattform-Networking

Für das Netzwerk werden GKE-Cluster in einer freigegebene VPC bereitgestellt, die im Rahmen des Blueprints für Unternehmensgrundlagen erstellt wird. Für GKE-Cluster müssen in den Entwicklungs-, Nicht-Produktions- und Produktionsumgebungen mehrere IP-Adressbereiche zugewiesen werden. Jeder vom Blueprint verwendete GKE-Cluster benötigt separate IP-Adressbereiche, die den Knoten, Pods, Diensten und der Steuerungsebene zugewiesen sind. Für AlloyDB for PostgreSQL-Instanzen sind ebenfalls separate IP-Adressbereiche erforderlich.

In der folgenden Tabelle werden die VPC-Subnetze und IP-Adressbereiche beschrieben, die in den verschiedenen Umgebungen zum Bereitstellen der Blueprint-Cluster verwendet werden. Für die Entwicklungsumgebung in GKE-Clusterregion 2 der Anwendung wird mit dem Blueprint nur ein IP-Adressbereich bereitgestellt, obwohl IP-Adressbereiche für zwei GKE-Entwicklungscluster zugewiesen sind.

Ressource Typ des IP-Adressbereichs Entwicklung Nicht-Produktion Produktion

GKE-Clusterregion 1 der Anwendung

Primärer IP-Adressbereich

10.0.64.0/24

10.0.128.0/24

10.0.192.0/24

Pod-IP-Adressbereich

100.64.64.0/24

100.64.128.0/24

100.64.192.0/24

Dienst-IP-Adressbereich

100.0.80.0/24

100.0.144.0/24

100.0.208.0/24

IP-Adressbereich der GKE-Steuerungsebene

10.16.0.0/21

10.16.8.0/21

10.16.16.0/21

GKE-Clusterregion 2 der Anwendung

Primärer IP-Adressbereich

10.1.64.0/24

10.1.128.0/24

10.1.192.0/24

Pod-IP-Adressbereich

100.64.64.0/24

100.64.128.0/24

100.64.192.0/24

Dienst-IP-Adressbereich

100.1.80.0/24

100.1.144.0/24

100.1.208.0/24

IP-Adressbereich der GKE-Steuerungsebene

10.16.0.0/21

10.16.8.0/21

10.16.16.0/21

AlloyDB for PostgreSQL

IP-Adressbereich der Datenbank

10.9.64.0/18

10.9.128.0/18

10.9.192.0/18

Wenn Sie ein eigenes Schema zur Zuweisung von IP-Adressen entwerfen müssen, lesen Sie die Informationen unter IP-Adressverwaltung in GKE und Planung von IPv4-Adressen in GKE.

Plattform-DNS

Im Blueprint wird Cloud DNS für GKE verwendet, um die DNS-Auflösung für Pods und Kubernetes-Dienste bereitzustellen. Cloud DNS für GKE ist ein verwaltetes DNS, für das kein Cluster-gehosteter DNS-Anbieter erforderlich ist.

Im Blueprint ist Cloud DNS für den VPC-Bereich konfiguriert. Mit dem VPC-Bereich können Dienste in allen GKE-Clustern in einem Projekt eine einzelne DNS-Zone gemeinsam nutzen. Mit einer einzelnen DNS-Zone können Dienste clusterübergreifend aufgelöst werden. VMs oder Pods außerhalb des Clusters können Dienste innerhalb des Clusters auflösen.

Plattform-Firewalls

GKE erstellt automatischFirewallregeln beim Erstellen vonGKE-Clustern ,GKE-Diensten,GKE-Gateway-Firewalls und GKE-Ingress-Firewalls, die den Betrieb von Clustern in Ihren Umgebungen ermöglichen. Die Priorität für alle automatisch erstellten Firewallregeln ist 1000. Diese Regeln sind erforderlich, da das Enterprise Foundation-Blueprint eine Standardregel zum Blockieren von Traffic in der freigegebene VPC enthält.

Plattformzugriff auf Google Cloud -Dienste

Da die Blueprint-Anwendungen private Cluster verwenden, bietet der private Google-Zugriff Zugriff auf Google Cloud -Dienste.

Hochverfügbarkeit der Plattform

Der Blueprint wurde so konzipiert, dass er sowohl zonalen als auch regionalen Ausfällen standhält. Die zum Ausführen von Anwendungen erforderlichen Ressourcen sind auf zwei Regionen verteilt. Sie wählen die Regionen aus, in denen das Blueprint bereitgestellt werden soll. Ressourcen, die nicht im kritischen Pfad für die Bereitstellung und Reaktion auf die Last liegen, sind nur in einer Region oder global verfügbar. In der folgenden Tabelle werden die Ressourcen und ihr Bereitstellungsort beschrieben.

Standort

Region 1

Region 2

Global

Umgebungen mit Ressourcen an diesem Standort
  • common
  • development
  • nonproduction
  • production
  • nonproduction
  • production
  • common
  • development
  • nonproduction
  • production

Projekte mit Ressourcen an diesem Standort
  • eab-gke-{env}
  • eab-infra-cicd
  • eab-{ns}-cicd
  • eab-gke-{env}
  • eab-{ns}-cicd (only for the Artifact Registry mirror)
  • eab-gke-{env}

Ressourcentypen an diesem Standort
  • GKE-Cluster (Anwendungen und Gateway-Konfiguration)
  • Artifact Registry
  • AlloyDB for PostgreSQL
  • Cloud Build
  • Cloud Deploy
  • GKE-Cluster (nur Anwendungen)
  • Artifact Registry
  • AlloyDB for PostgreSQL
  • Cloud Logging
  • Cloud Monitoring
  • Cloud Load Balancing
  • Flottenbereiche
  • Flotten-Namespaces

In der folgenden Tabelle ist zusammengefasst, wie verschiedene Komponenten auf einen Regions- oder Zonenausfall reagieren und wie Sie diese Auswirkungen abmildern können.

Umfang des Fehlers

Effekte externer Dienste

 Datenbankeffekte Effekte erstellen und bereitstellen Auswirkungen von Terraform-Pipelines

Eine Zone von Region 1

Verfügbar

Verfügbar

Die Standby-Instanz wird mit einem RPO von null aktiv.

Verfügbar, möglicherweise ist eine manuelle Änderung erforderlich.

Möglicherweise müssen Sie alle terraform apply-Befehle neu starten, die während des Ausfalls ausgeführt, aber abgeschlossen wurden.

Verfügbar, möglicherweise ist eine manuelle Änderung erforderlich.

Möglicherweise müssen Sie alle terraform apply-Befehle neu starten, die während des Ausfalls ausgeführt, aber abgeschlossen wurden.

Eine Zone von Region 2

Verfügbar

Verfügbar

Verfügbar

Verfügbar, möglicherweise ist eine manuelle Änderung erforderlich.

Möglicherweise müssen Sie alle terraform apply-Befehle neu starten, die während des Ausfalls ausgeführt, aber abgeschlossen wurden.

Region 1

Verfügbar

Manuelle Änderung erforderlich.

Ein Operator muss den sekundären Cluster manuell hochstufen.

Nicht verfügbar

Nicht verfügbar

Region 2

Verfügbar

Verfügbar

Verfügbar, möglicherweise manuelle Änderung erforderlich

Builds bleiben verfügbar. Möglicherweise müssen Sie neue Builds manuell bereitstellen. Vorhandene Builds werden möglicherweise nicht erfolgreich abgeschlossen.

Verfügbar

Ausfälle von Cloud-Anbietern sind nur eine Quelle für Ausfallzeiten. Die Hochverfügbarkeit hängt auch von Prozessen und Abläufen ab, die dazu beitragen, dass Fehler weniger wahrscheinlich sind. In der folgenden Tabelle werden alle Entscheidungen im Blueprint beschrieben, die sich auf die Hochverfügbarkeit beziehen, sowie die Gründe für diese Entscheidungen.

Blueprint-Entscheidung Auswirkungen auf die Verfügbarkeit

Änderungsmanagement

Verwenden Sie GitOps und IaC.

Unterstützt die Überprüfung von Änderungen durch Kollegen und das schnelle Zurücksetzen auf frühere Konfigurationen.

Änderungen schrittweise in den verschiedenen Umgebungen übernehmen

Die Auswirkungen von Software- und Konfigurationsfehlern werden reduziert.

Nicht-Produktions- und Produktionsumgebungen ähnlich machen.

So wird sichergestellt, dass Unterschiede die Erkennung eines Fehlers nicht verzögern. Beide Umgebungen sind dual-regional.

Ändern Sie replizierte Ressourcen in einer Umgebung jeweils in einer Region.

So wird sichergestellt, dass Probleme, die nicht durch die schrittweise Promotion erkannt werden, nur die Hälfte der Laufzeitinfrastruktur betreffen.

Ändern Sie jeweils nur einen Dienst in einer Region innerhalb einer Umgebung.

Sorgt dafür, dass Probleme, die nicht durch die schrittweise Promotion erkannt werden, nur die Hälfte der Dienst-Replikate betreffen.

Replizierte Computing-Infrastruktur

Verwenden Sie eine regionale Cluster-Steuerungsebene.

Die regionale Steuerungsebene ist während des Upgrades und der Größenanpassung verfügbar.

Erstellen Sie einen Mehrzonenknotenpool.

Ein Knotenpool eines Clusters hat mindestens drei Knoten, die auf drei Zonen verteilt sind.

Konfigurieren Sie ein freigegebene VPC-Netzwerk.

Das freigegebene VPC-Netzwerk umfasst zwei Regionen. Ein regionaler Ausfall wirkt sich nur auf den Netzwerk-Traffic zu und von Ressourcen in der ausgefallenen Region aus.

Image-Registry replizieren

Images werden in Artifact Registry gespeichert, die für die Replikation in mehreren Regionen konfiguriert ist. So wird verhindert, dass ein Ausfall einer Cloud-Region das Hochskalieren von Anwendungen in der verbleibenden Region verhindert.

Replizierte Dienste

Stellen Sie Dienstreplikate in zwei Regionen bereit.

Bei einem regionalen Ausfall bleibt ein Kubernetes-Dienst in der Produktions- und Nicht-Produktionsumgebung verfügbar.

Verwenden Sie Rolling Updates für Dienständerungen in einer Region.

Sie können Kubernetes-Dienste mit einem Rolling Update-Bereitstellungsmuster aktualisieren, um das Risiko und die Ausfallzeiten zu reduzieren.

Konfigurieren Sie für jeden Dienst drei Replikate in einer Region.

Ein Kubernetes-Dienst hat mindestens drei Replikate (Pods), um Rolling Updates in der Produktions- und Nichtproduktionsumgebung zu unterstützen.

Verteilen Sie die Pods der Bereitstellung auf mehrere Zonen.

Kubernetes-Dienste werden mithilfe einer Anti-Affinity-Anweisung auf VMs in verschiedenen Zonen verteilt. Eine Störung eines einzelnen Knotens oder ein vollständiger Zonenausfall kann toleriert werden, ohne dass zusätzlicher regionsübergreifender Traffic zwischen abhängigen Diensten anfällt.

Replizierter Speicher

Datenbankinstanzen mit mehreren Zonen bereitstellen

AlloyDB for PostgreSQL bietet Hochverfügbarkeit in einer Region. Die redundanten Knoten der primären Instanz befinden sich in zwei verschiedenen Zonen der Region. Die primäre Instanz behält die regionale Verfügbarkeit bei, indem sie einen automatischen Failover zur Standby-Zone auslöst, wenn in der aktiven Zone ein Problem auftritt. Regionaler Speicher trägt dazu bei, die Langlebigkeit von Daten zu gewährleisten, sollte es in einer einzelnen Zone zu einem Ausfall kommen.

Datenbanken regionsübergreifend replizieren.

AlloyDB for PostgreSQL verwendet die regionenübergreifende Replikation, um Funktionen zur Notfallwiederherstellung zu bieten. Die Datenbank repliziert die Daten Ihres primären Clusters asynchron in sekundäre Cluster, die sich in separatenGoogle Cloud -Regionen befinden.

Vorgänge

Stellen Sie Anwendungen für die doppelte erwartete Last bereit.

Wenn ein Cluster ausfällt (z. B. aufgrund eines regionalen Dienstausfalls), kann der Teil des Dienstes, der im verbleibenden Cluster ausgeführt wird, die Last vollständig aufnehmen.

Knoten automatisch reparieren

Die Cluster sind mit automatischer Knotenreparatur konfiguriert. Wenn die aufeinanderfolgenden Systemdiagnosen eines Knotens über einen längeren Zeitraum wiederholt fehlschlagen, initiiert GKE einen Reparaturprozess für diesen Knoten.

Sorgen Sie dafür, dass Knotenpool-Upgrades anwendungsbezogen sind.

In Deployments wird mit maxUnavailable: 1 ein Budget für Pod-Störungen definiert, um parallele Knotenpool-Upgrades in großen Clustern zu ermöglichen. Während Knotenpool-Upgrades ist jeweils nur eines von drei Replikaten (in der Entwicklungsumgebung) oder eines von sechs Replikaten (in Nicht-Produktions- und Produktionsumgebungen) nicht verfügbar.

Blockierte Dienste automatisch neu starten.

Die Bereitstellung, die einem Dienst zugrunde liegt, definiert einen Liveness-Probe, der Prozesse identifiziert und neu startet, die sich in einer Deadlock-Situation befinden.

Automatisch prüfen, ob Replikate bereit sind.

Die Bereitstellung, die einem Dienst zugrunde liegt, definiert eine Bereitschaftsprüfung, die angibt, wann eine Anwendung nach dem Start bereit ist, Anfragen zu verarbeiten. Mit einer Bereitschaftsprüfung sind keine manuellen Prüfungen oder Wartezeiten während Rolling Updates und Knotenpool-Upgrades erforderlich.

Die Referenzarchitektur ist für Anwendungen mit zonalen und regionalen Anforderungen an hohe Verfügbarkeit konzipiert. Hochverfügbarkeit verursacht einige Kosten, z. B. Kosten für Standby-Ersatz oder regionsübergreifende Replikation. Im Abschnitt Alternativen werden einige Möglichkeiten zur Senkung dieser Kosten beschrieben.

Plattformkontingente, Leistungsgrenzen und Skalierungsgrenzen

Sie können Kontingente, Leistung und Skalierung von Ressourcen auf der Entwicklerplattform steuern. In der folgenden Liste werden einige Punkte beschrieben, die Sie berücksichtigen sollten:

  • Für die Basisinfrastruktur sind zahlreiche Projekte erforderlich und für jeden zusätzlichen Mandanten vier Projekte. Möglicherweise müssen Sie zusätzliches Projektkontingent anfordern, bevor Sie die Bereitstellung vornehmen und weitere Mandanten hinzufügen.
  • Für jedes Projekt gilt ein Limit von 100 MultiClusterGateway-Ressourcen. Für jeden internetorientierten Kubernetes-Dienst auf der Entwicklerplattform ist ein MultiClusterGateway erforderlich.
  • Cloud Logging hat ein Limit von 100 Buckets pro Projekt. Der mandantenspezifische Logzugriff im Blueprint basiert auf einem Bucket für jeden Mandanten.
  • Wenn Sie mehr als 20 Mandanten erstellen möchten, können Sie eine Erhöhung des Projektkontingents für Scope- und Scope-Namespace-Ressourcen anfordern. Eine Anleitung zum Aufrufen von Kontingenten finden Sie unter Kontingente aufrufen und verwalten. Verwenden Sie einen Filter, um die Kontingenttypen gkehub.googleapis.com/global-per-project-scopes und gkehub.googleapis.com/global-per-project-scope-namespaces zu finden.

Wie geht es weiter?

  • Mehr über die Architektur erfahren (nächstes Dokument in dieser Reihe).