Setting up automated deployments

You can configure automated deployments for your workloads on Google Kubernetes Engine (GKE).

This page shows you how to set up a simple continuous integration/continuous delivery (CI/CD) pipeline for the workload. When you push a change to your repository, Cloud Build automatically builds and deploys the container to your GKE cluster.

How an automated deployment works

If you have a workload that references a single-container image in GKE, you can configure an automated deployment, so that your application is re-built and deployed each time a code change is checked into the repository.

With an automated deployment, you define your workload as a YAML file and store that YAML file in your repository (consistent with best practices). GKE generates YAML that you can use for this purpose.

You have the following two options for using YAML files:

  • If you don't yet have a YAML file that defines your workload, you can use the generated YAML file. Save the YAML file in your repository. Cloud Build uses it to deploy your workload each time.

  • If you already have a YAML file that defines your workload, you can point GKE to its location in your repository. You can compare the YAML file in your repository with the recommended YAML file to ensure you're deploying the correct workload in the correct way.

Before you begin

Before you start, make sure you have performed the following tasks:

Set up default gcloud settings using one of the following methods:

  • Using gcloud init, if you want to be walked through setting defaults.
  • Using gcloud config, to individually set your project ID, zone, and region.

Using gcloud init

If you receive the error One of [--zone, --region] must be supplied: Please specify location, complete this section.

  1. Run gcloud init and follow the directions:

    gcloud init

    If you are using SSH on a remote server, use the --console-only flag to prevent the command from launching a browser:

    gcloud init --console-only
  2. Follow the instructions to authorize gcloud to use your Google Cloud account.
  3. Create a new configuration or select an existing one.
  4. Choose a Google Cloud project.
  5. Choose a default Compute Engine zone for zonal clusters or a region for regional or Autopilot clusters.

Using gcloud config

  • Set your default project ID:
    gcloud config set project PROJECT_ID
  • If you are working with zonal clusters, set your default compute zone:
    gcloud config set compute/zone COMPUTE_ZONE
  • If you are working with Autopilot or regional clusters, set your default compute region:
    gcloud config set compute/region COMPUTE_REGION
  • Update gcloud to the latest version:
    gcloud components update

Requirements

Automated deployments have the following requirements:

  • You can only use an automated deployment with workloads of type Deployment that specify a single container image. Multi-container workloads and other workload types (for example, ReplicaSet) are not supported.

  • Your source-code repository must contain a Dockerfile to build the image.

    You can host this repository on one of the following products:

    If you use GitHub or Bitbucket, you need to grant Google Cloud access to your repository.

  • Store your container image in Artifact Registry, in the same Google Cloud project as your GKE cluster. You need to have the image in Artifact Registry, and you need to have deployed it at least once, so that you have a workload in GKE.

Creating the automated deployment

To create an automated deployment, perform the following steps:

  1. Go to the Workloads page in Cloud Console.

    Go to Workloads

  2. In the workloads list, click the name of the Deployment you want to modify.

  3. Click Actions > Automated deployment.

In the Automate deployment pane, perform the following steps:

  1. Under Source repository, choose your source code repository:

    1. In the Repository Provider drop-down list, choose the provider for your repository

      An automated deployment supports the following source control hosts:

      • Cloud Source Repositories
      • GitHub
      • Bitbucket

        If you are using GitHub or Bitbucket, authenticate with your username and password.

    2. From the Repository drop-down list, select the name of the repository containing the source code for your Deployment.

    3. Click Continue.

  2. Under Build configurations, specify the Build configuration information:

    1. Enter the name of the branch from which you want to build, or a regular expression (RegExp2) to match the branch or branches. The default branch is master. When you push to this branch, Cloud Build builds your application.
    2. Enter the relative path of the Dockerfile directory.
    3. Enter the Dockerfile name.

    4. Click Continue.

  3. Under Automated deployment configuration, provide the configuration YAML file location.

    The system automatically generates a YAML file, which you can use to populate the YAML file in your repository.

    1. Click View Google-recommended YAML to see the generated YAML file.

    2. Compare it to your own YAML file, if you have it, and update yours based on this one.

      Otherwise, create a new file and populate it with the generated YAML. This helps ensure the workload that gets deployed matches what's currently running. The file can have any name, but must have a .yaml or .yml extension.

    3. Specify the relative path to the directory that contains the YAML file.

      If there is more than one YAML file in the specified directory, GKE uses all of them.

  4. Click Set Up to finish configuring your automated deployment.

    You might be prompted to grant permissions to the Cloud Build service account. This permission is required.

What happens next

After you set up automated deployment for the selected workload, you have a Cloud Build trigger that builds a container image after a push to the selected branch of the repository. Cloud Build also deploys a new revision of your workload to the cluster where the original image was deployed.

For more information on your workload, see the Deployment Details page (Revision History tab).