Deploying a GKE cluster through the Cloud Console is fine for experimentation, but for production you want it in code. Terraform gives you repeatable, version-controlled GKE deployments that you can review, test, and roll back. GKE clusters have a lot of configuration options, and getting them right matters. A misconfigured cluster can be insecure, expensive, or both. This guide walks through deploying a production-ready GKE cluster with Terraform, focusing on the decisions that actually matter.
The intersection of Terraform as an infrastructure-as-code tool and Google Kubernetes Engine as a managed control plane creates a configuration surface where declarative intent meets regional, zonal, and node-pool realities. Terraform provides plugins called providers that let you interact with cloud providers and other APIs. You can use the Terraform provider for Google Cloud to provision and manage Google Cloud resources, including GKE. Each resource block describes one or more infrastructure objects, such as virtual networks or compute instances. This mapping from configuration to API calls is what makes Terraform suitable for production GKE work rather than console-driven experiments.
Prerequisites and API Enablement
Before starting, make sure you have:
- Terraform 1.5 or later installed
- The Google Cloud Terraform provider configured
- The Kubernetes Engine API enabled in your project
- A service account with at least the Kubernetes Engine Admin role
The presence of Terraform 1.5 or later installed establishes the baseline CLI capability for plan and apply operations that evaluate configuration and generate execution plans. The Google Cloud Terraform provider configured ensures the provider can authenticate and translate resource blocks into Google Cloud API calls. The Kubernetes Engine API enabled in your project is a hard dependency for any container.googleapis.com interactions. A service account with at least the Kubernetes Engine Admin role provides the permission boundary required to create clusters, node pools, and associated compute resources.
Enable the required APIs:
bash
gcloud services enable \
container.googleapis.com \
compute.googleapis.com \
binaryauthorization.googleapis.com
Enabling container.googleapis.com unlocks GKE cluster creation and management. compute.googleapis.com is required because GKE nodes are Compute Engine resources under the hood and the VPC network, subnetwork, and instance provisioning flow depends on Compute Engine APIs. binaryauthorization.googleapis.com is enabled for policy enforcement on container images, a production security decision that matters when moving beyond experimentation. The impact of omitting any of these enables is a failure at plan or apply time with opaque authentication or API not enabled errors, which interrupts repeatable deployment.
Before you begin, take the following steps to enable the Kubernetes Engine API:
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios
Signing in creates the identity context for gcloud and Terraform provider authentication. Creating an account is a prerequisite for project creation and billing linkage that underpins resource provisioning.
How Terraform Works with GKE
HashiCorp Terraform is an infrastructure-as-code tool that lets you provision and manage cloud infrastructure. Terraform provides plugins called providers that let you interact with cloud providers and other APIs. You can use the Terraform provider for Google Cloud to provision and manage Google Cloud resources, including GKE.
This page introduces you to using Terraform with GKE, including an introduction to how Terraform works and some resources to help you get started using Terraform with Google Cloud. You'll also find links to Terraform reference docs for GKE, code examples, and guides for using Terraform to provision GKE resources.
How Terraform works:
- You describe the infrastructure you want to provision in a Terraform configuration file. You don't need to write code describing how to provision the infrastructure. Terraform provisions the infrastructure for you.
- You run the terraform plan command, which evaluates your configuration and generates an execution plan. You can review the plan and make changes as needed
The declarative nature means the configuration describes desired state, not procedural steps. This separates intent from implementation and allows review of changes before they are applied to production GKE resources. The plan command is the safety layer that surfaces drift, new resources, and destructive changes.
It serves as a bridge between Terraform configurations and Google Cloud APIs, letting you declaratively define infrastructure resources, such as virtual machines and networks. The bridge metaphor holds because Terraform does not call APIs directly in user code; the provider translates resource schemas into authenticated API requests.
VPC Network Foundation for GKE
GKE clusters need a VPC network
The VPC network is the networking substrate for pod IP allocation, service IP ranges, and node-to-node communication. Without a VPC, GKE cannot allocate node IP addresses or establish the overlay network. Creating the VPC Network is therefore a foundational step before cluster creation.
The cluster and sample app for this tutorial are specified in two Terraform files that use the Google Cloud and Kubernetes providers.
Review the cluster.tf file:
bash
cat cluster.tf
The output is similar to the following
This file describes the following resources:
googlecomputenetwork: a VPC network with internal IPv6 enabled.
googlecomputesubnetwork: a dual-stack subnetwork.
googlecontainercluster: a dual-stack Autopilot mode cluster located in us-central1
The deletionprotection setting controls whether you can use Terraform to delete this cluster. If you set the value in the deletionprotection field to false, Terraform can delete the cluster. For details, see the googlecontainercluster reference.
A VPC network with internal IPv6 enabled expands addressability for pods and services that require IPv6. The dual-stack subnetwork indicates both IPv4 and IPv6 are provisioned, which aligns with modern GKE networking defaults and future-proofs the cluster. The dual-stack Autopilot mode cluster located in us-central1 combines Autopilot management of node provisioning with regional location choice. Autopilot mode shifts node management responsibility to Google, reducing operational overhead.
The deletionprotection setting controls whether you can use Terraform to delete this cluster. Setting deletionprotection to false allows Terraform to destroy the cluster on destroy operations. Leaving deletion_protection true protects production clusters from accidental Terraform destroys. This is a decision that actually matters for production safety.
Node Pool Provisioning and Zonal Distribution
You are now signed in to the dashboard for your Kubernetes cluster.
On the Dashboard UI, click Nodes on the left hand menu.
Notice there are 6 nodes in your cluster, even though gkenumnodes in your gke.tf file was set to 2. This is because a node pool was provisioned in each of the three zones within the region to provide high availability. To see the zones that the cluster deployed each node pool to, run the following in the learn-terraform-provision-gke-cluster directory.
bash
$ gcloud container clusters describe $(terraform output -raw kubernetes_cluster_name) --region us-central1 --format='default(locations)'
locations:
- us-central1-b
- us-central1-f
- us-central1-c
The discrepancy between requested node count and observed node count illustrates GKE's zonal distribution logic. Setting gkenumnodes to 2 does not mean two nodes total; it means two nodes per zone. With three zones in us-central1, the total becomes 6 nodes. This is high availability by design.
The command to describe cluster locations confirms the zonal placement. The output shows us-central1-b, us-central1-f, and us-central1-c. This visibility is essential for troubleshooting node failures, understanding data locality, and planning upgrades.
Congratulations, you have provisioned a GKE cluster with a separated node pool, configured kubectl, and deployed the Kubernetes dashboard.
If you'd like to learn how to manage your GKE cluster using the Terraform Kubernetes Provider, leave your cluster running and continue to the Kubernetes provider tutorial.
If not, remember to destroy any resources you create once you are done with this tutorial
Provisioning a separated node pool enables workload isolation and independent scaling. Configuring kubectl provides the client configuration to interact with the cluster. Deploying the Kubernetes dashboard gives a UI for node and workload inspection.
Workload Deployment and Access Patterns
Create a cluster and deploy a workload using Terraform
A Kubernetes cluster provides compute, storage, networking, and other services for applications, similar to a virtual data center. Apps and their associated services that run in Kubernetes are called workloads.
This tutorial lets you quickly see a running Google Kubernetes Engine cluster and sample workload, all set up using Terraform. You can then explore the workload in the Google Cloud console before going on to our more in-depth learning path, or to start planning and creating your own production-ready cluster. This tutorial assumes that you are already familiar with Terraform.
If you'd prefer to set up your sample cluster and workload in the Google Cloud console, see Create a cluster in the Google Cloud console.
Review the app.tf file:
bash
cat app.tf
The output is similar to the following
This file describes the following resources:
(Optional) Expose the application to the internet
The Terraform files for the example describe an application with an internal IP address, which can only be accessed from the same Virtual Private Cloud (VPC) as the sample app. If you want to access the running demo app's web interface from the internet (for example, from your laptop), modify the Terraform files to create a public IP address instead before you create the cluster
An internal IP address restricts access to the VPC, which is a secure default for internal services. Modifying the Terraform files to create a public IP address instead changes the exposure surface. This decision maps directly to production security posture and cost.
Terraform Resource Inventory for GKE
Terraform has a declarative and configuration-oriented syntax, which you can use to describe the infrastructure that you want to provision in your Google Cloud project. After you author this configuration in one or more Terraform configuration files, you can use the Terraform CLI to apply this configuration to your GKE resources.
The following table lists the Terraform resources available for GKE:
The Terraform-based guides for GKE are enumerated as follows:
| Guide | Details |
|---|---|
| Create a GKE cluster and deploy a workload by using Terraform | Explains how to create a Google Kubernetes Engine (GKE) Autopilot cluster and deploy a workload by using Terraform. |
| Create an Autopilot cluster | Explains how to create a GKE cluster in Autopilot. |
| Creating a zonal cluster | Explains shows you how to create a Standard zonal cluster with the default features enabled in GKE. |
| Creating a regional cluster | Explains how to create a Standard regional cluster in GKE. |
| Create a multi-tenant cluster by using Terraform | Explains how to create a multi-tenant cluster and deploy a workload by using Terraform. |
| Add and manage node pools | Explains how to add and perform operations on node pools running your GKE Standard clusters. |
| Create clusters and node pools with Arm nodes | Explains how to create a GKE Standard cluster or node pool with Arm nodes, so that you can run Arm workloads on GKE. |
| Consuming reserved zonal resources | Explains how to consume reserved Compute Engine resources in GKE. |
| Specify a node image | Explains how to specify a node image for nodes in GKE Standard clusters |
These guides map to different operational needs. Autopilot guides reduce node management overhead. Zonal and regional guides address availability requirements. Node pool management guides cover scaling and updates. Arm node guides address architecture-specific workloads. Reserved zonal resources guides address capacity guarantees.
Back to BlogRSSSeptember 4, 2025•Mike Vanbuskirk terraform github gke automation kubernetes google-cloud infrastructure Provisioning Google Cloud Infrastructure with Terraform (GKE Cluster Example)
This publication date anchors the practice in 2025 and signals ongoing relevance for Terraform GKE automation patterns.
Operational Decisions and Production Readiness
Deploying a GKE cluster through the Cloud Console is fine for experimentation, but for production you want it in code. Terraform gives you repeatable, version-controlled GKE deployments that you can review, test, and roll back.
Version control of Terraform configurations enables peer review, change history, and audit trails. Repeatability ensures identical clusters can be provisioned across environments. Rollback capability protects against misconfiguration.
GKE clusters have a lot of configuration options, and getting them right matters. A misconfigured cluster can be insecure, expensive, or both. This guide walks through deploying a production-ready GKE cluster with Terraform, focusing on the decisions that actually matter.
Security decisions include network policies, private cluster configuration, binary authorization, and deletion protection. Cost decisions include node pool size per zone, machine type selection, Autopilot versus Standard, and regional versus zonal placement. The combination of these decisions determines whether a cluster is suitable for production workloads.
The tutorial lets you quickly see a running Google Kubernetes Engine cluster and sample workload, all set up using Terraform. You can then explore the workload in the Google Cloud console before going on to our more in-depth learning path, or to start planning and creating your own production-ready cluster.
This progression from sample to production is deliberate. The sample provides immediate feedback. The learning path provides depth. Planning enables customization for organizational requirements.
Conclusion
Terraform provisioning of GKE clusters converts infrastructure intent into repeatable API-driven state. The VPC network with internal IPv6 enabled and dual-stack subnetwork provide the networking foundation. The googlecontainercluster resource with deletion_protection controls lifecycle safety. Autopilot mode in us-central1 shifts node management to Google while preserving regional control. Node pool provisioning per zone creates six nodes when two per zone is requested, delivering high availability by design. The gcloud container clusters describe command with locations output confirms zonal distribution.
Enabling container.googleapis.com, compute.googleapis.com, and binaryauthorization.googleapis.com satisfies the API prerequisites. Terraform 1.5 or later, a configured provider, and a service account with Kubernetes Engine Admin role satisfy the identity prerequisites. Terraform plan evaluates configuration before apply, preserving safety.
Workload deployment via app.tf demonstrates internal IP access patterns and the optional decision to expose applications to the internet. The Terraform Kubernetes Provider extends management beyond cluster creation into workload definition.
The guide inventory covering Autopilot, zonal, regional, multi-tenant, node pool management, Arm nodes, reserved resources, and node image specification provides a map for extending the baseline cluster to specialized production requirements. The combination of declarative configuration, version control, and provider-driven API translation makes Terraform the production choice over console-based experimentation.