A Cloud Deploy execution environment is the environment in which Cloud Deploy executes its render, predeploy, deploy, verify, and postdeploy operations. The execution environment consists of the following components:
The Cloud Build worker pool (default or private) in which Cloud Deploy executes render, predeploy, deploy, verify, and postdeploy operations
The service account (default or alternate) that calls Cloud Deploy to perform these actions
The storage location (default or alternate) for rendered manifests in Cloud Storage
The Cloud Build timeout for operations (default or custom)
This document describes the default execution environment, service accounts, and storage for Cloud Deploy, as well as why and how you can change these defaults.
Defaults
The following are the defaults that Cloud Deploy uses to run, to execute rendering and deployment, and to store assets such as rendered manifests:
Default worker pool
By default, Cloud Deploy runs in the default Cloud Build worker pool. However, you can configure Cloud Deploy to use a Cloud Build private worker pool.
For more details about worker pools, see the Cloud Build Overview of default pools and private pools.
Default execution service account
By default, Cloud Deploy uses the default Compute Engine service account.
Default Cloud Deploy storage location
This value is the Cloud Storage bucket where Cloud Deploy stores your rendered manifests. By default, Cloud Deploy creates a Cloud Storage bucket, in the same region as the Cloud Deploy resources, taking the following form:
<location>.deploy-artifacts.<project ID>.appspot.comDefault Cloud Build timeout
By default, Cloud Build has a timeout of 1 hour on operations it performs for Cloud Deploy. You can change that timeout in the execution environment specification in target configuration.
Default verbosity for Skaffold, gcloud CLI, and kubectl
By default, log levels for these tools are set to their respective defaults, typically
warnor the equivalent. You can change this todebugor the equivalent.
The sections that follow describe the circumstances under which you would change any of these values, and links to instructions for doing so.
About Cloud Build worker pools
The Cloud Deploy execution environment can use one of the following:
-
The default worker pool is a secure, hosted environment with access to the public internet. Render, deploy, predeploy, postdeploy, and verify operations are executed in that pool, isolated from other workloads.
A private pool
Private worker pools are private, dedicated pools that can be customized more than the default worker pool. That customization can include the ability to access resources in a private network. Like the default worker pool, private worker pools are hosted and fully managed by Cloud Build. These pools can scale up or scale down to zero, with no infrastructure to set up, upgrade, or scale.
The Cloud Build Private pools overview describes default worker pools and private worker pools more thoroughly, including a table comparing their features.
Changing the Cloud Deploy execution environment
You might change the Cloud Deploy execution environment under the following circumstances:
You want to deploy to a private Google Kubernetes Engine cluster
You want render, deploy, predeploy, postdeploy, or verify operations, or a combination of the five, to be performed in an environment that's isolated from other organizations.
You want these operations to be performed in an environment that isn't connected to the public internet.
You want separate environments for render and deploy.
You want to use a dedicated service account with permissions that are more specific to your use than the permissions available in the default service account.
You want to store rendered manifests in a location different from the default Cloud Storage bucket.
Configuration of all three parts of the execution environment (worker pool, service account, and storage) is done per target, in each target's YAML configuration.
Changing from the default pool to a private pool
You configure worker pools per target,
so that the pool is used for RENDER, DEPLOY, PREDEPLOY, POSTDEPLOY, or
VERIFY (or a combination of the five) for that target only.
To use the default worker pool for both render and deploy operations, you don't need to do anything.
The following is a sample target configuration that specifies a private worker
pool for DEPLOY, and the default worker pool for RENDER, PREDEPLOY,
POSTDEPLOY and VERIFY:
executionConfigs:
- usages:
- DEPLOY
privatePool:
workerPool: "projects/p123/locations/us-central1/workerPools/wp123"
- usages:
- RENDER
- PREDEPLOY
- VERIFY
- POSTDEPLOY
For more information about how to configure private pools for targets, see