Infrastructure as code changes how teams interact with Google Kubernetes Engine. The combination of HashiCorp Terraform and Google Cloud provider creates a declarative path to describe, preview, and enforce the desired state of GKE clusters and their supporting infrastructure. 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.
The operational reality for engineers is a shift from imperative clicks in the console to versioned configuration files that can be reviewed, tested, and applied repeatedly. The declarative and configuration-oriented syntax of Terraform means you describe the infrastructure 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 Google Kubernetes Engine is a fully managed Kubernetes service for deploying, managing, and scaling containerized applications on Google Cloud. When Terraform is used with GKE, the cluster definition lives alongside VPC, subnet, node pool, and IAM definitions. That colocation produces a single source of truth for the platform and the workloads it will host.
How Terraform Works with GKE
Terraform works through a small set of repeatable actions that translate configuration into real infrastructure.
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.
You run the
terraform apply
command, which performs the following actions:
It provisions your infrastructure based on your execution plan by invoking the corresponding GKE APIs in the background.
It creates a Terraform state file, which is a JSON file that maps the resources in your configuration file to the resources in the real-world infrastructure. Terraform uses this file to keep a record of the most recent state of your infrastructure, and to determine when to create, update, and destroy resources.
When you run
terraform apply
, Terraform uses the mapping in the state file to compare the existing infrastructure to the code, and make updates as necessary:
If a resource object is defined in the configuration file, but doesn't exist in the state file, Terraform creates it.
If a resource object exists in the state file, but has a different configuration from your configuration file, Terraform updates the resource to match your configuration file.
If a resource object in the state file matches your configuration file, Terraform leaves the resource unchanged.
This behavior creates a stable operational loop. Engineers can see exactly what will change before it changes, and the state file provides continuity across runs. The state file is the operational memory of Terraform. Losing it creates a disconnect between code and reality.
Each resource block describes one or more infrastructure objects, such as virtual networks or compute instances. Resources are the fundamental elements in the Terraform language. For GKE, the resource blocks cover clusters, node pools, network configuration, and related Google Cloud primitives.
Terraform Provider and GKE Resource Landscape
The Terraform provider for Google Cloud is the bridge between Terraform configuration and Google Cloud APIs. The 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.
The provider model means Terraform does not need custom scripts to call GKE APIs. The provider handles authentication, API versioning, and idempotent operations. This reduces toil and eliminates manual drift.
Terraform-based guides for GKE are published to help users move from concepts to production patterns.
| Guide | Details |
|---|---|
| Create a GKE cluster and deploy a workload by using Terraform | Explains how to create a Google Kubernetes Engine 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 |
The table reflects the breadth of scenarios covered by Terraform with GKE, from Autopilot to Standard, zonal to regional, node pool management to specialized hardware.
Tutorial Walkthrough: Two Node Separately Managed Node Pool
The HashiCorp tutorial demonstrates a practical path to GKE with Terraform.
In this tutorial, you will deploy a 2-node separately managed node pool GKE cluster using Terraform. This GKE cluster will be distributed across multiple zones for high availability.
Then, you will configure kubectl using Terraform output to deploy a Kubernetes dashboard on the cluster.
The tutorial emphasizes high availability through multi-zone distribution. Separately managed node pools allow you to customize your Kubernetes cluster profile — this is useful if some Pods require more resources than others.
While you could use the built-in GCP provisioning processes UI, SDK/CLI for GKE clusters, Terraform provides you with several benefits:
- Unified Workflow - If you are already deploying infrastructure to Google Cloud with Terraform, your GKE cluster can fit into that workflow. You can also deploy applications into your GKE cluster using Terraform.
- Full Lifecycle Management - Terraform doesn't only create resources, it updates, and deletes tracked resources without requiring you to inspect the API to identify those resources.
- Graph of Relationships - Terraform understands dependency relationships between resources
Unified workflow means platform teams can keep networking, IAM, and Kubernetes in the same repository and pipeline. Full lifecycle management means deletions and updates are expressed as code changes rather than manual console actions. Graph of relationships means Terraform can order creation of VPC before subnet before cluster before node pool without explicit sequencing by the user.
The tutorial includes preparatory steps for credentials and repository access.
Finally, add your account to the Application Default Credentials ADC. This will allow Terraform to access these credentials to provision resources on GCloud.
gcloud auth application-default login
In your terminal, clone the following repository. It contains the example configuration used in this tutorial.
git clone https://github.com/hashicorp-education/learn-terraform-provision-gke-cluster
You can explore this repository by changing directories or navigating in your UI.
cd learn-terraform-provision-gke-cluster
In here, you will find four files used to provision a VPC, subnets and a GKE cluster.
Configuration Files and Variables
The example repository contains a minimal, readable set of files.
vpc.tf provisions a VPC and subnet. A new VPC is created for this tutorial so it doesn't impact your existing cloud environment and resources. This file outputs region.
gke.tf provisions a GKE cluster and a separately managed node pool recommended. Separately managed node pools allows you to customize your Kubernetes cluster profile — this is useful if some Pods require more resources than others. You can learn more here. The number of nodes in the node pool is defined also defined here.
terraform.tfvars is a template for the project_id and region variables.
versions.tf sets the Terraform version to at least 0.14.
Replace the values in your terraform.tfvars file with your project_id and region. Terraform will use these values to target your project when provisioning your resources.
The separation of code and variables is intentional. vpc.tf and gke.tf contain the shape of infrastructure. terraform.tfvars contains the targeting information. versions.tf pins the toolchain. This separation supports reuse across environments and protects secrets and project identifiers from being hard-coded.
Execution Plan, State File, and Lifecycle
The plan and apply cycle is the core feedback loop.
The terraform plan command evaluates your configuration and generates an execution plan. You can review the plan and make changes as needed.
The terraform apply command provisions infrastructure based on the execution plan by invoking the corresponding GKE APIs in the background. It creates a Terraform state file, which is a JSON file that maps the resources in your configuration file to the resources in the real-world infrastructure.
The state file keeps a record of the most recent state of your infrastructure, and to determine when to create, update, and destroy resources.
On subsequent runs, Terraform uses the mapping in the state file to compare the existing infrastructure to the code, and make updates as necessary. If a resource object is defined in the configuration file, but doesn't exist in the state file, Terraform creates it. If a resource object exists in the state file, but has a different configuration from your configuration file, Terraform updates the resource to match your configuration file. If a resource object in the state file matches your configuration file, Terraform leaves the resource unchanged.
This model prevents accidental drift and enables safe refactoring. Engineers can see a diff of infrastructure before it is applied.
Cost Awareness and Billing Impact
Cost considerations are explicit in the tutorial.
Warning! Google Cloud charges about ten cents per hour management fee for each GKE cluster, in addition to the cluster's resource costs. One zonal cluster per billing account is free. As a result, you may be charged to run these examples. The most you should be charged should only be a few dollars, but we're not responsible for any charges that may incur.
The management fee is per cluster, not per node. The free zonal cluster allowance reduces cost for experimentation. The warning reinforces that infrastructure as code can provision real resources that incur charges immediately after apply.
Teams often pair Terraform with cost guardrails, such as budgeting alerts, resource labels, and automated teardown for ephemeral environments. The ten cents per hour figure provides a baseline for planning.
Guide Catalog and Community Artifacts
The Google Cloud documentation lists Terraform resources available for GKE. Each resource block describes one or more infrastructure objects, such as virtual networks or compute instances.
Additional reference artifacts include terraform-google-gke-gitlab for installing GitLab on GKE.
What's next sections point to Terraform code samples for GKE, Terraform on Google Cloud documentation, Google Cloud provider documentation in HashiCorp, and Infrastructure as code for Google Cloud.
The blogosphere continues to expand practical patterns. Back to BlogRSS September 4, 2025 • Mike Vanbuskirk terraform github gke automation kubernetes google-cloud infrastructure Provisioning Google Cloud Infrastructure with Terraform GKE Cluster Example.
The date and author provide a temporal anchor for the community discussion around Terraform and GKE automation.
Next Steps and Reference Artifacts
The documentation ecosystem supports progression from tutorial to production.
Terraform code samples for GKE provide copyable modules.
Terraform on Google Cloud documentation provides platform context.
Google Cloud provider documentation in HashiCorp provides provider version details and resource references.
Infrastructure as code for Google Cloud provides conceptual guidance for teams adopting IaC at scale.
The combination of declarative configuration, state tracking, and provider-managed APIs makes Terraform a repeatable way to provision GKE clusters, node pools, networking, and related resources. The tutorial path with VPC, subnet, cluster, and node pool files demonstrates a minimal viable pattern that can be extended to Autopilot, regional, multi-tenant, and Arm node scenarios.
Conclusion
Terraform and GKE together enable infrastructure definition as versioned code with explicit lifecycle control. The declarative syntax removes the need to write imperative provisioning steps. The plan command provides a preview of changes before any API call is made. The apply command creates a state file that maps configuration to real resources and drives future updates and deletions.
The tutorial example with a 2-node separately managed node pool distributed across multiple zones shows how high availability and customization can be expressed in a few files. The vpc.tf and gke.tf separation keeps networking distinct from Kubernetes. The terraform.tfvars file isolates project_id and region. The versions.tf file enforces a minimum Terraform version.
Cost awareness is built into the workflow. The about ten cents per hour management fee per GKE cluster, plus resource costs, with one free zonal cluster per billing account, informs budgeting for experiments and production.
Benefits of using Terraform with GKE include unified workflow for teams already using Terraform, full lifecycle management for create update and delete without manual API inspection, and a graph of relationships that orders dependencies automatically.
The guide catalog covers Autopilot, Standard zonal, Standard regional, multi-tenant, node pool management, Arm nodes, reserved zonal resources, and node image specification. These patterns provide a foundation for production-grade GKE provisioning with Terraform.