Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Eine Cloud Deploy-Ausführungsumgebung ist die Umgebung, in der Cloud Deploy seine Rendering-, Vorabbereitstellungs-, Bereitstellungs-, Überprüfungs- und Bereitstellungsnachbereitungsvorgänge ausführt. Die Ausführungsumgebung besteht aus den folgenden Komponenten:
Der Cloud Build-Worker-Pool (Standard oder privat), in dem Cloud Deploy Rendering-, Vorabbereitstellungs-, Bereitstellungs-, Überprüfungs- und Bereitstellungsnachbereitungsvorgänge ausführt
Das Dienstkonto (Standard oder Alternativ), das Cloud Deploy zum Ausführen dieser Aktionen aufruft
Der Speicherort (Standard oder Alternativ) für gerenderte Manifeste in Cloud Storage.
Die Cloud Build-Zeitüberschreitung für Vorgänge (Standard oder benutzerdefiniert)
In diesem Artikel werden die Standardausführungsumgebung, die Dienstkonten und der Speicher für Cloud Deploy beschrieben, sowie Gründe und Vorgehensweisen für die Änderung dieser Standardeinstellungen.
Standardeinstellungen
Im Folgenden finden Sie die Standardwerte, die Cloud Deploy zum Ausführen, zum Rendering, zur Bereitstellung sowie zum Speichern von Assets, darunter gerenderte Manifeste, verwendet:
Dieser Wert ist der Cloud Storage-Bucket, in dem Cloud Deploy Ihre gerenderten Manifeste speichert. Standardmäßig erstellt Cloud Deploy einen Cloud Storage-Bucket in derselben Region wie die Cloud Deploy-Ressourcen. Er hat folgende Form:
Standardmäßig hat Cloud Build eine Zeitüberschreitung von einer Stunde für Vorgänge, die für Cloud Deploy ausgeführt werden. Sie können diese Zeitüberschreitung in der Ausführungsumgebungsspezifikation in der Zielkonfiguration ändern.
Standardausführlichkeit für Skaffold, gcloud CLI und kubectl
Standardmäßig sind die Logebenen für diese Tools auf die jeweiligen Standardwerte festgelegt, in der Regel warn oder ein entsprechender Wert. Sie können dies ändern und debug oder ein ähnliches Zeichen verwenden.
In folgenden Abschnitten werden die Umstände beschrieben, unter denen Sie diese Werte ändern würden, sowie Links zu entsprechenden Anleitungen.
Cloud Build-Worker-Pools
Für die Cloud Deploy-Ausführungsumgebung kann Folgendes verwendet werden:
Der Standard-Worker-Pool ist eine sichere, gehostete Umgebung mit Zugriff auf das öffentliche Internet. In diesem Pool werden von anderen Arbeitslasten isolierte Rendering-, Bereitstellungs-, Vorabbereitstellungs-, Nachbereitstellungs- und Überprüfungsvorgänge ausgeführt.
Privater Pool
Private Worker-Pools sind private, dedizierte Pools, die stärker angepasst werden können als der standardmäßige Worker-Pool. Diese Anpassung kann die Möglichkeit bieten, auf Ressourcen in einem privaten Netzwerk zuzugreifen. Wie der Standard-Worker-Pool werden auch private Worker-Pools von Cloud Build gehostet und vollständig verwaltet. Diese Pools können vertikal und horizontal auf null skaliert werden. Dabei muss keine Infrastruktur eingerichtet, aktualisiert oder skaliert werden.
In der Übersicht über private Pools von Cloud Build werden Standard-Worker-Pools und private Worker-Pools ausführlicher beschrieben. Dort findet sich auch eine Tabelle, in der die Funktionen verglichen werden.
Cloud Deploy-Ausführungsumgebung ändern
Unter folgenden Umständen können Sie die Cloud Deploy-Ausführungsumgebung ändern:
Sie möchten, dass Render-, Bereitstellungs-, Vorabbereitstellungs-, Nachbereitstellungs- oder Überprüfungsvorgänge oder eine Kombination aus diesen fünf Vorgängen in einer Umgebung ausgeführt werden, die von anderen Organisationen isoliert ist.
Sie möchten, dass diese Vorgänge in einer Umgebung ausgeführt werden, die nicht mit dem öffentlichen Internet verbunden ist.
Sie möchten separate Umgebungen für Rendering und Bereitstellung erstellen.
Sie möchten ein dediziertes Dienstkonto mit Berechtigungen verwenden, die für Ihre Nutzung spezifischer sind als die im Standarddienstkonto verfügbaren Berechtigungen.
Sie möchten gerenderte Manifeste an einem anderen Speicherort als dem standardmäßigen Cloud Storage-Bucket speichern.
Die Konfiguration aller drei Teile der Ausführungsumgebung (Worker-Pool, Dienstkonto und Speicher) erfolgt pro Ziel in der YAML-Konfiguration der einzelnen Ziele.
Vom Standardpool zu einem privaten Pool wechseln
Sie konfigurieren Worker-Pools pro Ziel, sodass der Pool für RENDER, DEPLOY, PREDEPLOY, POSTDEPLOY oder VERIFY (oder eine Kombination dieser fünf) nur für das jeweilige Ziel verwendet wird.
Wenn Sie den Standard-Worker-Pool sowohl für Rendering- als auch für Bereitstellungsvorgänge verwenden möchten, müssen Sie nichts weiter tun.
Im folgenden Beispiel wird eine Zielkonfiguration mit einem privaten Worker-Pool für DEPLOY und dem Standard-Worker-Pool für RENDER, PREDEPLOY, POSTDEPLOY und VERIFY gezeigt:
Vom Standarddienstkonto zum benutzerdefinierten Ausführungsdienstkonto wechseln
Wie beim Worker-Pool können Sie ein alternatives Dienstkonto angeben, das für Rendering oder Bereitstellung (oder beides) pro Ziel verwendet werden soll. Fügen Sie dazu folgende Zeile in die Zielkonfiguration ein, nach dem workerPool-Element:
Logebene für Skaffold, gcloud-Befehlszeile und kubectl ändern
Wenn Sie die Protokollebene für Skaffold, die gcloud-Befehlszeile und kubectl von den jeweiligen Standardwerten in debug (oder einem entsprechenden Wert) ändern möchten, setzen Sie in den Ausführungskonfigurationen verbose auf true. Beispiel:
Sie müssen einen privaten Cloud Build-Worker-Pool für die Ausführungsumgebung des Ziels verwenden – also nicht den Standard-Worker-Pool.
Das Projekt, das den Worker-Pool enthält, und das Projekt, das Ihre Cloud Deploy-Ressourcen enthält, müssen sich im selben VPC Service Controls-Sicherheitsperimeter befinden.
GKE-Cluster, die Sie im VPC Service Controls-Perimeter bereitstellen, müssen private Cluster sein.
Informationen zum Einrichten eines privaten Pools für einen privaten Cluster finden Sie in dieser Anleitung.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-17 (UTC)."],[[["\u003cp\u003eCloud Deploy's execution environment includes a Cloud Build worker pool, a service account, a storage location for rendered manifests, and a Cloud Build timeout, all of which have default settings.\u003c/p\u003e\n"],["\u003cp\u003eThe default Cloud Deploy settings use the default Cloud Build worker pool, the default Compute Engine service account, a Cloud Storage bucket for rendered manifests in the same region as the Cloud Deploy resources, and a one-hour Cloud Build timeout.\u003c/p\u003e\n"],["\u003cp\u003eYou can customize the Cloud Deploy execution environment per target, such as switching to a private Cloud Build worker pool, using a dedicated service account, or specifying a different Cloud Storage bucket for rendered manifests.\u003c/p\u003e\n"],["\u003cp\u003eChanging the execution environment is useful for deploying to private Google Kubernetes Engine clusters, isolating operations, or using dedicated service accounts with specific permissions.\u003c/p\u003e\n"],["\u003cp\u003eCloud Deploy can be configured to use a VPC Service Controls perimeter, but it requires a Cloud Build private worker pool and that the worker pool and the Cloud Deploy project be within the same security perimeter.\u003c/p\u003e\n"]]],[],null,["# Using Cloud Deploy execution environments\n\nA Cloud Deploy execution environment is the environment in which\nCloud Deploy executes its render, predeploy, deploy, verify, and\npostdeploy operations. The execution environment consists of the following\ncomponents:\n\n- The [Cloud Build worker pool](/build/docs/private-pools/private-pools-overview)\n (default or private) in which Cloud Deploy executes render,\n predeploy, deploy, verify, and postdeploy operations\n\n- The service account (default or alternate) that calls Cloud Deploy\n to perform these actions\n\n- The storage location (default or alternate) for rendered manifests in\n Cloud Storage\n\n- The Cloud Build timeout for operations (default or custom)\n\nThis article describes the default execution environment, service accounts, and\nstorage for Cloud Deploy, as well as why and how you can change these\ndefaults.\n\nDefaults\n--------\n\nThe following are the defaults that Cloud Deploy uses to run, to\nexecute rendering and deployment, and to store assets such as rendered manifests:\n\n- Default worker pool\n\n By default, Cloud Deploy runs in the default Cloud Build\n worker pool. However, you can [configure Cloud Deploy to use a Cloud Build\n private worker pool](/deploy/docs/config-files#executionconfigs).\n\n For more details about worker pools, see the Cloud Build\n [Overview of default pools and private pools](/build/docs/private-pools/private-pools-overview#overview_of_default_pools_and_private_pools).\n- Default execution service account\n\n By default, Cloud Deploy uses the [default Compute Engine\n service account](/deploy/docs/cloud-deploy-service-account#default_service_account).\n- Default Cloud Deploy storage location\n\n This value is the Cloud Storage bucket where Cloud Deploy\n stores your rendered manifests. By default, Cloud Deploy creates\n a Cloud Storage bucket, in the same [region](/deploy/docs/regions)\n as the Cloud Deploy resources, taking the following form:\n\n `\u003clocation\u003e.deploy-artifacts.\u003cproject ID\u003e.appspot.com`\n- Default Cloud Build timeout\n\n By default, Cloud Build has a timeout of 1 hour on operations it\n performs for Cloud Deploy. You can change that timeout in the\n execution environment specification in\n [target configuration](/deploy/docs/config-files#executionconfigs).\n- Default verbosity for Skaffold, gcloud CLI, and kubectl\n\n By default, log levels for these tools are set to their respective defaults,\n typically `warn` or the equivalent. You can [change this](#changing_log_level)\n to `debug` or the equivalent.\n\nThe sections that follow describe the circumstances under which you would change\nany of these values, and links to instructions for doing so.\n\nAbout Cloud Build worker pools\n------------------------------\n\nThe Cloud Deploy execution environment can use one of the following:\n\n- The [Cloud Build default pool](/build/docs/private-pools/private-pools-overview)\n\n The default worker pool is a secure, hosted environment with access to the\n public internet. Render, deploy, predeploy, postdeploy, and verify operations\n are executed in that pool, isolated from other workloads.\n- A private pool\n\n [Private worker pools](/build/docs/private-pools/private-pools-overview) are\n private, dedicated pools that can be customized more than the default worker\n pool. That customization can include the ability to access resources in a\n private network. Like the default worker pool, private worker pools are hosted\n and fully managed by Cloud Build. These pools can scale up or\n scale down to zero, with no infrastructure to set up, upgrade, or scale.\n\n The Cloud Build [Private pools overview](/build/docs/private-pools/private-pools-overview)\n describes default worker pools and private worker pools more thoroughly,\n including a table comparing their features.\n\n| **Note:** Cloud Build private worker pools are regional resources. Cloud Deploy lets you configure [targets](/deploy/docs/terminology#target) with private pools in other regions. This configuration makes it possible to share private worker pools among targets, and allows cross-regional dependencies.\n\nChanging the Cloud Deploy execution environment\n-----------------------------------------------\n\nYou might change the Cloud Deploy execution environment under the\nfollowing circumstances:\n\n- You want to [deploy to a private Google Kubernetes Engine cluster](/build/docs/private-pools/use-in-private-network#deploying-to-clusters)\n\n- You want render, deploy, predeploy, postdeploy, or verify operations, or a\n combination of the five, to be performed in an environment that's isolated from\n other organizations.\n\n- You want these operations to be performed in an environment that isn't\n connected to the public internet.\n\n- You want separate environments for render and deploy.\n\n- You want to use a dedicated service account with permissions that are more\n specific to your use than the permissions available in the default service\n account.\n\n- You want to store rendered manifests in a location different from the default\n Cloud Storage bucket.\n\nConfiguration of all three parts of the execution environment (worker pool, service\naccount, and storage) is done per target, in [each target's YAML configuration](/deploy/docs/config-files#target_definitions).\n\n### Changing from the default pool to a private pool\n\nYou configure worker pools [per target](/deploy/docs/config-files#target_definitions),\nso that the pool is used for `RENDER`, `DEPLOY`, `PREDEPLOY`, `POSTDEPLOY`, or\n`VERIFY` (or a combination of the five) *for that target only*.\n\nTo use the default worker pool for both render and deploy operations, you don't\nneed to do anything.\n| **Note:** if you want to configure a target to use a private worker pool for either operation (`RENDER` or `DEPLOY`), but the default worker pool for the other, you must configure both. That is, you can't specify a private worker pool for `DEPLOY` but assume Cloud Deploy will perform rendering in the default pool.\n\nThe following is a sample target configuration that specifies a private worker\npool for `DEPLOY`, and the default worker pool for `RENDER`, `PREDEPLOY`,\n`POSTDEPLOY` and `VERIFY`: \n\n executionConfigs:\n - usages:\n - DEPLOY\n privatePool:\n workerPool: \"projects/p123/locations/us-central1/workerPools/wp123\"\n - usages:\n - RENDER\n - PREDEPLOY\n - VERIFY\n - POSTDEPLOY\n\n| **Note:** if Cloud Deploy is running in a different project from the worker pool's project, make sure the [service agent](/deploy/docs/cloud-deploy-service-account#service_agent) has permission on the worker pool in that project. You can use either the `roles/cloudbuild.workerPoolUser` role or the `cloudbuild.workerpools.use` direct permission.\n\nFor more information about how to configure private pools for targets, see\n[Delivery pipeline configuration documentation](/deploy/docs/config-files#executionconfigs).\n\n### Changing from the default to custom execution service account\n\nAs with the worker pool, you can specify an alternate service account to use for\nrendering or deploying (or both) per target. To do so, add the following line to\nthe target configuration, after the `workerPool` element:\n\n`serviceAccount: \"[name]@[project_name].iam.gserviceaccount.com\"`\n\nThe specified service account must include the `clouddeploy.jobRunner` role, as\ndescribed in the [Cloud Deploy service accounts](/deploy/docs/cloud-deploy-service-account)\ndocument.\n\nSee [Target definitions](/deploy/docs/config-files#target_definitions) for more\ndetails on this configuration.\n\n### Changing the storage location\n\nTo change the storage bucket from the Cloud Deploy default, add the\nfollowing line to the [target definition](/deploy/docs/config-files#target_definitions)\nin the `workerPool` stanza:\n\n`artifactStorage: \"gs://[bucket_name]/[dir]\"`\n\nThis configuration changes where the rendered manifests are stored, but does not\naffect [where the rendering source is stored](/sdk/gcloud/reference/deploy/releases/create#--source).\n\n### Changing the log level for Skaffold, gcloud CLI, and kubectl\n\nTo change the log level for Skaffold, gcloud CLI, and kubectl, from\ntheir respective defaults to `debug` (or the equivalent), set `verbose` to\n`true` in the execution configs. Here's an example: \n\n executionConfigs:\n - usages:\n - [RENDER | PREDEPLOY| DEPLOY | VERIFY | POSTDEPLOY]\n workerPool:\n serviceAccount:\n artifactStorage:\n executionTimeout:\n verbose: true\n\nUsing Cloud Deploy in a VPC Service Controls perimeter\n------------------------------------------------------\n\nCloud Deploy supports [VPC Service Controls](/vpc-service-controls).\n\nYou can follow the [VPC Service Controls quickstart](/vpc-service-controls/docs/set-up-service-perimeter)\nto set up a service perimeter.\n\n### Limitations\n\n- You must use a Cloud Build private worker pool for the target's\n execution environment---not the default worker pool.\n\n- The project that contains the worker pool and the project that contains your\n Cloud Deploy resources must remain in the same VPC Service Controls\n security perimeter.\n\n- Any GKE cluster you deploy to in the\n VPC Service Controls perimeter must be a private cluster.\n\n To set up a private pool for a private cluster, see [this tutorial](https://cloud.google.com/architecture/accessing-private-gke-clusters-with-cloud-build-private-pools).\n\nWhat's next\n-----------\n\n- Find out more about [Cloud Deploy target configuration](/deploy/docs/config-files#target_definitions).\n\n- Read about [Cloud Build private pools](/build/docs/private-pools/private-pools-overview).\n\n- Read about [how Cloud Build uses VPC Service Controls](/build/docs/private-pools/using-vpc-service-controls).\n\n- Learn about how Cloud Deploy uses [service accounts](/deploy/docs/cloud-deploy-service-account).\n\n- [Access private GKE clusters with Cloud Build private pools](/architecture/accessing-private-gke-clusters-with-cloud-build-private-pools)."]]
