Architektur von Cloud Workstations

Cloud Workstations verwaltet Google Cloud-Ressourcen wie Compute Engine-VMs und nichtflüchtige Speicher (Persistent Disks, PDs) und bietet Ihnen so mehr Transparenz und Kontrolle über die Ressourcen Ihrer Projekte. Sie können beispielsweise Richtlinien für geplante Laufwerk-Snapshots einrichten, die Sicherungsrichtlinien für alle Workstation-PDs erzwingen. Mit VMs in Ihrem Projekt können Sie dagegen 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 Workstationcluster enthält und verwaltet eine Sammlung von Workstations in einer einzelnen Cloud-Region und einem VPC-Netzwerk innerhalb Ihres Projekts. Jeder Workstationcluster besteht aus 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 Traffic an die VMs der Workstations weiterzuleiten.

  • Gateway: empfängt Traffic von Clients, die an bestimmte Workstations gebunden sind, und leitet den Traffic an die entsprechende VM-Instanz weiter. Jeder Workstationcluster hat einen eindeutigen Domainnamen und jede Workstation kann in einer Subdomain der Domain des Workstationclusters erreicht werden, z. B. $WORKSTATION_ID.$CLUSTER_ID.cloudworkstations.dev.

Weitere Funktionen von Workstation-Clustern sind:

  • Administratoren und Plattformteams erstellen Workstationcluster, mit denen eine Gruppe von Workstations in einer bestimmten Region und in dem VPC-Netzwerk definiert wird, an das sie angehängt sind.

  • Workstationcluster sind nicht mit GKE-Clustern (Google Kubernetes Engine) verbunden.

  • Jeder Workstationcluster hat einen dedizierten Controller, der mit einer VPC verbunden ist, in der sich die Workstations mit Private Service Connect befinden. Dies hat keine Auswirkungen auf VPC-Peering-Limits. Dieser Controller verwaltet die Workstationressourcen während ihres gesamten Lebenszyklus und stellt den ausgehenden und eingehenden Netzwerktraffic zu den Workstations über ein öffentliches Clustergateway bereit.

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

  • Bei Bedarf können Sie auch ein vollständig privates Gateway aktivieren, sodass nur Endpunkte in Ihrem privaten Netzwerk Zugriff auf Cloud Workstations haben.

VPC-Netzwerk

Beim Erstellen eines Workstationclusters 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 Ihrer VPC her, sodass Sie Ressourcen in Ihrem Projekt erstellen können.

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

    • VM Gateway: ruft Clienttraffic vom Workstationclustergateway 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 Codeeditor) sowie alle anderen Programme oder Einstellungen, die in der Workstationkonfiguration angegeben werden.

      Cloud Workstations bietet eine Reihe von Basis-Images, die mit gängigen IDEs und Sprachtools vorkonfiguriert sind. Darüber hinaus 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 ist, die im Ordner /home bereitgestellt ist. Dadurch 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 der Workstation-Konfiguration.

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

  1. Erstellt eine VM.
  2. Das Workstation-Container-Image wird per Pull-Verfahren auf die VM übertragen.
  3. Beim ersten Start der Workstation wird ein nichtflüchtiger Speicher erstellt, der als Verzeichnis /home der Workstation dient.
  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, löscht Cloud Workstations die VM, trennt aber den nichtflüchtigen Speicher und behält ihn bei, damit er in zukünftigen Workstationsitzungen verwendet werden kann. Der Workstationdienst behält das Laufwerk bei, bis die Workstation gelöscht wird. Dann wird der nichtflüchtige Speicher ebenfalls gelöscht – es sei denn, er ist optional für die Aufbewahrung konfiguriert.

Ressourcen-Pooling

Administratoren und Plattformteams können mithilfe der Workstation-Konfigurationsoption für die Poolgröße optional VMs und nichtflüchtige Speicher gruppieren, um die Workstations schneller zu starten. Wenn dieses Flag angegeben ist, gruppiert der Dienst die angegebene Anzahl nichtflüchtiger Speicher und VMs und lädt das Container-Image vor der Zuweisung der Workstation auf die VM. Nicht zugewiesene VMs und Laufwerke im Pool werden automatisch alle 12 Stunden gelöscht und neu erstellt. Dies ermöglicht schnellere Startzeiten von Workstations, da die Wartezeit für das Erstellen von VMs und das Abrufen des Container-Images auf die VM entfällt.

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

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

Wenn die Sitzung endet, löscht Cloud Workstations die VM, trennt aber den nichtflüchtigen Speicher und behält ihn bei, damit er in zukünftigen Workstationsitzungen verwendet werden kann. Der Workstationdienst behält das Laufwerk bei, bis die Workstation gelöscht wird. Dann wird der nichtflüchtige Speicher ebenfalls gelöscht – es sei denn, er ist optional für die Aufbewahrung konfiguriert.

Updates für Container-Images

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

Wenn Sie erzwingen möchten, dass bei einer Poolaktualisierung die Container-Image-Updates sofort übernommen werden, können Administratoren pool_size auf 0 und dann wieder auf die bevorzugte pool_size setzen. Deaktivieren Sie in der Google Cloud Console das Feature Schnellstart-Workstations in der Workstationkonfiguration, speichern Sie die Konfiguration, setzen Sie sie auf die bevorzugte Nummer zurück und speichern Sie noch einmal.

Alternativ können Administratoren und Plattformteams das Image-Tag in der Workstationkonfiguration im Feld container.image aktualisieren. Dadurch wird eine Aktualisierung des Pools erzwungen, um das neue Container-Image-Tag abzurufen.

Workstationstartzeit mit Image-Streaming reduzieren

Cloud Workstations unterstützt Image-Streaming. Damit wird die Startzeit der Workstations verkürzt, da die Abrufzeit des Workstation-Container-Images verkürzt wird.

Image-Streaming in Cloud Workstations reduziert in der Regel die Abrufzeit von Container-Images von Minuten auf Sekunden und Workstation-Container werden normalerweise gestartet, ohne auf den Download des gesamten Images warten zu müssen.

Voraussetzungen

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

  • 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-Befehlszeilenbefehl 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.

  • Das Artifact Registry-Repository muss sich in derselben Region wie Ihre Cloud Workstations-Region oder an einem multiregionalen Standort befinden, der der Region entspricht, in der Ihre Workstations ausgeführt werden.

  • Sie müssen ein Dienstkonto zur Verwendung in Ihrer Workstationkonfiguration angeben.

  • Wenn sich Ihr Cluster innerhalb eines VPC Service Controls-Perimeters befindet, müssen Sie eine Regel für ausgehenden Traffic hinzufügen, damit Ihr Dienstkonto auf die Container File System API in dem Projekt zugreifen kann, in dem Ihr Container-Image gehostet wird. Wenn Sie eine vorkonfigurierte IDE verwenden, 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. Nachdem das Image durch Image-Streaming im Cache gespeichert wurde, profitieren künftige Image-Abrufe auf einer Workstation jedoch von Image-Streaming.

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