Building a CI/CD System for Private GKE Clusters with Google Cloud Deploy

Originally published on priyathgregory.dev.

A robust Continuous Integration and Continuous Delivery (CICD) pipeline plays a crucial role in any development ecosystem, introducing dependability, efficiency, and adaptability to your integration and delivery workflows.

As part of our company’s ongoing re-architectural efforts, we recently engineered a CICD pipeline tailored to seamlessly support the deployment of Google Kubernetes Engine (GKE) workloads. The system was designed with the following criteria in mind:

• Separate build and deployment steps
• A single control point to manage the release lifecycle
• Support workload deployment into private GKE clusters across different GCP projects. (eg: staging & production)
• Environment promotion and rollback support for releases.
• Observability

A high-level visualisation of the final architecture is shown below

The Build Step

Github Actions is used for the build step. The action is triggered via a successful pull request merge to the main branch. The action runs code verification and initiates the docker build. On completion, the built artifact is pushed to the Google Artifact Registry.

The build step will also call the Google Cloud Deploy service to create a release for application deployment. We will look into the details of this process in the next section.

Authentication for GCP from Github Actions is handled via OpenID Connect (OIDC) with Google’s Workload Identity Federation. This approach allows workflows to get temporary access tokens when needed, while eliminating the overhead and risk of managing sensitive service account keys.

The Deploy Step

Google Cloud Deploy is used for the CD system. Cloud Deploy is a Google-managed service that automates delivery and allows you to manage the release lifecycle of your applications. It interacts with the following systems: