Kubernetes on Google Cloud Platform: automate deployments with Cloud Build

This article is the last of a three-article series on Kubernetes and Google Cloud Platform. You can find the links to the other articles at the end. 

In this article, we will use Google Cloud Build to automate our app deployment with Helm.

Continuous Deployment

Continuous Deployment consists of the automation of a series of steps that usually go as follows: test, build, release and deploy of an application. This automated process can be triggered by a commit to a specific branch, or a tag on a repository, or manually.

There are various Continuous Deployment tools, some SaaS such as AWS CodePipeline, others like Gitlab-CI which are self-hosted. In this article, we will use Google Cloud Build, the Google Cloud Platform integrated Continuous Deployment solution. Cloud Build natively integrates with the GCP environment and can be granted IAM roles to interact with your GKE cluster and Google Cloud Registry.

By now you should have a GKE Kubernetes cluster, a NodeJS app, and a Helm chart to deploy it. Let’s bundle all those files in a git repository. Before pushing your repository to Github, add a .gitignore file to ignore the node modules:

When you are all set, your repository should look like this.

Deploying to Kubernetes with Google Cloud Build

Google Cloud Build executes a series of steps defined in a YAML file in the repository, that way the pipeline is versioned alongside the code. Each step runs a docker container with the content of the repository mounted as a volume in the working directory. In our case, we will want to build a docker image from our Dockerfile, push this image to a container registry, and upgrade our helm deployment with this new image. Create the following cloudbuild.yml file at the root of your repository:

Make sure to replace _CUSTOM_REGION with the region you chose when you terraformed your Kubernetes cluster.

As you can see, we push the image we build on the Google Container Registry (GCR). We also use base images available on GCR for docker and kubectl, but not for Helm. We have to build and push the helm image from this repository. To do so run the following commands:

Configuring a trigger

Now that we have a repository configured with a Cloud Build pipeline, we have to set a trigger for this pipeline. To do so, head over to the trigger page, click on connect repository, select GitHub and continue. Authorize Cloud Build to access your GitHub projects and when you are redirected to the Cloud Console click on Install Google Cloud Build. A new GitHub page will open, select your namespace and your repository. Back on the Cloud Console, check your repository and click connect repository.

Now that your repository is connected to Cloud Build, you can create a trigger by clicking create a push trigger. By default, Cloud Build pipelines will be triggered by push events on any branch. You can edit it to only deploy on pushes to the master branch, or only when some files change by specifying a glob pattern as in a .gitignore file.

To test your Cloud Build pipeline, push a new commit to your repository and you should see the pipeline automatically deploy your new code on your GKE cluster and the status reported on your GitHub repository by a green checkmark next to your commit.


Throughout this series of articles, you have learned the bases of Terraform to create a Kubernetes cluster on Google Cloud Platform. You have then discovered how to package and deploy an app on your cluster with Helm. And finally, you have configured Continuous Deployment of your app with Google Cloud Build

To learn more about Kubernetes and other Cloud Technologies, check our other blog articles.

Hadrien Patte

Hadrien Patte

Hadrien is a Site Reliability Engineer (SRE) at Padok. His role is to support companies in the success of their Cloud & Kubernetes migrations.

What do you think? Leave your comments here !