Arbeitslasten bereitstellen

Arbeitslastoperator

Ein Arbeitslastoperator kann Optionen an eine Confidential Space-Arbeitslast-VM-Instanz übergeben, um ihr Verhalten vor der Ausführung zu bestimmen. Einige Flags haben erforderliche Werte, die sich nicht ändern. Sie müssen jedoch die folgenden Optionen auswählen:

• Ob die VM-Instanz auf einem Confidential Space-Produktions- oder Debugging-Image basieren soll.

• Ob AMD SEV, Intel TDX oder Intel TDX mit NVIDIA Confidential Computing verwendet werden soll, um die Vertraulichkeit Ihrer Arbeitslastdaten zu gewährleisten.

• Welche VM-Metadatenvariablen übergeben werden müssen, einschließlich Details wie dem auszuführenden Arbeitslast-Container-Image, dem zu verwendenden Attestierungsdienst, ob in Cloud Logging protokolliert werden soll und welche Umgebungsvariablen festgelegt werden sollen.

• Welches Dienstkonto an die VM angehängt werden soll, um die Arbeitslast auszuführen, und welche Berechtigungen es benötigt, um auf vertrauliche Daten in anderen Projekten zuzugreifen und die Ergebnisse an einen bestimmten Ort zu schreiben.

• In welcher Zone die VM-Instanz ausgeführt werden soll.

Im folgenden Beispiel wird eine Confidential VM erstellt und ein Docker-Container mit dem Namen WORKLOAD_CONTAINER_NAME ausgeführt:

CPU-basierte Arbeitslasten

gcloud compute instances create INSTANCE_NAME \
    --confidential-compute-type=CONFIDENTIAL_COMPUTING_TECHNOLOGY \
    --machine-type=MACHINE_TYPE_NAME \
    --maintenance-policy=MAINTENANCE_POLICY \
    --shielded-secure-boot \
    --image-project=confidential-space-images \
    --image-family=IMAGE_FAMILY \
    --metadata="^~^tee-image-reference=us-docker.pkg.dev/WORKLOAD_AUTHOR_PROJECT_ID/REPOSITORY_NAME/WORKLOAD_CONTAINER_NAME:latest" \
    --service-account=WORKLOAD_SERVICE_ACCOUNT_NAME@WORKLOAD_OPERATOR_PROJECT_ID.iam.gserviceaccount.com \
    --scopes=cloud-platform \
    --zone=ZONE_NAME \
    --project=PROJECT_ID

Geben Sie folgende Werte an:

• INSTANCE_NAME: Der Name der neuen VM-Instanz.

• CONFIDENTIAL_COMPUTING_TECHNOLOGY: Der zu verwendende Typ der Confidential Computing-Technologie. Wählen Sie einen der folgenden Werte aus:

  • SEV

  • TDX

• MACHINE_TYPE_NAME: Der VM-Maschinentyp, z. B. n2d-standard-2. Die gültigen Maschinentypen für Confidential VM-Instanzen werden durch die von Ihnen ausgewählte Confidential Computing-Technologie bestimmt, entweder AMD SEV oder Intel TDX. Siehe Maschinentypen.

• MAINTENANCE_POLICY: Legen Sie für N2D-Maschinentypen, die SEV verwenden, diesen Wert auf MIGRATE fest, um die Live-Migration zu unterstützen. Legen Sie diesen Wert für alle anderen Maschinentypen auf TERMINATE fest, da sie keine Live-Migration unterstützen.

• IMAGE_FAMILY_NAME: Die Familie für die Confidential Space-Images. Wählen Sie eine der folgenden Optionen aus:

  • confidential-space für Produktionsarbeitslasten

  • confidential-space-debug für Debug-Arbeitslasten

• Zusätzliche Metadatenvariablen, die das Verhalten der VM ändern, einschließlich des zu verwendenden Attestierungsdienstes.

• WORKLOAD_AUTHOR_PROJECT: Die ID des Projekts, in dem das Artifact Registry-Repository gehostet wird, in dem der Arbeitslastcontainer gespeichert ist.

• REPOSITORY_NAME: Der Name des Artifact Registry-Repositorys, in dem der Arbeitslastcontainer gespeichert ist.

• WORKLOAD_CONTAINER_NAME: Der Name des Arbeitslastcontainers.

• WORKLOAD_SERVICE_ACCOUNT_NAME: Der Name des Dienstkontos, das die Arbeitslast ausführt.

• WORKLOAD_OPERATOR_PROJECT_ID: Die ID des Projekts, in dem die Arbeitslast ausgeführt wird.

• ZONE_NAME: Die Zone, in der die VM-Instanz ausgeführt wird, z. B. us-west1-b. Confidential Space erfordert die folgenden Dienste, die an bestimmten Standorten verfügbar sind:

  • Confidential VM, basierend auf der verwendeten Confidential Computing-Technologie

  • Certificate Authority Service

• PROJECT_ID: Optional. Die ID des Projekts, in dem die VM-Instanz erstellt werden soll.

GPU-basierte Arbeitslasten

Hinweis

• Confidential Space unterstützt NVIDIA Confidential Computing nur auf H100-GPUs.

• Prüfen Sie Ihr GPU-Kontingent, damit Ihr Kontingent für die angeforderten Ressourcen ausreicht. Fordern Sie für Confidential VM-Instanzen mit GPUs ein GPU-Kontingent auf Abruf an, um die Ressourcen zu verwenden. Wenn Sie ein GPU-Kontingent anfordern, müssen Sie ein Kontingent für die GPU-Modelle, die Sie in den einzelnen Regionen erstellen möchten, sowie ein zusätzliches globales Kontingent (GPUs (all regions)) für die Gesamtzahl der GPUs aller Typen in allen Regionen anfordern.

• Informationen zum Kontingentverbrauch finden Sie unter GPU-VMs und Zuteilungskontingente auf Abruf.

• Lesen Sie die Einschränkungen für das Erstellen einer Anfrage zur Größenanpassung in einer MIG.

• Wenn Sie die für NVIDIA Confidential Computing erforderlichen Treiber installieren möchten, müssen Sie die Metadatenvariable tee-install-gpu-driver mit dem Wert true übergeben.

• Für NVIDIA-Treiber und das CUDA-Toolkit wird ein VM-Bootlaufwerk mit mindestens 30 GB Speicherplatz empfohlen.

• Zur Verwendung von CUDA-Anwendungen müssen NVIDIA CUDA-X-Bibliotheken in dem von Ihnen verwendeten Container-Image verfügbar sein. Führen Sie einen der folgenden Schritte aus, um die Bibliotheken einzubinden:

  • Verwenden Sie ein Container-Image mit vorinstallierten NVIDIA CUDA-X-Bibliotheken. Sie können beispielsweise die Deep Learning Container von Google für vorinstallierte Data-Science-Frameworks, NVIDIA CUDA-X-Bibliotheken und zusätzliche Tools verwenden. Alternativ können Sie das CUDA-Container-Image von NVIDIA nur für die NVIDIA CUDA-X-Bibliotheken verwenden.

  • Erstellen und verwenden Sie ein eigenes Container-Image. Legen Sie die Umgebungsvariable LD_LIBRARY_PATH auf /usr/local/nvidia/lib64 fest. Diese muss die NVIDIA CUDA-X-Bibliotheken und ‑Gerätetreiber enthalten.

Bekannte Probleme

• Wenn Sie eine Confidential Space-Arbeitslast mit einer angehängten NVIDIA H100-GPU ausführen, wird möglicherweise die folgende Fehlermeldung angezeigt:

  failed to get launchspec, make sure you're running inside
  a GCE VM: GPU Driver installation is not supported.
  

  Dies ist ein bekanntes Problem mit dem Confidential Space-Image. Starten Sie die Confidential VM neu, um das Problem zu umgehen.

GPU-basierte Arbeitslast bereitstellen

Wenn Sie eine GPU-basierte Arbeitslast bereitstellen möchten, müssen Sie eine Confidential VM-Instanz mit dem Bereitstellungsmodell Spot oder Flex-Start erstellen.

Spot

Wenn Sie das Spot-Bereitstellungsmodell verwenden möchten, erstellen Sie eine beschleunigeroptimierte VM-Instanz.

gcloud compute instances create INSTANCE_NAME \
    --provisioning-model=SPOT \
    --confidential-compute-type=TDX \
    --machine-type=a3-highgpu-1g \
    --maintenance-policy=TERMINATE \
    --shielded-secure-boot \
    --image-project=confidential-space-images \
    --image-family=IMAGE_FAMILY_NAME \
    --metadata="^~^tee-image-reference=us-docker.pkg.dev/WORKLOAD_AUTHOR_PROJECT_ID/REPOSITORY_NAME/WORKLOAD_CONTAINER_NAME:latest~tee-install-gpu-driver=true" \
    --service-account=WORKLOAD_SERVICE_ACCOUNT_NAME@WORKLOAD_OPERATOR_PROJECT_ID.iam.gserviceaccount.com \
    --scopes=cloud-platform \
    --boot-disk-size=30G \
    --zone=ZONE_NAME \
    --project=PROJECT_ID

Geben Sie folgende Werte an:

• INSTANCE_NAME: Der Name der neuen VM-Instanz.

• IMAGE_FAMILY_NAME: Die Familie für die Confidential Space-Images. Wählen Sie eine der folgenden Optionen aus:

  • confidential-space für Produktionsarbeitslasten

  • confidential-space-debug für Debug-Arbeitslasten

• Zusätzliche Metadatenvariablen, die das Verhalten der VM ändern, einschließlich des zu verwendenden Attestierungsdienstes.

• WORKLOAD_AUTHOR_PROJECT: Die Projekt-ID, in der die Arbeitslast ausgeführt wird.

• REPOSITORY_NAME: Der Name des Artifact Registry-Repositorys.

• WORKLOAD_CONTAINER_NAME: Der Name des Arbeitslastcontainers.

• WORKLOAD_SERVICE_ACCOUNT_NAME: Der Name des Dienstkontos, das die Arbeitslast ausführt.

• WORKLOAD_OPERATOR_PROJECT_ID: Die ID des Projekts, in dem die Arbeitslast ausgeführt wird.

• ZONE_NAME: Eine der Zonen, die NVIDIA Confidential Computing unterstützen.

• PROJECT_ID: Optional. Die ID des Projekts, in dem die VM-Instanz erstellt werden soll.

Flex-Start

Wenn Sie das Bereitstellungsmodell „Flex-Start“ verwenden möchten, erstellen Sie eine Instanzvorlage und dann eine verwaltete Instanzgruppe (MIG).

1. Instanzvorlage erstellen:

   gcloud beta compute instance-templates create INSTANCE_TEMPLATE_NAME \
       --provisioning-model=FLEX_START \
       --confidential-compute-type=TDX \
       --machine-type=a3-highgpu-1g \
       --maintenance-policy=TERMINATE \
       --shielded-secure-boot \
       --image-project=confidential-space-images \
       --image-family=IMAGE_FAMILY_NAME \
       --metadata="^~^tee-image-reference=us-docker.pkg.dev/WORKLOAD_AUTHOR_PROJECT_ID/REPOSITORY_NAME/WORKLOAD_CONTAINER_NAME:latest~tee-install-gpu-driver=true" \
       --service-account=WORKLOAD_SERVICE_ACCOUNT_NAME@WORKLOAD_OPERATOR_PROJECT_ID.iam.gserviceaccount.com \
       --scopes=cloud-platform \
       --boot-disk-size=30G \
       --max-run-duration=RUN_DURATION \
       --instance-termination-action=DELETE \
       --project=PROJECT_ID
   

   Geben Sie folgende Werte an:

   • INSTANCE_TEMPLATE_NAME: Der Name der neuen VM-Instanzvorlage.

   • IMAGE_FAMILY_NAME: Die Familie für die Confidential Space-Images. Wählen Sie eine der folgenden Optionen aus:

     • confidential-space für Produktionsarbeitslasten

     • confidential-space-debug für Debug-Arbeitslasten

   • WORKLOAD_AUTHOR_PROJECT: Die Projekt-ID, in der die Arbeitslast ausgeführt wird.

   • REPOSITORY_NAME: Der Name des Artifact Registry-Repositorys.

   • WORKLOAD_CONTAINER_NAME: Der Name des Arbeitslastcontainers.

   • WORKLOAD_SERVICE_ACCOUNT_NAME: Der Name des Dienstkontos, das die Arbeitslast ausführt.

   • WORKLOAD_OPERATOR_PROJECT_ID: Die ID des Projekts, in dem die Arbeitslast ausgeführt wird.

   • RUN_DURATION: die Dauer, für die die angeforderten VM-Instanzen ausgeführt werden sollen. Sie müssen den Wert als Anzahl von Tagen, Stunden, Minuten oder Sekunden gefolgt von d, h, m bzw. s formatieren. Geben Sie beispielsweise 30m für 30 Minuten oder 1d2h3m4s für einen Tag, zwei Stunden, drei Minuten und vier Sekunden an. Der Wert muss zwischen 10 Minuten und 7 Tagen liegen.

   • PROJECT_ID: Optional. Die ID des Projekts, in dem die VM-Instanzen erstellt werden sollen.

2. Erstellen Sie eine zonale MIG mit dem Befehl instance-groups managed create:

   gcloud compute instance-groups managed create INSTANCE_GROUP_NAME \
       --template=INSTANCE_TEMPLATE_NAME \
       --size=0 \
       --zone=ZONE_NAME \
       --default-action-on-vm-failure=do_nothing
   

   Geben Sie folgende Werte an:

   • INSTANCE_GROUP_NAME: Name der MIG.

   • INSTANCE_TEMPLATE_NAME: Der Name der Instanzvorlage für GPU-VMs.

   • ZONE_NAME: Eine der Zonen, die NVIDIA Confidential Computing unterstützen.

3. Erstellen Sie in der MIG eine Anfrage zur Größenanpassung. Geben Sie die gewünschte Anzahl von GPU-VM-Instanzen und die Dauer an, für die diese VM-Instanzen ausgeführt werden sollen.

   gcloud compute instance-groups managed resize-requests create INSTANCE_GROUP_NAME \
       --resize-request=RESIZE_REQUEST_NAME \
       --resize-by=COUNT \
       --zone=ZONE_NAME
   

   Geben Sie folgende Werte an:

   • INSTANCE_GROUP_NAME: Name der MIG.

   • INSTANCE_TEMPLATE_NAME: Der Name der Instanzvorlage für GPU-VM-Instanzen.

   • ZONE_NAME: Eine der Zonen, die NVIDIA Confidential Computing unterstützen.

   • RESIZE_REQUEST_NAME: Der Name der Anfrage zur Größenänderung.

   • COUNT: Die Anzahl der VM-Instanzen, die alle gleichzeitig in der Gruppe hinzugefügt werden sollen.

   Die von Ihnen erstellte Anfrage zur Größenanpassung bleibt im Status ACCEPTED, bis die MIG alle angeforderten GPU-VM-Instanzen erstellt hat. Nachdem alle GPU-VM-Instanzen in der Gruppe erstellt wurden, ändert sich der Status der Anfrage in SUCCEEDED.

4. Wenn genügend Ressourcen für die Anfrage zur Größenanpassung verfügbar sind, werden der MIG VM-Instanzen hinzugefügt und gestartet, um Ihre Arbeitslast auszuführen. Führen Sie den folgenden Befehl aus, um die Instanzen in der MIG aufzulisten:

   gcloud compute instance-groups managed list-instances INSTANCE_GROUP_NAME \
       --zone=ZONE_NAME \
       --project=PROJECT_ID
   

   Geben Sie folgende Werte an:

   • INSTANCE_GROUP_NAME: Name der MIG.

   • ZONE_NAME: Die unterstützte Zone, aus der eine Liste der VM-Instanzen abgerufen werden soll.

   • PROJECT_ID: Optional. Die ID des Projekts, von dem eine Liste der VM-Instanzen abgerufen werden soll.

Angehängtes Dienstkonto

Ein Dienstkonto muss an die Confidential VM einer Arbeitslast angehängt sein, damit die Arbeitslast ausgeführt werden kann. Das Dienstkonto muss so eingerichtet werden:

• Mit den folgenden Rollen:

  • roles/confidentialcomputing.workloadUser, um ein Attestierungstoken zu generieren.

  • roles/artifactregistry.reader, um ein in Artifact Registry gespeichertes Arbeitslast-Container-Image abzurufen.

  • roles/logging.logWriter, wenn Sie STDOUT und STDERR an Cloud Logging weiterleiten möchten.

• Mit Lesezugriff auf den Speicherort, an dem die Daten-Collaborators ihre vertraulichen Daten speichern, z. B. einen Cloud Storage-Bucket oder eine BigQuery-Tabelle.

• Mit Schreibzugriff auf den Speicherort, an den die Arbeitslast die Daten ausgibt, z. B. einen Cloud Storage-Bucket. Datenmitbearbeiter müssen Lesezugriff auf diesen Speicherort haben.

Außerdem müssen Datenmitbearbeiter und Arbeitslastoperatoren Folgendes einrichten:

• Wenn Datenmitarbeiter die Identitätsübernahme des Dienstkontos anstelle des direkten Ressourcenzugriffs verwenden, müssen sie das Dienstkonto als Attributbedingung zu ihrem Workload Identity-Poolanbieter hinzufügen:

  'WORKLOAD_SERVICE_ACCOUNT_NAME@DATA_COLLABORATOR_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts
  

• Der Arbeitslastoperator benötigt die Rolle roles/iam.serviceAccountUser, um die Identität des Dienstkontos zu übernehmen. So können sie es an eine Arbeitslast-VM-Instanz anhängen, damit die Arbeitslast ausgeführt werden kann.

Metadatenvariablen

Sie können das Verhalten der Confidential Space-Arbeitslast-VM ändern, indem Sie beim Erstellen der VM Variablen an die Option --metadata übergeben.

Wenn Sie mehrere Variablen übergeben möchten, legen Sie zuerst das Trennzeichen fest, indem Sie dem Wert --metadata das Präfix ^~^ voranstellen. Dadurch wird das Trennzeichen auf ~ gesetzt, da , in Variablenwerten verwendet wird.

Beispiel:

metadata="^~^tee-restart-policy=Always~tee-image-reference=us-docker.pkg.dev/WORKLOAD_AUTHOR_PROJECT_ID/REPOSITORY_NAME/WORKLOAD_CONTAINER_NAME:latest"

In der folgenden Tabelle sind die Metadatenvariablen aufgeführt, die Sie für Ihre Arbeitslast-VM festlegen können.

Hinweis: Einige Metadatenvariablen können von den Startrichtlinien beeinflusst werden, die von den Autoren der Arbeitslast festgelegt werden.

Metadatenschlüssel	Typ	Beschreibung und Werte
tee-image-reference Interagiert mit: Datenmitbearbeiter: Die Assertion container.image_reference.	String	Pflichtangabe. Dies verweist auf den Speicherort des Arbeitslastcontainers. Beispiel tee-image-reference=us-docker.pkg.dev/WORKLOAD_AUTHOR_PROJECT_ID/REPOSITORY_NAME/WORKLOAD_CONTAINER_NAME:latest
ita-api-key	String	Nur erforderlich, wenn Sie Intel Trust Authority als Attestierungsdienst verwenden. Legen Sie den Wert auf Ihren Intel Trust Authority API-Schlüssel fest. Informationen zum Erstellen eines Intel Trust Authority-API-Schlüssels finden Sie in der Dokumentation von Intel. Intel Trust Authority unterstützt Intel TDX-VM-Instanzen, die optional eine NVIDIA H100-GPU haben. Wenn die GPU vorhanden ist, wird auch ihr Nachweis geprüft. Beispiel ita-api-key=API_KEY
ita-region	String	Nur erforderlich, wenn Sie Intel Trust Authority als Attestierungsdienst verwenden. Legen Sie den Wert auf die Region fest, in der Intel Trust Authority ausgeführt werden soll. Gültige Regionen sind: US: https://api.trustauthority.intel.com Europa: https://api.eu.trustauthority.intel.com Intel Trust Authority unterstützt Intel TDX-VM-Instanzen, die optional eine NVIDIA H100-GPU haben. Wenn die GPU vorhanden ist, wird auch ihr Nachweis geprüft. Beispiel ita-region=REGION_NAME
tee-added-capabilities Interagiert mit: Arbeitslastautor: Die Startrichtlinie allow_capabilities.	JSON-String-Array	Fügt dem Arbeitslastcontainer zusätzliche Linux-Funktionen hinzu. Beispiel tee-added-capabilities="[\"CAP_SYS_ADMIN\", \"CAP_SYS_CHROOT\"]"
tee-cgroup-ns Interagiert mit: Arbeitslastautor: Die Startrichtlinie allow_cgroups.	Boolesch	Die Standardeinstellung ist false. Wenn dieser Wert auf true gesetzt ist, wird eine Namespace- cgroup-Bereitstellung unter /sys/fs/cgroup aktiviert. Beispiel tee-cgroup-ns=true
tee-cmd Interagiert mit: Arbeitslastautor: Die Startrichtlinie allow_cmd_override. Datenmitbearbeiter: Die Assertion container.cmd_override.	JSON-String-Array	Überschreibt die CMD-Anweisungen, die in der Dockerfile des Arbeitslastcontainers angegeben sind. Beispiel tee-cmd="[\"params1\", \"params2\"]"
tee-container-log-redirect Interagiert mit: Arbeitslastautor: Die Startrichtlinie log_redirect.	Aufzählung	Gibt STDOUT und STDERR aus dem Arbeitslastcontainer in Cloud Logging oder der seriellen Konsole aus, unter dem Feld confidential-space-launcher. Gültige Werte sind: false: (Standardeinstellung) Es erfolgt kein Logging. true: Ausgaben an die serielle Konsole und Cloud Logging. cloud_logging: Ausgabe nur in Cloud Logging. serial: Ausgabe nur an die serielle Konsole. Ein hohes Logvolumen in der seriellen Konsole kann die Arbeitslastleistung beeinträchtigen. Beispiel tee-container-log-redirect=true
tee-dev-shm-size-kb	Ganzzahl	Legt die Größe des gemeinsam genutzten Speicher-Mounts /dev/shm in kB fest. Beispiel tee-dev-shm-size-kb=65536
tee-env-ENVIRONMENT_VARIABLE_NAME Interagiert mit: Datenmitbearbeiter: Die Assertions container.env und container.env_override.	String	Legt Umgebungsvariablen im Arbeitslastcontainer fest. Der Ersteller der Arbeitslast muss die Namen der Umgebungsvariablen auch der Startrichtlinie allow_env_override hinzufügen, da sie sonst nicht festgelegt werden. Beispiel tee-env-example-env-1='value-1'~tee-env-example-env-2='value-2'
tee-impersonate-service-accounts Interagiert mit: Datenmitbearbeiter: Die Assertion google_service_accounts.	String	Eine Liste der Dienstkonten, deren Identität der Arbeitslastoperator übernehmen kann. Der Arbeitslastoperator muss die Identität der Dienstkonten übernehmen dürfen. Es können mehrere Dienstkonten durch Kommas getrennt aufgeführt werden. Beispiel tee-impersonate-service-accounts=SERVICE_ACCOUNT_NAME_1@WORKLOAD_OPERATOR_PROJECT_ID.iam.gserviceaccount.com,SERVICE_ACCOUNT_NAME_2@WORKLOAD_OPERATOR_PROJECT_ID.iam.gserviceaccount.com
tee-install-gpu-driver Interagiert mit: Datenmitbearbeiter: Die Assertions nvidia_gpu.cc_feature, nvidia_gpu.cc_mode und nvidia_gpu.gpus.	Boolesch	Gibt an, ob der Confidential Computing-GPU-Treiber von NVIDIA installiert werden soll. Erfordert einen Maschinentyp, der NVIDIA Confidential Computing unterstützt. Beispiel tee-install-gpu-driver=true
tee-monitoring-memory-enable Interagiert mit: Datenmitbearbeiter: Die Assertion instance_memory_monitoring_enabled. Arbeitslastautor: Die Startrichtlinie monitoring_memory_allow.	Boolesch	Die Standardeinstellung ist false. Wenn auf true gesetzt, wird das Monitoring der Speichernutzung aktiviert. Die von der Confidential VM erfassten Messwerte sind vom Typ guest/memory/bytes_used und können in Cloud Logging oder im Metrics Explorer aufgerufen werden. Beispiel tee-monitoring-memory-enable=true
tee-mount Interagiert mit: Arbeitslastautor: Die Startrichtlinie allow_mount_destinations.	String	Eine Liste von durch Semikolons getrennten Bereitstellungsdefinitionen. Eine Bereitstellungsdefinition besteht aus einer durch Kommas getrennten Liste von Schlüssel/Wert-Paaren, die type, source und destination erfordern. destination muss ein absoluter Pfad sein und type/source muss tmpfs sein. Beispiel type=tmpfs,source=tmpfs,destination=/tmp/tmpfs,size=12345;type=tmpfs,source=tmpfs,destination=/run/workload
tee-nonroot-container Interagiert mit: Arbeitslastautor: Die Startrichtlinie nonroot_container.	Boolesch	Die Standardeinstellung ist false. Wenn der Wert auf true festgelegt ist, wird der Container in einem isolierten Nutzer-Namespace als Nicht-Root-Nutzer auf der Host-VM ausgeführt. Diese Variable muss auf true festgelegt werden, wenn der Arbeitslastautor tee.launch_policy.nonroot_container auf nonrootonly festlegt. Hinweis: Wird ab Confidential Space-Image confidential-space-261001 unterstützt. Wenn dieser Schlüssel für frühere Images verwendet wird, hat er keine Auswirkungen und der Container wird als Root ausgeführt. Beispiel tee-nonroot-container=true
tee-restart-policy Interagiert mit: Datenmitbearbeiter: Die Assertion container.restart_policy.	Aufzählung	Die Neustart-Richtlinie des Container-Launchers, wenn die Arbeitslast beendet wird. Gültige Werte sind: Never (Standard) Always OnFailure Diese Variable wird nur vom Confidential Space-Produktions-Image unterstützt. Beispiel tee-restart-policy=OnFailure
tee-signed-image-repos Interagiert mit: Datenmitbearbeiter: Die Assertion container.image_signatures.	String	Eine Liste von kommagetrennten Container-Repositories, in denen die von Sigstore Cosign generierten Signaturen gespeichert werden. Beispiel tee-signed-image-repos=us-docker.pkg.dev/projectA/repo/example,us-docker.pkg.dev/projectB/repo/example,us-docker.pkg.dev/projectC/repo/example

Skalierung

Informationen zur Skalierung und Hochverfügbarkeit von Confidential Space-Produktionsarbeitslasten finden Sie unter Verwaltete Instanzgruppen.