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 Sie VMs in Ihrem können Sie nahtlos auf Ressourcen in Ihrem VPC-Netzwerk.

Das folgende Diagramm veranschaulicht 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 der VM Instanzen und andere Workstation-Ressourcen innerhalb Ihres Projekts.

    Die Controller nutzen die Compute Engine API, um den Lebenszyklus Ressourcen zu finden und Private Service Connect den Traffic an die Workstations weiterzuleiten, VMs

  • Gateway: empfängt Traffic von Clients, die für bestimmte und leitet den Traffic 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 Funktionen von Workstationclustern sind:

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

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

  • Jeder Workstation-Cluster hat einen eigenen Controller, der über Private Service Connect mit einem VPC verbunden ist, in dem sich die Workstations 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-Arbeitsstationen zugreifen können.

VPC-Netzwerk

Beim Erstellen eines Workstationclusters geben Sie ein Projekt und ein VPC-Netzwerk zum Hosten der Ressourcen. Cloud Workstations stellt dann die folgenden Ressourcen in Ihrem Projekt bereit:

  • Private Service Connect: stellt eine Verbindung zwischen dem Cloud Workstations-Controller und Ihre VPC, die Erstellung von Ressourcen innerhalb Ihres Projekts.

  • 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 das Cloud Workstations-Basis-Image erweitern können 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 Speicher zur Verwendung als Laufzeitumgebung für jede Workstation. Konfigurieren Sie die Spezifikationen für diese Ressourcen in Ihrer Workstation-Konfiguration.

Beim Start einer Workstation führt Cloud Workstations Folgendes aus:

  1. Erstellt eine VM.
  2. Das Workstation-Container-Image wird auf die VM gezogen.
  3. Beim ersten Start der Workstation wird ein nichtflüchtiger Speicher erstellt als Verzeichnis /home der Workstation.
  4. Der nichtflüchtige Speicher wird an die VM angehängt.
  5. Startet den Container auf der VM und stellt den nichtflüchtigen Speicher auf der /home-Verzeichnis im Container.

Wenn die Sitzung endet, löscht Cloud Workstations die VM, trennt aber die Verbindung und Der nichtflüchtige Speicher wird beibehalten, sodass er auf der zukünftigen Workstation verwendet werden kann. Sitzungen. Der Workstationdienst behält das Laufwerk bei, bis die Workstation gelöscht wird. Zu diesem Zeitpunkt wird auch der nichtflüchtige Speicher gelöscht – es sei denn, er ist optional beibehalten werden sollen.

Ressourcen-Pooling

Administratoren und Plattformteams können optional VMs und nichtflüchtige Speicher in einem Pool zusammenfassen. für einen schnelleren Start der Workstation pool size Workstation Konfigurationsoption. Wenn dieses Flag angegeben ist, erstellt der Dienst die angegebene Anzahl von nichtflüchtige Speicher und VMs erstellen und das Container-Image vorab auf die VM ziehen Workstation-Zuweisung. Nicht zugewiesene VMs und Laufwerke im Pool werden automatisch gelöscht und alle 12 Stunden 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. Der nichtflüchtige Speicher wird an die VM angehängt.
  4. Startet das Container-Image auf der VM und stellt den nichtflüchtigen Speicher auf dem Verzeichnis /home im Container-Image.
  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 aber die Verbindung und Der nichtflüchtige Speicher wird beibehalten, sodass er auf der zukünftigen Workstation verwendet werden kann. Sitzungen. Der Workstationdienst behält das Laufwerk bei, bis die Workstation gelöscht wird. Zu diesem Zeitpunkt wird auch der nichtflüchtige Speicher gelöscht – es sei denn, er ist optional beibehalten werden sollen.

Container-Image-Updates

Da das Container-Image der Workstation vorab auf die gemeinsamen VMs geladen wird, Aktualisierungen am Container-Image, die im Remote-Image-Repository vorgenommen wurden, mit denselben Image-Tags werden erst ausgewählt, wenn alle gemeinsamen VMs zugewiesen wurden oder werden nach 12 Stunden gelöscht. Dann werden neue VMs erstellt, um den Pool aufzufüllen. und rufen Sie das aktualisierte Container-Image ab.

Um eine Poolaktualisierung zu erzwingen, damit die Container-Image-Aktualisierungen 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 Image-Streaming, was eine schnellere Startzeit der Workstation durch Reduzierung der Abrufzeit des Workstation-Container-Images.

Image-Streaming in Cloud Workstations reduziert in der Regel das Abrufen von Container-Images von Minuten bis Sekunden und Workstationcontainer. in der Regel ausgeführt werden, ohne auf den Download des gesamten Images warten zu müssen.

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-Kommandozeilenbefehl ausführen, um Aktivieren Sie die Container File System API im Hostprojekt der Workstation:

    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 auf Ihrer Workstation angeben Konfiguration.

  • Wenn sich der Cluster in einem VPC Service Controls-Perimeter befindet, müssen Sie einen Ausgangsregel damit Ihr Dienstkonto auf die Container File System API zugreifen kann, das Projekt, das das Container-Image hostet. Wenn Sie eine vorkonfigurierten IDE haben, müssen Sie das Projekt cloud-workstations-images (Projektnummer 662288601415) auf die Zulassungsliste setzen.

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.