Architektur von Cloud Workstations

Cloud Workstations verwaltet Google Cloud Ressourcen wie Compute Engine-VMs und persistent disks (PDs), damit Sie mehr Einblick in die Ressourcen Ihrer Projekte haben und sie besser steuern können. Sie können beispielsweise Richtlinien für geplante Festplattensnapshots einrichten, mit denen Sicherungsrichtlinien für alle Arbeitsstations-PDs erzwungen werden. Wenn Sie VMs in Ihrem Projekt haben, können Sie nahtlos auf Ressourcen in Ihrem VPC-Netzwerk zugreifen und diese verwalten.

Das folgende Diagramm veranschaulicht die Architektur von Cloud Workstations.

Architekturdiagramm

Abbildung 1. Cloud Workstations-Architektur

Workstationcluster

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

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

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

  • Gateway:Empfängt Traffic von Clients, der für bestimmte Arbeitsstationen bestimmt ist, und leitet ihn an die entsprechende VM-Instanz weiter. Jeder Workstation-Cluster hat einen eindeutigen Domainnamen und jede Workstation ist über eine Subdomain der Domain des Workstation-Clusters erreichbar, z. B. $WORKSTATION_ID.$CLUSTER_ID.cloudworkstations.dev.

Weitere Funktionen 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 dedizierten Controller, der über Private Service Connect mit einer VPC verbunden ist, in der sich Workstations befinden. Dies hat keine Auswirkungen auf die VPC-Peering-Limits. Dieser Controller verwaltet die Workstation-Ressourcen während ihres gesamten Lebenszyklus und bietet Netzwerk-Egress und ‑Ingress für die Workstations über ein öffentliches Cluster-Gateway.

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

  • Bei Bedarf kann auch ein vollständig privates Gateway aktiviert werden, sodass nur Endpunkte in Ihrem privaten Netzwerk Zugriff auf Cloud Workstations haben.

VPC-Netzwerk

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

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

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

    • VM-Gateway: Ruft Client-Traffic vom Gateway des Arbeitsstationsclusters ab, authentifiziert und autorisiert ihn und leitet ihn an den Container weiter.

    • Container: Definiert die auf einer Workstation vorinstallierten Tools, z. B. die IDE oder den Code-Editor, sowie alle anderen Programme oder Einstellungen, die in der Workstation-Konfiguration angegeben sind.

      Cloud Workstations bietet eine Reihe von Basis-Images, die mit beliebten 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 Cloud Workstations-Basis-Image 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 im Ordner /home bereitgestellt wird. So können Daten und Dateien nach dem Ende der Sitzung gespeichert werden.

Ressourcenlebenszyklus

Cloud Workstations verwaltet VMs, Container-Images und nichtflüchtige Speicher, 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. Ruft das Container-Image der Workstation auf die VM ab.
  3. Beim ersten Starten der Workstation wird ein nichtflüchtiger Speicher als /home-Verzeichnis der Workstation erstellt.
  4. Hängt den nichtflüchtigen Speicher 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, wird die VM von Cloud Workstations gelöscht, der nichtflüchtige Speicher wird jedoch getrennt und beibehalten, damit er in zukünftigen Workstation-Sitzungen verwendet werden kann. Der Workstations-Dienst behält das Laufwerk bei, bis die Workstation gelöscht wird. Dann wird auch der nichtflüchtige Speicher gelöscht, sofern er nicht optional für die Aufbewahrung konfiguriert ist.

Ressourcen-Pooling

Administratoren und Plattformteams können optional VMs und persistenten Speicherplatz für einen schnelleren Workstation-Start mit der Workstation-Konfigurationsoption pool size (Poolgröße) zusammenfassen. Wenn angegeben, werden die angegebene Anzahl von persistenten Laufwerken und VMs vom Dienst gepoolt und das Container-Image wird vor der Zuweisung der Arbeitsstation auf die VM vorab abgerufen. Nicht zugewiesene VMs und Laufwerke im Pool werden automatisch alle 12 Stunden gelöscht und neu erstellt. Dadurch kann die Workstation schneller gestartet werden, da die Wartezeit für das Erstellen von VMs und das Übertragen des Container-Images auf die VM entfällt.

Wenn das Pooling aktiviert ist, führt Cloud Workstations beim Starten einer Workstation die folgenden Schritte aus:

  1. Wählt eine VM aus dem Pool aus, auf der das Container-Image bereits abgerufen wurde.
  2. Beim ersten Start der Workstation wird eine nichtflüchtige Festplatte 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 hängt den nichtflüchtigen Speicher im Verzeichnis /home im Container-Image ein.
  5. Füllt den Pool wieder auf, indem eine neue VM und ein neuer nichtflüchtiger Speicher erstellt werden, um die zugewiesenen zu ersetzen.

Wenn die Sitzung endet, wird die VM von Cloud Workstations gelöscht, der nichtflüchtige Speicher wird jedoch getrennt und beibehalten, damit er in zukünftigen Workstation-Sitzungen verwendet werden kann. Der Workstations-Dienst behält das Laufwerk bei, bis die Workstation gelöscht wird. Dann wird auch der nichtflüchtige Speicher gelöscht, sofern er nicht optional für die Aufbewahrung konfiguriert ist.

Container-Image-Updates

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

Wenn Administratoren ein Pool-Aktualisierung erzwingen möchten, damit die Container-Image-Updates sofort übernommen werden, können sie pool_size auf 0 festlegen und dann wieder auf den bevorzugten pool_size-Wert zurücksetzen. Google Cloud Console: Deaktivieren Sie in der Workstationkonfiguration die Funktion Schnellstart-Workstations, speichern Sie die Konfiguration, stellen Sie sie wieder auf die bevorzugte Anzahl ein und speichern Sie sie noch einmal.

Alternativ können Administratoren und Plattformteams das Image-Tag im Feld container.image in der Workstation-Konfiguration aktualisieren. Dadurch wird ein Aktualisieren des Pools erzwungen, um das neue Container-Image-Tag zu übernehmen.

Startzeit von Workstations mit Image-Streaming verkürzen

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

Durch Image-Streaming in Cloud Workstations wird die Zeit für das Pullen von Container-Images in der Regel von Minuten auf Sekunden verkürzt. Workstation-Container werden normalerweise gestartet, ohne dass auf den Download des gesamten Images gewartet werden muss.

Voraussetzungen

Sie müssen die folgenden Anforderungen erfüllen, um Image-Streaming in Cloud Workstations zu verwenden:

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

    Container File System API aktivieren

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

    gcloud services enable containerfilesystem.googleapis.com

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

  • Sie müssen ein Dienstkonto für die Verwendung in Ihrer Workstation-Konfiguration angeben.

  • Wenn sich Ihr Cluster in einem VPC Service Controls-Perimeter befindet, müssen Sie eine Regel für ausgehenden Traffic hinzufügen, die Ihrem Dienstkonto den Zugriff auf die Container File System API im Projekt mit Ihrem Container-Image ermöglicht. Wenn Sie eine vorkonfigurierte IDE verwenden, müssen Sie das cloud-workstations-images-Projekt (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 für eine Workstation vom Image-Streaming.

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

Zeitüberschreitungen bei Inaktivität

Sie können Ihre Workstations so konfigurieren, dass sie nach einer bestimmten Inaktivitätszeit automatisch heruntergefahren werden. Das Leerlauftimeout wird bei jeder eingehenden Netzwerkanfrage und jedes Mal, wenn der API-Aufruf workstations.Start erfolgt, zurückgesetzt. Außerdem ist in den Basis-Workstation-Images, in denen die vorkonfigurierten IDEs installiert sind, ein Plug-in vorinstalliert, mit dem die Interaktion mit der IDE (Mausklick, Tastendruck usw.) erkannt und das Zeitlimit für Inaktivität zurückgesetzt wird.

Wenn Sie einen Hintergrundprozess mit langer Ausführungszeit starten und nicht mehr mit der Workstation interagieren, erreichen Sie möglicherweise den Grenzwert für das Zeitlimit bei Inaktivität. Dadurch wird die Workstation heruntergefahren. Wenn die Workstation aktiv bleiben muss, können Sie das /google/scripts/keep_alive.sh-Skript in den Basis-Workstation-Images verwenden, um Zeitüberschreitungen bei Inaktivität zu verhindern. Alternativ können Sie den workstation.Start-API-Aufruf im Hintergrundprozess auslösen, um das Herunterfahren im Leerlauf zu verhindern. Wenn Sie beispielsweise die Google Cloud CLI verwenden, können Sie dazu den Befehl gcloud workstations start ausführen.