Skip to content
Terraform code and scripts for deploying a Google Kubernetes Engine (GKE) cluster.
Branch: master
Clone or download
robmorgan Merge pull request #40 from gruntwork-io/version-bump
Remove redundant timeout block, bump provider versions for 0.12
Latest commit 5c4208b May 24, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
.circleci fix typo May 14, 2019
examples Remove redundant timeout block, bump provider versions for 0.12 May 23, 2019
modules Remove redundant timeout block, bump provider versions for 0.12 May 23, 2019
test be sure to pass in kubectl config May 14, 2019
.gitignore ignore terratest output Jan 15, 2019
.pre-commit-config.yaml shift cluster tests into stages Jan 31, 2019
CODEOWNERS add codeowners Feb 12, 2019 Repo boilerplate Jan 12, 2019 Repo boilerplate Jan 12, 2019
LICENSE add Apache 2.0 license Jan 11, 2019
NOTICE add other module defaults Jan 15, 2019 Merge pull request #35 from gruntwork-io/yorinasub17-patch-1 May 9, 2019 Remove redundant timeout block, bump provider versions for 0.12 May 23, 2019 ensure the root example has the updated code May 14, 2019

Maintained by GitHub tag (latest SemVer)

Google Kubernetes Engine (GKE) Module

This repo contains a Terraform module for running a Kubernetes cluster on Google Cloud Platform (GCP) using Google Kubernetes Engine (GKE).


If you want to quickly spin up a GKE Private Cluster with Tiller, you can run the example that is in the root of this repo. Check out the gke-private-tiller example documentation for instructions.

What's in this repo

This repo has the following folder structure:

  • root: The root folder contains an example of how to deploy a GKE Private Cluster with Tiller. See gke-private-tiller for the documentation.

  • modules: This folder contains the main implementation code for this Module, broken down into multiple standalone submodules.

    The primary module is:

    There are also several supporting modules that add extra functionality on top of gke-cluster:

  • examples: This folder contains examples of how to use the submodules.

  • test: Automated tests for the submodules and examples.

What is Kubernetes?

Kubernetes is an open source container management system for deploying, scaling, and managing containerized applications. Kubernetes is built by Google based on their internal proprietary container management systems (Borg and Omega). Kubernetes provides a cloud agnostic platform to deploy your containerized applications with built in support for common operational tasks such as replication, autoscaling, self-healing, and rolling deployments.

You can learn more about Kubernetes from the official documentation.

What is GKE?

Google Kubernetes Engine or "GKE" is a Google-managed Kubernetes environment. GKE is a fully managed experience; it handles the management/upgrading of the Kubernetes cluster master as well as autoscaling of "nodes" through "node pool" templates.

Through GKE, your Kubernetes deployments will have first-class support for GCP IAM identities, built-in configuration of high-availability and secured clusters, as well as native access to GCP's networking features such as load balancers.

How do you run applications on Kubernetes?

There are three different ways you can schedule your application on a Kubernetes cluster. In all three, your application Docker containers are packaged as a Pod, which are the smallest deployable unit in Kubernetes, and represent one or more Docker containers that are tightly coupled. Containers in a Pod share certain elements of the kernel space that are traditionally isolated between containers, such as the network space (the containers both share an IP and thus the available ports are shared), IPC namespace, and PIDs in some cases.

Pods are considered to be relatively ephemeral disposable entities in the Kubernetes ecosystem. This is because Pods are designed to be mobile across the cluster so that you can design a scalable fault tolerant system. As such, Pods are generally scheduled with Controllers that manage the lifecycle of a Pod. Using Controllers, you can schedule your Pods as:

  • Jobs, which are Pods with a controller that will guarantee the Pods run to completion.
  • Deployments behind a Service, which are Pods with a controller that implement lifecycle rules to provide replication and self-healing capabilities. Deployments will automatically reprovision failed Pods, or migrate Pods to healthy nodes off of failed nodes. A Service constructs a consistent endpoint that can be used to access the Deployment.
  • Daemon Sets, which are Pods that are scheduled on all worker nodes. Daemon Sets schedule exactly one instance of a Pod on each node. Like Deployments, Daemon Sets will reprovision failed Pods and schedule new ones automatically on new nodes that join the cluster.

What's a Module?

A Module is a canonical, reusable, best-practices definition for how to run a single piece of infrastructure, such as a database or server cluster. Each Module is written using a combination of Terraform and scripts (mostly bash) and include automated tests, documentation, and examples. It is maintained both by the open source community and companies that provide commercial support.

Instead of figuring out the details of how to run a piece of infrastructure from scratch, you can reuse existing code that has been proven in production. And instead of maintaining all that infrastructure code yourself, you can leverage the work of the Module community to pick up infrastructure improvements through a version number bump.

Who maintains this Module?

This Module and its Submodules are maintained by Gruntwork. If you are looking for help or commercial support, send an email to

Gruntwork can help with:

  • Setup, customization, and support for this Module.
  • Modules and submodules for other types of infrastructure, such as VPCs, Docker clusters, databases, and continuous integration.
  • Modules and Submodules that meet compliance requirements, such as HIPAA.
  • Consulting & Training on AWS, Terraform, and DevOps.

How do I contribute to this Module?

Contributions are very welcome! Check out the Contribution Guidelines for instructions.

How is this Module versioned?

This Module follows the principles of Semantic Versioning. You can find each new release, along with the changelog, in the Releases Page.

During initial development, the major version will be 0 (e.g., 0.x.y), which indicates the code does not yet have a stable API. Once we hit 1.0.0, we will make every effort to maintain a backwards compatible API and use the MAJOR, MINOR, and PATCH versions on each release to indicate any incompatibilities.


Please see LICENSE for how the code in this repo is licensed.

Copyright © 2019 Gruntwork, Inc.

You can’t perform that action at this time.