In diesem Abschnitt werden die Steuerelemente beschrieben, die auf der Entwicklerplattform verwendet werden.
Plattformidentität, -rollen und -gruppen
Für den Zugriff auf Google Cloud-Dienste sind Google Cloud-Identitäten erforderlich. Der Blueprint verwendet Flotten-Workload Identity, um die Kubernetes-Dienstkonten, die als Identitäten für Pods verwendet werden, Google Cloud-Dienstkonten zuzuordnen, die den Zugriff auf Google Cloud-Dienste steuern. Zum Schutz vor umgebungsübergreifenden Eskalationen hat jede Umgebung einen separaten Identitätspool (als eine Reihe vertrauenswürdiger Identitätsanbieter bezeichnet) für ihre Workload Identity-Konten.
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. Dieses Team umfasst die folgenden Mitglieder:
- Entwicklerplattformentwickler: Diese Teammitglieder erweitern den Blueprint und binden ihn in vorhandene Systeme ein. Dieses Team erstellt auch neue Anwendungsvorlagen.
- Entwicklerplattformadministrator: Dieses Team ist für Folgendes verantwortlich:
- Die Erstellung neuer Mandantenteams genehmigen.
- Geplante und ungeplante Aufgaben ausführen, die mehrere Mandanten betreffen, darunter:
- Die Hochstufung von Anwendungen in die Nicht-Produktionsumgebung und die Produktionsumgebung genehmigen
- Koordinieren von Infrastrukturupdates
- Kapazitätspläne auf Plattformebene erstellen
Ein Mandant der Entwicklerplattform ist ein einzelnes Softwareentwicklungsteam, das für den Betrieb dieser Software verantwortlich ist. Das Mandantenteam besteht aus zwei Gruppen: Anwendungsentwicklern und Anwendungsoperatoren. Die Aufgaben der beiden Gruppen des Mandantenteams sind:
- Anwendungsentwickler: Dieses Team schreibt und behebt Anwendungscode. Sie werden manchmal auch als Softwareentwickler oder Full-Stack-Entwickler bezeichnet. Zu ihren Aufgaben zählen:
- Tests und Qualitätssicherung für eine Anwendungskomponente durchführen, wenn diese in der Entwicklungsumgebung bereitgestellt wird.
- Anwendungseigene Cloud-Ressourcen (z. B. Datenbanken und Storage-Buckets) in der Entwicklungsumgebung verwalten.
- Datenbank- oder Speicherschemas für die Verwendung durch Anwendungen entwerfen
- 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 als Dienstoperatoren, Systementwickler oder Systemadministratoren bezeichnet. Zu den Aufgaben zählen:
- Kapazitätsanforderungen auf Anwendungsebene planen
- Benachrichtigungsrichtlinien erstellen und Service Level Objectives (SLOs) für Dienste festlegen
- Diagnostizieren von Dienstproblemen mithilfe von Logs und Messwerten, die für diese Anwendung spezifisch sind.
- Als Reaktion auf Benachrichtigungen und Seiten, z. B. wenn ein Dienst seine SLOs nicht erfüllt.
- Mit einer Gruppe oder mehreren Gruppen von Anwendungsentwicklern arbeiten
- Bereitstellung neuer Versionen für die Produktion genehmigen
- Verwaltung der anwendungseigenen Cloud-Ressourcen in den Nicht-Produktionsumgebungen und Produktionsumgebungen (z. B. Sicherungen und Schemaaktualisierungen).
Organisationsstruktur der Plattform
Der Blueprint der Unternehmensanwendung verwendet die Organisationsstruktur, die vom Blueprint der Unternehmensgrundlage bereitgestellt wird. Das folgende Diagramm zeigt, wie sich die Blueprint-Projekte für die Unternehmensanwendung in die Struktur des Grundlagen-Blueprints einfügen.
Plattformprojekte
In der folgenden Tabelle werden die zusätzlichen Projekte beschrieben, die über die Projekte des Grundlagen-Blueprints hinausgehen, die der Anwendungs-Blueprint zum Bereitstellen von Ressourcen, Konfigurationen und Anwendungen benötigt.
| Ordner | Projekt | Beschreibung |
|---|---|---|
|
|
Enthält die mandantenfähige Infrastrukturpipeline zum Bereitstellen der Mandanteninfrastruktur. |
|
Enthält die Application Factory , mit der Einzelmandanten-Anwendungsarchitekturen und Continuous Integration- und Continuous Deployment-Pipelines (CI/CD) erstellt werden. Dieses Projekt enthält auch die Config Sync, die für die GKE-Clusterkonfiguration verwendet wird. |
|
|
Enthält die CI/CD-Pipelines der Anwendung, die sich in unabhängigen Projekten befinden, um die Trennung zwischen Entwicklungsteams zu ermöglichen. Für jede Anwendung gibt es eine Pipeline. |
|
|
|
Enthält die GKE-Cluster für die Entwicklerplattform und die Logik, mit der Cluster für die Flottenverwaltung registriert werden. |
( |
Enthält alle Einzelmandanten-Anwendungsdienste wie Datenbanken oder andere verwaltete Dienste, die von einem Anwendungsteam verwendet werden. |
Architektur des Plattformclusters
Der Blueprint stellt Anwendungen in drei Umgebungen bereit: 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 Kontrolle. Eine Flotte bietet eine Möglichkeit, Kubernetes-Cluster logisch zu gruppieren und zu normalisieren, und vereinfacht die Verwaltung der Infrastruktur.
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. Damit Sie die Flottenfunktionen nutzen können, verwendet der Blueprint das Konzept der Gleichheit über Namespace-Objekte, Dienste und Identität hinweg.
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 Blueprint-Bereitstellung 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 geben. Der Zugriff auf die GKE-Cluster wird durch eine 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.
Platform GKE Enterprise-Komponenten
Die Entwicklerplattform verwendet GKE Enterprise-Komponenten, mit denen Sie den Lebenszyklus Ihrer Anwendungen erstellen, bereitstellen und verwalten können. In der Blueprint-Bereitstellung werden folgende GKE Enterprise-Komponenten verwendet:
- GKE für die Containerverwaltung
- Policy Controller für die Richtlinienverwaltung und -erzwingung
- Anthos Service Mesh für die Dienstverwaltung
- Binärautorisierung für die Attestierung von Container-Images
- GKE Gateway Controller für den Multi-Cluster-Gateway-Controller für GKE-Cluster
Flottenmanagement für Plattformen
Mit Flotten können Sie mehrere GKE-Cluster einheitlich verwalten. Die Flottenteamverwaltung erleichtert Plattformadministratoren die Bereitstellung und Verwaltung von Infrastrukturressourcen für Mandanten von Entwicklerplattformen. Mandanten haben die Kontrolle über Ressourcen innerhalb ihres eigenen Namespace, einschließlich ihrer Anwendungen, Logs und Messwerte.
Um Teilmengen von Flottenressourcen auf Teambasis bereitzustellen, können Administratoren Teambereiche verwenden. Mit Teambereichen können Sie Teilmengen von Flottenressourcen für jedes Team definieren, wobei jeder Teambereich einem oder mehreren Clustern der Flottenmitglieder zugeordnet ist.
Flotten-Namespaces bieten die Kontrolle darüber, wer Zugriff auf bestimmte Namespaces in Ihrer Flotte hat. Die Anwendung verwendet zwei GKE-Cluster, die in einer Flotte mit drei Teambereichen bereitgestellt werden und jeder Bereich einen Flotten-Namespace hat.
Das folgende Diagramm zeigt die Flotten- und Bereichsressourcen, die Beispielclustern in einer Umgebung entsprechen, wie durch den Blueprint implementiert.
Plattformnetzwerk
Für Netzwerke werden GKE-Cluster in einer freigegebenen VPC bereitgestellt, die als Teil des Blueprints der Unternehmensgrundlage 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. AlloyDB for PostgreSQL-Instanzen erfordern außerdem separate IP-Adressbereiche.
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 der GKE-Clusterregion 2 der Anwendung stellt der Blueprint nur einen IP-Adressbereich bereit, obwohl für zwei GKE-Entwicklungscluster ein IP-Adressbereich zugewiesen ist.
| 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, finden Sie weitere Informationen unter IP-Adressverwaltung in GKE und GKE-IPv4-Adressplanung.
Plattform-DNS
Der Entwurf verwendet Cloud DNS für GKE, 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 in Clustern 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 lautet 1000. Diese Regeln sind erforderlich, da der Blueprint der Unternehmensgrundlage eine Standardregel zum Blockieren des Traffics in der freigegebenen VPC hat.
Plattformzugriff auf Google Cloud-Dienste
Da die Blueprint-Anwendungen private Cluster verwenden, bietet der private Google-Zugriff Zugriff auf Google Cloud-Dienste.
Plattform-Hochverfügbarkeit
Der Blueprint wurde so konzipiert, dass er sowohl zonalen als auch regionalen Ausfällen gegenüber resistent ist. Die für den Betrieb der Anwendungen erforderlichen Ressourcen werden auf zwei Regionen verteilt. Sie wählen die Regionen aus, in denen Sie den Blueprint bereitstellen möchten. Ressourcen, die sich nicht im kritischen Pfad für die Bereitstellung und Reaktion auf die Last befinden, sind nur eine einzelne Region oder global. In der folgenden Tabelle werden die Ressourcen und wo sie bereitgestellt werden.
Standort |
Region 1 |
Region 2 |
Global |
|---|---|---|---|
Umgebungen mit Ressourcen an diesem Speicherort |
|
|
|
Projekte mit Ressourcen an diesem Standort |
|
|
|
Ressourcentypen an diesem Standort |
|
|
|
In der folgenden Tabelle wird zusammengefasst, wie verschiedene Komponenten auf einen Ausfall einer Region oder eine Zone reagieren und wie Sie diese Auswirkungen minimieren können.
Fehlerbereich |
Auswirkungen auf externe Dienste |
Auswirkungen auf die Datenbank | Effekte erstellen und bereitstellen | Auswirkungen von Terraform-Pipelines |
|---|---|---|---|---|
Eine Zone von Region 1 |
Verfügbar |
Verfügbar Die Standby-Instanz wird ohne RPO aktiviert. |
Verfügbar; möglicherweise ist eine manuelle Änderung erforderlich. Möglicherweise müssen Sie jeden |
Verfügbar; möglicherweise ist eine manuelle Änderung erforderlich. Möglicherweise müssen Sie jeden |
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 jeden |
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 ist eine 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 der Ursachen für Ausfallzeiten. Hochverfügbarkeit hängt außerdem von Prozessen und Vorgängen ab, die die Fehlerwahrscheinlichkeit verringern. In der folgenden Tabelle werden alle Entscheidungen beschrieben, die im Blueprint getroffen wurden, die sich auf Hochverfügbarkeit beziehen, und die Gründe für diese Entscheidungen.
| Entwurfsentscheidung | Auswirkungen auf die Verfügbarkeit |
|---|---|
Änderungsmanagement |
|
GitOps und IaC verwenden |
Unterstützt die Prüfung von Änderungen durch Kollegen und das schnelle Wiederherstellen auf vorherige Konfigurationen. |
Änderungen schrittweise in Umgebungen hochstufen. |
Reduziert die Auswirkungen von Software- und Konfigurationsfehlern. |
Nicht-Produktions- und Produktionsumgebungen ähnlich machen. |
Stellt sicher, dass Unterschiede die Erkennung eines Fehlers nicht verzögern. Beide Umgebungen sind dualregional. |
Replizierte Ressourcen in einer Umgebung für eine Region nach der anderen ändern |
Sorgt dafür, dass Probleme, die nicht von der schrittweisen Hochstufung erkannt werden, sich nur auf die Hälfte der Laufzeitinfrastruktur auswirken. |
Einen Dienst nur in einer Region innerhalb einer Umgebung ändern |
Sorgt dafür, dass Probleme, die nicht durch die schrittweise Hochstufung erkannt werden, sich nur auf die Hälfte der Dienstreplikate auswirken. |
Replizierte Computing-Infrastruktur |
|
Regionale Cluster-Steuerungsebene verwenden. |
Die regionale Steuerungsebene ist während des Upgrades und der Größenänderung verfügbar. |
Einen Knotenpool mit mehreren Zonen erstellen. |
Ein Clusterknotenpool hat mindestens drei Knoten, die auf drei Zonen verteilt sind. |
Ein freigegebenes VPC-Netzwerk konfigurieren. |
Das freigegebene VPC-Netzwerk deckt zwei Regionen ab. Ein regionaler Ausfall wirkt sich nur auf den Netzwerk-Traffic zu und von Ressourcen in der ausgefallenen Region aus. |
Replizieren Sie die Image-Registry. |
Images werden in Artifact Registry gespeichert, die so konfiguriert ist, dass sie in mehrere Regionen repliziert wird, sodass ein Ausfall der Cloud-Region nicht 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 der Nicht-Produktionsumgebung verfügbar. |
Rolling Updates für Dienständerungen innerhalb einer Region verwenden |
Sie können Kubernetes-Dienste mit einem Rolling Update-Bereitstellungsmuster aktualisieren, das Risiken und Ausfallzeiten reduziert. |
Konfigurieren Sie für jeden Dienst drei Replikate in einer Region. |
Ein Kubernetes-Dienst verfügt über mindestens drei Replikate (Pods), um Rolling Updates in der Produktions- und Nicht-Produktionsumgebung zu unterstützen. |
Verteilen Sie die Pods des Deployments auf mehrere Zonen. |
Kubernetes-Dienste werden mithilfe einer Anti-Affinitäts-Stanza auf VMs in verschiedenen Zonen verteilt. Eine Unterbrechung eines einzelnen Knotens oder ein Ausfall einer Zone kann toleriert werden, ohne zusätzlichen regionenübergreifenden Traffic zwischen abhängigen Diensten zu verursachen. |
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 im Falle eines Ausfalls in einer einzelnen Zone zu gewährleisten. |
Datenbanken regionenübergreifend replizieren |
AlloyDB for PostgreSQL verwendet die regionenübergreifende Replikation, um Funktionen zur Notfallwiederherstellung bereitzustellen. Die Datenbank repliziert die Daten des primären Clusters asynchron in sekundäre Cluster, die sich in separaten Google 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 werden mit automatischer Knotenreparatur konfiguriert. Wenn die aufeinanderfolgenden Systemdiagnosen eines Knotens über einen längeren Zeitraum wiederholt fehlschlagen, initiiert GKE für diesen Knoten einen Reparaturprozess. |
Achten Sie darauf, dass Upgrades von Knotenpools anwendungsspezifisch sind. |
Deployments definieren ein Budget für Pod-Störungen mit |
Deadlocke Dienste automatisch neu starten. |
Die Bereitstellung, die einen Dienst unterstützt, definiert eine Aktivitätsprüfung, die blockierte Prozesse identifiziert und neu startet. |
Prüfen Sie automatisch, ob Replikate bereit sind. |
Die Bereitstellung, die einen Dienst unterstützt, definiert eine Bereitschaftsprüfung, die ermittelt, wann eine Anwendung nach dem Start zur Bereitstellung bereit ist. Mit einer Bereitschaftsprüfung sind keine manuellen Prüfungen oder Wartezeiten während Rolling Updates und Knotenpool-Upgrades erforderlich. |
Die Referenzarchitektur wurde für Anwendungen mit zonalen und regionalen Hochverfügbarkeitsanforderungen entwickelt. Das Sicherstellen einer hohen Verfügbarkeit verursacht einige Kosten (z. B. freie Standby-Kosten oder regionsübergreifende Replikationskosten). Im Abschnitt Alternativen werden einige Möglichkeiten zur Minderung dieser Kosten beschrieben.
Plattformkontingente, Leistungsgrenzen und Skalierungslimits
Sie können Kontingente, Leistung und Skalierung von Ressourcen auf der Entwicklerplattform steuern. In der folgenden Liste werden einige zu berücksichtigende Punkte beschrieben:
- Die Basisinfrastruktur erfordert zahlreiche Projekte und jeder zusätzliche Mandant benötigt vier Projekte. Möglicherweise müssen Sie vor der Bereitstellung und vor dem Hinzufügen weiterer Mandanten zusätzliche Projektkontingente anfordern.
- Für jedes Projekt gilt ein Limit von 100 MultiClusterGateway-Ressourcen. Jeder internetorientierte Kubernetes-Dienst auf der Entwicklerplattform erfordert ein MultiClusterGateway.
- Cloud Logging hat ein Limit von 100 Buckets in einem Projekt. Für den Logzugriff pro Mandant im Blueprint ist ein Bucket für jeden Mandanten erforderlich.
- Wenn Sie mehr als 20 Mandanten erstellen möchten, können Sie eine Erhöhung des Projektkontingents für Bereichs- und Bereichs-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-scopesundgkehub.googleapis.com/global-per-project-scope-namespaceszu finden.
Wie geht es weiter?
- Mehr über die Architektur erfahren (nächstes Dokument in dieser Reihe).