Google Distributed Cloud unterstützt mehrere Bereitstellungsmodelle, um unterschiedliche Anforderungen an Verfügbarkeit, Isolation und Ressourcenbedarf zu erfüllen. Auf dieser Seite werden die Konzepte beschrieben, die alle Bereitstellungsmodelle gemeinsam verwenden, und es wird jedes Modell beschrieben.
Nutzercluster
Ein Nutzercluster ist ein Kubernetes-Cluster, auf dem Ihre containerisierten Arbeitslasten ausgeführt werden. Die Instanz besteht aus Knoten der Steuerungsebene und Worker-Knoten. Google Distributed Cloud unterstützt einen oder mehrere Nutzercluster. Nutzercluster müssen einen oder mehrere Worker-Knoten enthalten, mit denen Nutzerarbeitslasten ausgeführt werden.
Administratorcluster
Ein Administratorcluster ist ein Kubernetes-Cluster, der einen oder mehrere Nutzercluster verwaltet. Ihr Administratorcluster kann folgende Aufgaben ausführen:
- Nutzercluster erstellen
- Nutzercluster aktualisieren
- Nutzercluster aktualisieren
- Nutzercluster löschen
Zum Erstellen eines Nutzerclusters richtet Ihr Administratorcluster die Google Distributed Cloud-Komponenten auf der Steuerungsebene und den Worker-Knoten des Nutzerclusters ein. Ihr Administratorcluster hat nur Knoten der Steuerungsebene, da die Komponenten von Google Distributed Cloud auf den Knoten der Steuerungsebene ausgeführt werden.
Ihr Administratorcluster enthält die folgenden Arten von sensiblen Daten:
- SSH-Anmeldedaten: Wird für die Remote-Installation verwendet
- Google Cloud-Dienstkontoschlüssel: Werden für den Zugriff auf Features wie Container Registry verwendet
Beschränken Sie den Zugriff auf Ihren Administratorcluster, um sensible Daten zu schützen.
Hochverfügbarkeit
Sie können Administrator- oder Nutzercluster im Modus Hochverfügbarkeit (HA) ausführen. Für diesen Modus müssen drei oder mehr Knoten der Steuerungsebene (ungerade Zahl) in Ihrem Cluster ausgeführt werden. Wenn Sie einen Cluster im Nicht-Hochverfügbarkeitsmodus ausführen, benötigt Ihr Cluster nur einen Knoten der Steuerungsebene.
Verwenden Sie den Hochverfügbarkeitsmodus für Produktionsbereitstellungen, um einen Single Point of Failure zu vermeiden. Verwenden Sie den Modus ohne Hochverfügbarkeit für nicht geschäftskritische Umgebungen, z. B. eine Testumgebung, in der Sie den Cluster neu erstellen können, wenn der einzelne Knoten der Steuerungsebene ausfällt. Ein Hochverfügbarkeits-Nutzercluster muss zwei oder mehr Worker-Knoten haben, wenn ein Worker-Knoten ausfällt.
Wenn Sie Ihre Cluster aktualisieren, verringert eine Hochverfügbarkeitsbereitstellung auch das Risiko, dass der Cluster bei einem Fehler nicht mehr zugänglich ist.
Bereitstellungsmodelle
Google Distributed Cloud unterstützt die folgenden Bereitstellungsmodelle, um unterschiedliche Anforderungen zu erfüllen:
- Bereitstellung von Administrator- und Nutzerclustern
- Hybridcluster bereitstellen
- Standalone-Clusterbereitstellung
Bereitstellung von Administrator- und Nutzerclustern
Verwenden Sie dieses Bereitstellungsmodell, wenn Sie mehrere Cluster im selben Rechenzentrum haben, die Sie von einem zentralen Ort aus verwalten möchten, und für größere Bereitstellungen, die zwischen verschiedenen Teams oder zwischen Entwicklungs- und Produktionsarbeitslasten isoliert werden müssen.
Dieses Bereitstellungsmodell besteht aus den folgenden Clustern:
- Ein Administratorcluster: Der zentrale Verwaltungspunkt, der eine API zum Verwalten von Nutzerclustern bereitstellt. Ihr Administratorcluster führt nur Verwaltungskomponenten aus.
- Einen oder mehrere Nutzercluster: Enthält die Knoten der Steuerungsebene und die Worker-Knoten, auf denen Nutzerarbeitslasten ausgeführt werden.
Dieses Modell erfüllt folgende Anforderungen:
- Bietet eine zentrale Steuerungsebene und eine API zur Verwaltung der Lebenszyklen Ihrer Nutzercluster.
- Bietet Isolation zwischen verschiedenen Teams.
- Bietet Isolation zwischen Entwicklungs- und Produktionsarbeitslasten.
- Sie müssen keine SSH-Anmeldedaten und Dienstkontoschlüssel für Clusterinhaber freigeben.
- Sie können Ihre Bereitstellung in Ihre eigenen Steuerungsebenen integrieren
Footprint
Für die Bereitstellung eines Administrator- und Nutzerclusters sind die folgenden Knoten erforderlich:
Administratorcluster
- Ein Knoten der Steuerungsebene für Nicht-HA
- Drei oder mehr Knoten der Steuerungsebene für HA
Nutzercluster: Sie können HA für jeden Nutzercluster unabhängig konfigurieren.
Knoten der Steuerungsebene:
- Ein Knoten der Steuerungsebene für Nicht-HA
- Drei oder mehr Knoten der Steuerungsebene für HA
Worker-Knoten:
- Einen oder mehrere Worker-Knoten für Nicht-HA
- Mindestens zwei Worker-Knoten für HA
Bereitstellung von Hybridclustern
Dieses Bereitstellungsmodell ist eine spezialisierte Bereitstellung mit mehreren Clustern. Ein Hybridcluster ist ein Administratorcluster, der Nutzerarbeitslasten ausführen kann. In Ihrem Hybridcluster werden weiterhin zusätzliche Nutzercluster verwaltet.
Merkmale dieses Modells:
- Die Zuweisung einer Reihe von Maschinen zu einem Administratorcluster ist oft aufwendig, da Administratorcluster relativ wenige Ressourcen benötigen. Mit der Hybrid-Clusterbereitstellung können Sie ungenutzte Kapazität auf diesen Maschinen zurückgewinnen, da Sie damit Nutzerarbeitslasten im Administratorcluster ausführen können.
- Der Administratorcluster enthält sensible Daten wie SSH-Anmeldedaten (die vom Administratorcluster zum Verwalten von Nutzerclustern auf Remote-Maschinen verwendet werden) und Google Cloud-Dienstkontoschlüssel (die vom Administratorcluster für den Zugriff auf Google Cloud-Dienste wie Cloud Storage verwendet werden). In Hybridclusterbereitstellungen werden Nutzerarbeitslasten im Administratorcluster ausgeführt. Dadurch werden die sensiblen Daten des Administratorclusters möglicherweise für Nutzerarbeitslasten freigegeben.
Footprint
Für die Bereitstellung eines hybriden Clusters sind folgende Knoten erforderlich:
Hybrid-Cluster
Knoten der Steuerungsebene:
- Ein Knoten der Steuerungsebene für Nicht-HA
- Drei oder mehr Knoten der Steuerungsebene für HA
Worker-Knoten:
- Einen oder mehrere Worker-Knoten für Nicht-HA
- Mindestens zwei Worker-Knoten für HA und je nach Arbeitslasttyp
Nutzercluster: Sie können HA für jeden Nutzercluster unabhängig konfigurieren.
Knoten der Steuerungsebene:
- Ein Knoten der Steuerungsebene für Nicht-HA
- Drei oder mehr Knoten der Steuerungsebene für HA
Worker-Knoten:
- Einen oder mehrere Worker-Knoten für Nicht-HA
- Mindestens zwei Worker-Knoten für HA
Bereitstellung des eigenständigen Clusters
Dieses Bereitstellungsmodell hat einen einzelnen Cluster, der als Nutzercluster und als Administratorcluster dient.
Dieses Modell bietet folgende Vorteile:
- Es ist kein separater Administratorcluster erforderlich.
- Es unterstützt das Edge-Profil, das die Systemressourcenanforderungen erheblich reduziert und für Edge-Geräte mit hohen Ressourceneinschränkungen empfohlen wird.
Dieses Modell hat einige Sicherheits-Kompromisse, da Arbeitslasten in einem Cluster mit den folgenden sensiblen Daten ausgeführt werden:
- SSH-Anmeldedaten
- Google Cloud-Dienstkontoschlüssel
Verwenden Sie dieses Modell, wenn eine der folgenden Bedingungen erfüllt ist:
- Sie verwalten jeden Cluster unabhängig.
- Die Anzahl der Worker-Knoten ist gering.
- Sie unterstützen ein einzelnes Team.
- Sie führen einen einzigen Arbeitslasttyp aus.
Dieses Modell funktioniert in folgenden Situationen gut:
- Jeder Cluster wird unabhängig mit verschiedenen SSH-Schlüsseln und Google Cloud-Anmeldedaten verwaltet
- Cluster werden in netzwerk-partitionierten Partitionen wie denormalisierten Zonen (DMZs) ausgeführt.
- Cluster werden an Edge-Standorten ausgeführt.
Footprint
Für die Bereitstellung eines eigenständigen Clusters sind folgende Knoten erforderlich:
Knoten der Steuerungsebene:
- Ein Knoten der Steuerungsebene für Nicht-HA
- Drei oder mehr Knoten der Steuerungsebene für HA
Worker-Knoten:
- Einen oder mehrere Worker-Knoten für Nicht-HA
- Mindestens zwei Worker-Knoten für HA