The Google Kubernetes Engine is a fully managed Kubernetes service for deploying, managing, and scaling containerized applications on Google Cloud. The service abstracts the control plane operations that would otherwise require manual etcd maintenance, API server patching, and scheduler tuning, which allows teams to focus on workload definition rather than cluster mechanics. Terraform enters this landscape as an infrastructure-as-code tool that lets you provision and manage cloud infrastructure with declarative configuration. 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.
The intersection of these two systems creates a repeatable path from code to a running, multi-zone GKE cluster with a separately managed node pool, VPC networking, and kubectl configuration emitted as Terraform output. The tutorial material emphasizes a 2-node separately managed node pool GKE cluster using Terraform distributed across multiple zones for high availability, followed by kubectl configuration using Terraform output to deploy a Kubernetes dashboard on the cluster. The emphasis on separate node pools reflects a design decision to allow customization of the Kubernetes cluster profile, which is useful if some Pods require more resources than others.
The operational reality of this setup includes cost awareness. 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. That warning sits alongside the practical benefits of using Terraform instead of the built-in GCP provisioning processes via UI, SDK, or CLI. While you could use the built-in GCP provisioning processes for GKE clusters, Terraform provides you with several benefits.
Unified Workflow is one of those benefits. 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 is another benefit. 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 is the third benefit. Terraform understands dependency relationships between resources.
GKE Service Characteristics and Terraform Fit
The Google Kubernetes Engine is a fully managed Kubernetes service for deploying, managing, and scaling containerized applications on Google Cloud. That definition carries an impact for teams that would otherwise operate self-managed Kubernetes. The managed nature reduces control plane operational burden, while Terraform adds a declarative, version-controlled layer on top of the managed service. The combination allows infrastructure changes to be reviewed, tested, and rolled back.
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. This statement anchors the production readiness argument. 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 declarative and configuration-oriented syntax of Terraform is central to this fit. 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.
How Terraform Works with GKE Resources
Terraform works through a small set of steps that translate human intent into API calls. The following steps explain 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 plancommand, which evaluates your configuration and generates an execution plan. You can review the plan and make changes as needed
Each resource block describes one or more infrastructure objects, such as virtual networks or compute instances. That resource block model means a VPC, subnet, GKE cluster, and node pool each become discrete, addressable objects in state. The state file becomes the source of truth for drift detection.
The Terraform provider for Google Cloud exposes GKE resources through the provider. 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.
Provisioning Workflow from the HashiCorp Tutorial
The HashiCorp tutorial walks through a concrete provisioning sequence that begins with authentication and ends with kubectl configuration.
First, credentials are established for Terraform to access Google Cloud. Finally, add your account to the Application Default Credentials. This will allow Terraform to access these credentials to provision resources on GCloud.
gcloud auth application-default login
The command is run in a terminal and creates local ADC credentials that the Google provider uses.
Next, the example configuration is obtained. 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.
The repository layout is explicit and minimal. 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. 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 vpc.tf and gke.tf reflects a dependency graph where the GKE cluster requires network resources to exist first. Terraform understands dependency relationships between resources, which means the apply order is inferred from references rather than manually scripted.
Node Pool Configuration and High Availability Design
The tutorial targets a 2-node separately managed node pool GKE cluster using Terraform. This GKE cluster will be distributed across multiple zones for high availability. Distributing nodes across zones reduces the blast radius of zonal failures and aligns with Google Cloud's recommendation for production workloads.
Separately managed node pools are recommended over the default node pool because they decouple cluster control plane lifecycle from worker node lifecycle. The number of nodes in the node pool is defined also defined here, in gke.tf. That allows scaling decisions to be codified and version controlled rather than performed through console clicks.
The high availability design has cost implications. Multi-zone deployment increases availability but also increases the number of Compute Engine instances that must be billed. Combined with the management fee of about ten cents per hour per GKE cluster, the financial model requires explicit tracking. One zonal cluster per billing account is free, which provides a low-cost experimentation path, but the multi-zone tutorial will incur charges.
Production Prerequisites and API Enablement
A production-ready GKE cluster with Terraform requires prerequisites that ensure both tooling and permissions are correct.
Prerequisites
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 Terraform version requirement of 1.5 or later installed reflects the need for modern provider schemas and HCL features. The Google Cloud Terraform provider configured ensures that authentication and project targeting are established before any plan runs.
The Kubernetes Engine API enabled in your project is a hard requirement. Without the API enabled, the provider cannot create clusters and node pools.
The service account with at least the Kubernetes Engine Admin role provides the IAM permissions needed for cluster creation, node pool management, and network provisioning.
Enable the required APIs:
gcloud services enable \
container.googleapis.com \
compute.googleapis.com \
binaryauthorization.googleapis.com
Enable the APIs needed for GKE. The container.googleapis.com API is the core GKE control plane. compute.googleapis.com is required for the underlying Compute Engine instances and VPC resources. binaryauthorization.googleapis.com is included for workload security policy enforcement.
Creating the VPC Network
GKE clusters need a VPC network. The VPC network provides the network foundation for pod IP allocation, service CIDR, and node-to-control-plane connectivity. Provisioning a dedicated VPC for GKE isolates the cluster from other projects and allows fine-grained firewall rules.
Terraform-Based Guides for GKE
The Google Cloud documentation catalogs multiple Terraform-based how-to guides and tutorials for GKE. The following table lists Terraform resources available for GKE and the guide catalog.
| 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 |
These guides cover the spectrum from Autopilot to Standard, zonal to regional, and specialized node types. The catalog reinforces the idea that Terraform can express both simple and advanced GKE configurations.
What's next pointers in the documentation include:
- Terraform code samples for GKE
- Terraform on Google Cloud documentation
- Google Cloud provider documentation in HashiCorp
- Infrastructure as code for Google Cloud
These links provide onward navigation for deeper provider reference and sample code.
Benefits of Unified Infrastructure Management
The benefits of using Terraform with GKE extend beyond provisioning.
Unified Workflow means GKE clusters fit into an existing Terraform workflow for Google Cloud. 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. This unification reduces context switching between IaC and manual console work.
Full Lifecycle Management means Terraform doesn't only create resources, it updates, and deletes tracked resources without requiring you to inspect the API to identify those resources. That property enables drift detection and automated remediation.
Graph of Relationships means Terraform understands dependency relationships between resources. The dependency graph ensures VPC and subnet creation precedes GKE cluster creation, and node pool creation follows cluster creation. The graph also enables safe destroy ordering.
The declarative nature of Terraform means 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. This reduces imperative error paths.
Cost, Risk, and Operational Considerations
The warning about charges about ten cents per hour management fee for each GKE cluster, in addition to the cluster's resource costs, is operationally significant. Teams that run multiple clusters for development, staging, and production must multiply this fee by cluster count. One zonal cluster per billing account is free, which creates a safe sandbox for learning, but the tutorial's multi-zone, two-node design will exceed the free quota.
A misconfigured cluster can be insecure, expensive, or both. Configuration options such as node pool size, machine type, disk size, network policies, and auto-upgrade settings all affect cost and security posture. Terraform's version control allows peer review of these decisions before they are applied.
The separately managed node pool design allows you to customize your Kubernetes cluster profile. That customization power is also a risk if defaults are not locked down. Production guides therefore emphasize explicit configuration of node images, security patches, and authorized networks.
Contextual Connections Across the Workflow
The HashiCorp tutorial repository learn-terraform-provision-gke-cluster contains four files used to provision a VPC, subnets and a GKE cluster. The VPC file outputs region. The GKE file provisions a GKE cluster and a separately managed node pool. The tfvars file holds project_id and region. The versions file pins Terraform version.
These files map directly to the prerequisites: Terraform 1.5 or later installed, provider configured, API enabled, and service account with Kubernetes Engine Admin role. The gcloud auth application-default login step satisfies authentication for the provider. The gcloud services enable step satisfies API enablement.
The node pool configuration of two nodes across multiple zones implements high availability. The Terraform plan command evaluates the configuration and generates an execution plan. You can review the plan and make changes as needed before applying.
Once applied, Terraform output can be used to configure kubectl and deploy a Kubernetes dashboard on the cluster. This closes the loop from infrastructure provisioning to workload deployment.
Conclusion
The combination of GKE as a fully managed Kubernetes service and Terraform as an infrastructure-as-code orchestrator creates a durable, auditable path from project definition to running cluster. The HashiCorp tutorial demonstrates a minimal but complete workflow: authenticate via Application Default Credentials, clone the learn-terraform-provision-gke-cluster repository, edit terraform.tfvars with project_id and region, and apply vpc.tf and gke.tf to create a VPC, subnet, GKE cluster, and a separately managed two-node node pool distributed across zones for high availability. The management fee of about ten cents per hour per cluster and the free one zonal cluster per billing account shape cost expectations, while the prerequisites of Terraform 1.5 or later, provider configuration, API enablement, and Kubernetes Engine Admin role ensure safe execution.
Production adoption requires more than the tutorial. 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. The decision points that actually matter include VPC isolation, node pool separation, zonal versus regional placement, node image pinning, and API enablement for container.googleapis.com, compute.googleapis.com, and binaryauthorization.googleapis.com.
The broader catalog of Terraform-based guides for GKE shows the breadth of achievable configurations: Autopilot clusters, Standard zonal and regional clusters, multi-tenant clusters, node pool management, Arm nodes, reserved zonal resources, and node image specification. Each guide builds on the same core principles: describe the infrastructure you want in a Terraform configuration file, run terraform plan to generate an execution plan, and apply to provision resources. Terraform understands dependency relationships between resources, provides unified workflow with other Google Cloud resources, and offers full lifecycle management for create, update, and delete operations.
The operational impact is a shift from imperative console clicks to declarative, peer-reviewed code. The cost model remains visible through the management fee and resource consumption, and the high availability design of multi-zone node pools trades cost for resilience. The separately managed node pool pattern allows customization of the Kubernetes cluster profile for workloads with varying resource needs, while the VPC network requirement ensures network isolation and security.