Architektur von Cloud Workstations

Cloud Workstations verwaltet Google Cloud-Ressourcen wie Compute Engine-VMs und Persistent Disks (PDs), damit Sie die Ressourcen Ihrer Projekte besser im Blick behalten und steuern können. Sie können beispielsweise Richtlinien für geplante Laufwerk-Snapshots einrichten, die Sicherungsrichtlinien für alle PDs von Workstations erzwingen. Wenn sich VMs in Ihrem Projekt befinden, können Sie auch nahtlos auf Ressourcen in Ihrem VPC-Netzwerk zugreifen und diese verwalten.

Das folgende Diagramm zeigt die Architektur von Cloud Workstations.

Architekturdiagramm

Abbildung 1. Architektur von Cloud Workstations

Workstationcluster

Ein Workstation-Cluster enthält und verwaltet eine Gruppe von Workstations in einer einzigen Cloud-Region und einem einzigen VPC-Netzwerk in Ihrem Projekt. Jeder Workstation-Cluster enthält zwei Komponenten, die von Google Cloud verwaltet werden: einen Controller und ein Gateway.

  • Controller: Verwaltet den Lebenszyklus von VM-Instanzen und anderen Workstation-Ressourcen in Ihrem Projekt.

    Die Controller verwenden die Compute Engine API, um den Lebenszyklus der Ressourcen zu verwalten, und Private Service Connect, um den Traffic an die VMs der Workstations weiterzuleiten.

  • Gateway: empfängt Traffic von Clients, der an bestimmte Workstations gerichtet ist, und leitet ihn an die entsprechende VM-Instanz weiter. Jeder Workstation-Cluster hat einen eindeutigen Domainnamen und jede Workstation kann über eine Subdomain der Domain des Workstation-Clusters erreicht werden, z. B. $WORKSTATION_ID.$CLUSTER_ID.cloudworkstations.dev.

Weitere Merkmale von Workstation-Clustern:

  • Administratoren und Plattformteams erstellen Workstation-Cluster, die eine Gruppe von Workstations in einer bestimmten Region und das VPC-Netzwerk definieren, mit dem sie verbunden sind.

  • Workstation-Cluster haben keinen Bezug zu Google Kubernetes Engine-Clustern (GKE).

  • Jeder Workstation-Cluster hat einen eigenen Controller, der mit einem VPC verbunden ist, in dem sich Workstations mit Private Service Connect befinden. Dies hat keine Auswirkungen auf die VPC-Peering-Limits. Dieser Controller verwaltet die Ressourcen der Workstations während ihres gesamten Lebenszyklus und stellt über ein öffentliches Cluster-Gateway Netzwerkzugriff für die Workstations bereit.

  • Für jede Cloud-Region ist mindestens ein Workstation-Cluster erforderlich.

  • Bei Bedarf können Sie auch ein vollständig privates Gateway aktivieren, damit nur Endpunkte innerhalb Ihres privaten Netzwerks auf Cloud Workstations zugreifen können.

VPC-Netzwerk

Wenn Sie einen Workstation-Cluster erstellen, geben Sie ein Projekt und ein VPC-Netzwerk an, in dem die Ressourcen gehostet werden sollen. Cloud Workstations stellt dann die folgenden Ressourcen in Ihrem Projekt bereit:

  • Private Service Connect: Hiermit wird eine Verbindung zwischen dem Cloud Workstations-Controller und Ihrem VPC hergestellt, sodass Ressourcen in Ihrem Projekt erstellt werden können.

  • VM-Instanz: Eine Compute Engine-VM wird dynamisch in Ihrem Projekt und VPC erstellt, nachdem eine Workstation gestartet wurde. Diese VM wird am Ende einer Nutzersitzung oder nach einem konfigurierbaren Zeitlimit für die Sitzung automatisch gelöscht.

    • VM-Gateway: Zieht Client-Traffic vom Workstation-Cluster-Gateway ab, authentifiziert und autorisiert ihn und leitet ihn an den Container weiter.

    • Container: Hier werden die auf einer Workstation vorinstallierten Tools wie die IDE oder der Code-Editor sowie alle anderen Programme oder Einstellungen definiert, die in der Workstation-Konfiguration angegeben sind.

      Cloud Workstations bietet eine Reihe von Basis-Images, die mit gängigen IDEs und Sprachtools vorkonfiguriert sind. Außerdem können Administratoren und Plattformteams ihre Umgebungen anpassen, indem sie benutzerdefinierte Container-Images erstellen und angeben, die die Tools enthalten, die für die Anforderungen ihrer Entwickler erforderlich sind. Diese Container-Images können das Basis-Image von Cloud Workstations erweitern oder neue, benutzerdefinierte Linux-Container-Images sein, die vom Plattformteam erstellt wurden.

  • Nichtflüchtiger Speicher: Ein nichtflüchtiger Speicher, der an die Workstation-VM angehängt und auf den Ordner /home bereitgestellt wird, sodass Daten und Dateien nach dem Ende der Sitzung gespeichert werden können.

Ressourcenlebenszyklus

Cloud Workstations verwaltet VMs, Container-Images und nichtflüchtige Laufwerke, die als Laufzeitumgebung für jede Workstation verwendet werden. Konfigurieren Sie die Spezifikationen für diese Ressourcen in Ihrer Workstation-Konfiguration.

Wenn eine Workstation gestartet wird, führt Cloud Workstations die folgenden Schritte aus:

  1. Erstellt eine VM.
  2. Das Workstation-Container-Image wird auf die VM gezogen.
  3. Beim ersten Starten der Workstation wird ein nichtflüchtiger Datenträger erstellt, der als /home-Verzeichnis der Workstation dient.
  4. Hängt das nichtflüchtige Laufwerk an die VM an.
  5. Startet den Container auf der VM und stellt den nichtflüchtigen Speicher im Verzeichnis /home im Container bereit.

Wenn die Sitzung endet, löscht Cloud Workstations die VM, trennt den nichtflüchtigen Speicher jedoch und behält ihn, damit er in zukünftigen Workstation-Sitzungen verwendet werden kann. Der Workstation-Dienst behält das Laufwerk so lange bei, bis die Workstation gelöscht wird. In diesem Fall wird auch der nichtflüchtige Speicher gelöscht, es sei denn, er wurde optional so konfiguriert, dass er beibehalten wird.

Ressourcen-Pooling

Administratoren und Plattformteams können VMs und persistente Laufwerke optional mit der Workstation-Konfigurationsoption Poolgröße für einen schnelleren Workstation-Start gruppieren. Wenn angegeben, fasst der Dienst die angegebene Anzahl von persistenten Laufwerken und VMs in einem Pool zusammen und ruft das Container-Image vor der Zuweisung an die Workstation auf der VM ab. Nicht zugewiesene VMs und Laufwerke im Pool werden alle 12 Stunden automatisch gelöscht und neu erstellt. Dadurch wird der Start der Workstation beschleunigt, da die Wartezeit für das Erstellen von VMs und das Abrufen des Container-Images auf die VM entfällt.

Wenn das Pooling aktiviert ist, geschieht beim Starten einer Workstation Folgendes:

  1. Wählt eine VM aus dem Pool aus, für die das Container-Image bereits zuvor abgerufen wurde.
  2. Beim ersten Start der Workstation wird ein nichtflüchtiger Datenträger aus dem Pool ausgewählt.
  3. Hängt den nichtflüchtigen Speicher an die VM an.
  4. Startet das Container-Image auf der VM und bindet den nichtflüchtigen Speicher an das Verzeichnis /home im Container-Image an.
  5. Der Pool wird wieder aufgefüllt, indem eine neue VM und ein neuer nichtflüchtiger Speicher erstellt werden, um die zugewiesenen zu ersetzen.

Wenn die Sitzung endet, löscht Cloud Workstations die VM, trennt den nichtflüchtigen Speicher jedoch und behält ihn, damit er in zukünftigen Workstation-Sitzungen verwendet werden kann. Der Workstation-Dienst behält das Laufwerk so lange bei, bis die Workstation gelöscht wird. In diesem Fall wird auch der nichtflüchtige Speicher gelöscht, es sei denn, er wurde optional so konfiguriert, dass er beibehalten wird.

Container-Image-Updates

Da das Workstation-Container-Image vorab auf die zusammengefassten VMs gezogen wird, werden Aktualisierungen des Container-Images, die im Remote-Image-Repository mit demselben Image-Tag vorgenommen wurden, erst nach 12 Stunden übernommen, wenn alle zusammengefassten VMs zugewiesen oder gelöscht wurden. In diesem Fall werden neue VMs erstellt, um den Pool aufzufüllen und das aktualisierte Container-Image abzurufen.

Um eine Poolaktualisierung zu erzwingen, damit die Container-Image-Updates sofort übernommen werden, können Administratoren die pool_size auf 0 setzen und dann wieder auf die gewünschte pool_size zurücksetzen. Deaktivieren Sie in der Google Cloud Console in der Workstation-Konfiguration die Funktion Workstations schnell starten, speichern Sie die Konfiguration, stellen Sie die gewünschte Anzahl wieder her und speichern Sie die Konfiguration noch einmal.

Alternativ können Administratoren und Plattformteams das Image-Tag im Feld container.image in der Workstation-Konfiguration aktualisieren. Dadurch wird der Pool aktualisiert, damit das neue Container-Image-Tag übernommen wird.

Startzeit von Workstations mit Image-Streaming verkürzen

Cloud Workstations unterstützt das Image-Streaming, wodurch die Startzeit der Workstation verkürzt wird, da die Pull-Zeit für das Workstation-Container-Image reduziert wird.

Durch das Image-Streaming in Cloud Workstations wird die Abrufzeit von Container-Images in der Regel von Minuten auf Sekunden reduziert. Workstation-Container werden in der Regel gestartet, ohne dass auf den Download des gesamten Images gewartet werden muss.

Voraussetzungen

Für die Verwendung von Image-Streaming in Cloud Workstations müssen folgende Voraussetzungen erfüllt sein:

  • Sie müssen die Container File System API im Hostprojekt für Workstations aktivieren.

    Container File System API aktivieren

    Alternativ können Sie den folgenden gcloud-Befehlszeilenbefehl ausführen, um die Container File System API im Workstation-Hostprojekt zu aktivieren:

    gcloud services enable containerfilesystem.googleapis.com
    

  • Ihre Container-Images müssen in Artifact Registry gespeichert sein.

  • Das Artifact Registry-Repository muss sich in derselben Region wie Ihre Cloud Workstations-Region befinden oder in einer Multi-Region, die der Region entspricht, in der Ihre Workstations ausgeführt werden.

  • Sie müssen ein Dienstkonto für die Verwendung in Ihrer Workstationkonfiguration angeben.

  • Wenn sich Ihr Cluster in einem VPC Service Controls-Perimeter befindet, müssen Sie eine Ausgangsregel hinzufügen, die Ihrem Dienstkonto Zugriff auf die Container File System API im Projekt gewährt, in dem Ihr Container-Image gehostet wird. Wenn Sie eine vorkonfigurierte IDE verwenden, müssen Sie das cloud-workstations-images-Projekt (Projektnummer 662288601415) zur Zulassungsliste hinzufügen.

Beschränkungen

  • Möglicherweise bemerken Sie die Vorteile des Image-Streamings beim ersten Abrufen eines zulässigen Images nicht. Aber nachdem das Image-Streaming das Image im Cache gespeichert hat, profitieren künftige Image-Abrufe auf einer Workstation vom Image-Streaming.

  • Es gelten weitere Einschränkungen für das GKE-Image-Streaming.