Metadatenvariablen für Arbeitslasten


Sie können das Verhalten der Confidential Space-VM für Arbeitslasten ä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 ~ festgelegt, 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.

Metadatenschlüssel Typ Beschreibung und Werte

tee-image-reference

Interagiert mit:

String

Erforderlich. Dieser verweist auf den Speicherort des Arbeitslastcontainers.

Beispiel
tee-image-reference=us-docker.pkg.dev/WORKLOAD_AUTHOR_PROJECT_ID/REPOSITORY_NAME/WORKLOAD_CONTAINER_NAME:latest

tee-cmd

Interagiert mit:

JSON-Strings-Array

Überschreibt die CMD-Anweisungen, die in der Dockerfile des Arbeitslastcontainers angegeben sind.

Beispiel
tee-cmd="[\"params1\", \"params2\"]"

tee-container-log-redirect

Interagiert mit:

Definierter String

Gibt STDOUT und STDERR aus dem Arbeitslastcontainer in Cloud Logging oder in der seriellen Konsole aus, unter dem Feld confidential-space-launcher.

Gültige Werte:

  • false: (Standard) Es erfolgt keine Protokollierung.
  • true: werden an die serielle Konsole und Cloud Logging ausgegeben.
  • cloud_logging: Ausgabe nur in Cloud Logging.
  • serial: Ausgabe nur an die serielle Konsole.

Ein hohes Protokollvolumen in der seriellen Konsole kann sich auf die Arbeitslastleistung auswirken.

Beispiel
tee-container-log-redirect=true

tee-dev-shm-size-kb

Ganzzahl

Hiermit wird die Größe des freigegebenen Arbeitsspeichers von /dev/shm in KB festgelegt.

Beispiel
tee-dev-shm-size-kb=65536

tee-env-ENVIRONMENT_VARIABLE_NAME

Interagiert mit:

String

Hiermit werden Umgebungsvariablen im Arbeitslastcontainer festgelegt. Der Autor der Arbeitslast muss die Namen der Umgebungsvariablen auch der allow_env_override -Richtlinie für den Start 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:

String

Eine Liste der Dienstkonten, deren Identität vom Arbeitslastoperator übernommen werden 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-monitoring-memory-enable

Interagiert mit:

Boolesch

Die Standardeinstellung ist false. Wenn true festgelegt ist, wird die Überwachung der Arbeitsspeichernutzung 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:

String

Eine Liste von durch Semikolons getrennten Bereitstellungsdefinitionen. Eine Bereitstellungsdefinition besteht aus einer durch Kommas getrennten Liste von Schlüssel/Wert-Paaren, für die type, source und destination erforderlich sind. 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-restart-policy

Interagiert mit:

Definierter String

Die Neustart-Richtlinie des Container-Launchers, wenn die Arbeitslast beendet wird

Gültige Werte:

  • Never (Standard)
  • Always
  • OnFailure

Diese Variable wird nur vom Produktions-Image für Confidential Space unterstützt.

Beispiel
tee-restart-policy=OnFailure

tee-signed-image-repos

Interagiert mit:

String

Eine Liste von durch Kommas getrennten Container-Repositories, in denen die Signaturen gespeichert werden, die von Sigstore Cosign generiert 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