Part 2 of a 6 Part Series on Deploying on Google Cloud Platform

We recently did five mock deployments on Google Cloud Platform using different methods in an effort to understand the nuances associated with each method.

The five methods we investigated were:

We will be examining each of the 5 approaches in this series and wrap it all up with an article that talks about our findings in the context of all five approaches.

For our second article in the series we will be deploying an application on Google Cloud Platform using Google Kubernetes Engine.

Deploying with Google Kubernetes Engine

Google Kubernetes Engine (GKE) is the CaaS (Container as a Service) solution provided by Google Cloud Platform.

It allows users to easily run Docker containers in a fully-managed Kubernetes environment.

It takes care of the automation, management, and deployment of containers, their networking, storage and resources.

Google Kubernetes Engine leverages Kubernetes features that help users manage many moving parts of large applications, like Horizontal Pod Autoscalers, which manage replicas of the same pod throughout the available instances in the cluster.

It also benefits from Kubernetes Services for handling internal networking, and so on.

More GKE features can be found at

gke instance group

When to use GKE

You should use GKE when you need to manage Docker containers in a production environment without worrying too much about networking, node allocation and scaling features.

It is a good option for huge applications with many services that need to connect to each other.

It is also a wise option for when the team doesn’t have much SysAdmin knowledge since it can be configured to automate tasks like upgrading software, internal networking and so on.

Its console makes it easy to manage the application lifecycle, provision new instances and even restart / update applications.

How we implemented it

For this solution we used a terraform project that declares the following resources:

  • A VPC with a subnet for running the instances
  • A Google Cloud Artifacts repository for storing the application container image
  • A Redis instance to store data
  • A Kubernetes deployment, service, secret and load balancer for running the application

Main Components


Here is the Terraform block declaring the Redis instance.

Copy to Clipboard


Here we declare the cluster setting the region, network, subnetwork.

Copy to Clipboard

Node Pool

Here we declare the node pool with custom configurations, mainly the preemptible option.

Copy to Clipboard

Ingress Controller

Here we declare the helm chart for installing the ingress controller in the cluster.

Copy to Clipboard

Other components

The complete solution with other components can be found in our repository:

Pros & Cons

Pros Cons
Deploy Docker containers to production fast and easily Requires some Kubernetes knowledge
It is highly-available by nature, especially for microservices The high level of abstraction can sometimes take some part of the control from the user
It can handle application autoscaling natively using HPA It’s more expensive to run a cluster in GKE than the same set of applications in GCE
Communication between applications in the cluster is easy using Kubernetes Services It’s not as customizable as other solutions since some features are managed by Google
Easier to deploy and manage than other technologies, like kops
The Control Plane allows the user to manage pretty much everything on the cluster
It usually requires less manual work than other solutions, like GCE

Check back each week for the next instalment in the series.

Share Me

Related Reading


Don’t miss a beat

Get all the latest NearForm news, from technology to design. Sign up for our newsletter.

Follow us for more information on this and other topics.