Introduction
GKE Autopilot represents a distinct mode of operation for Google Kubernetes Engine where the provisioning and management of the underlying infrastructure is handled by Google Cloud. The Terraform Google Kubernetes Engine module documents Autopilot cluster functionality and covers available Autopilot module variants, key features, configuration options and usage patterns. Autopilot clusters are enabled in the module using the enableautopilot = true configuration flag in the googlecontainer_cluster resource. In Autopilot mode Google manages the node infrastructure, removing the need to manually configure node pools, while optimizing resource utilization and costs.
The shift from Standard mode to Autopilot changes the operational contract between user and platform. In Standard mode the user manages node pools and machine types. In Autopilot the user deploys workloads and Google figures out the infrastructure. The combination of Autopilot with Workload Identity for secure GCP service access and private networking for security produces a production-ready Kubernetes cluster with minimal operational overhead. Setting this up through Terraform gives reproducible infrastructure that can be version controlled and applied across environments.
GKE Autopilot is Google's fully managed Kubernetes offering. Unlike Standard mode where you manage node pools and machine types, Autopilot handles all of that for you. You deploy workloads, and Google figures out the infrastructure. The Terraform module provides two variants of Autopilot clusters: beta-autopilot-private-cluster and beta-autopilot-public-cluster. Both modules support beta features of GKE through the google-beta provider, allowing access to the latest capabilities that may not yet be generally available.
Autopilot Mode Fundamentals And Terraform Enablement
GKE Autopilot is a mode of operation for Google Kubernetes Engine clusters that simplifies Kubernetes management by handling the provisioning and management of the underlying infrastructure.
The impact for operators is the removal of node pool sizing decisions, machine type selection, and manual node repairs. Teams no longer calculate node requirements or maintain node images. The platform performs auto health-monitoring, checks, compute calculation, and auto-repair.
The contextual layer ties this to Terraform usage. The Terraform GKE module surfaces Autopilot through the enableautopilot = true flag. The flag is placed inside the googlecontainer_cluster resource. The module documentation notes that while using Autopilot, you do not have to specify the number of nodes required; they will be automatically calculated for you.
Provider requirements are explicit. In order to use the GKE Autopilot, you will need:
- A Google Cloud account
- A configured gcloud SDK
- The Google Cloud Terraform provider version 3.63.0 or higher
The provider version requirement is a hard gate. Use of an earlier provider version will not recognize the enable_autopilot argument and will fail plan or apply. The version 3.63.0 or later requirement was introduced when HashiCorp announced support for Google Kubernetes Engine Autopilot in Terraform, released in February 2021.
GKE Autopilot gives you a hands-off approach to using Kubernetes on Google Cloud by eliminating node management operations and maximizing your cluster efficiency.
The platform provides:
- A completely automated Kubernetes platform
- Auto health-monitoring, checks, compute calculation, and auto-repair
- Efficient per-pod billing
Autopilot helps shift several site reliability engineering responsibilities from your team to Google Cloud, specifically for nodes and control planes where they help with cluster provisioning and maintenance.
Module Variants Private Versus Public Autopilot
The Terraform GKE module provides two variants of Autopilot clusters.
- beta-autopilot-private-cluster
Creates a private Autopilot cluster with the control plane isolated from the public internet
beta-autopilot-public-cluster
- Creates a standard Autopilot cluster with publicly accessible endpoints
Both modules support beta features of GKE through the google-beta provider, allowing access to the latest capabilities that may not yet be generally available.
Sources: modules/beta-autopilot-private-cluster/cluster.tf22-23 modules/beta-autopilot-public-cluster/cluster.tf22-23 modules/beta-autopilot-private-cluster/cluster.tf158 modules/beta-autopilot-public-cluster/cluster.tf158
The primary difference between private and public Autopilot clusters is the networking configuration and variable availability.
| Variable | Private Module | Public Module | Default Value |
|---|---|---|---|
| enableprivateendpoint | ✓ | ✗ | false |
| enableprivatenodes | ✓ | ✗ | true |
| masteripv4cidr_block | ✓ | ✗ | null |
| privateendpointsubnetwork | ✓ | ✗ | null |
| masterglobalaccess_enabled | ✓ | ✗ | true |
The private variant enables control plane isolation. The public variant exposes endpoints to the public internet by default. The choice between variants determines whether masteripv4cidrblock and privateendpoint_subnetwork can be configured.
Networking Configuration Private Endpoint Private Nodes Master CIDR
Private Autopilot clusters are created with the control plane isolated from the public internet. The enableprivateendpoint variable controls whether the private endpoint is enabled. The enableprivatenodes variable controls node private visibility and defaults to true.
The masteripv4cidrblock variable allows definition of the control plane CIDR. The privateendpointsubnetwork variable allows mapping of the private endpoint to a specific subnetwork. The masterglobalaccessenabled variable controls global access to the master and defaults to true.
In Autopilot mode Google manages the node infrastructure, removing the need to manually configure node pools, while optimizing resource utilization and costs. The networking configuration therefore focuses on control plane access and pod network integration rather than node pool subnets.
The impact for security teams is that private clusters reduce attack surface by requiring access through private networks or authorized networks. The contextual layer shows that private networking pairs with Workload Identity for secure GCP service access.
Workload Identity And Private Network Integration
GKE Autopilot is Google's fully managed Kubernetes offering. Unlike Standard mode where you manage node pools and machine types, Autopilot handles all of that for you. You deploy workloads, and Google figures out the infrastructure.
Combined with Workload Identity for secure GCP service access and private networking for security, you get a production-ready Kubernetes cluster with minimal operational overhead.
The module example shows projectid, region, clustername, authorizednetworks, and workloadservice_accounts.
The authorized_networks block restricts control plane access:
{
cidr_block = "203.0.113.0/24"
display_name = "Office VPN"
}
The workloadserviceaccounts block maps Kubernetes service accounts to GCP roles:
workload_service_accounts = {
api-service = {
namespace = "default"
k8s_sa = "api-service"
gcp_roles = [
"roles/cloudsql.client",
"roles/secretmanager.secretAccessor",
]
}
worker-service = {
namespace = "workers"
k8s_sa = "worker"
gcp_roles = [
"roles/storage.objectViewer",
"roles/pubsub.subscriber",
]
}
}
This pattern eliminates long-lived service account keys. Pods assume GCP identities via Workload Identity federation. The impact is reduced credential leakage risk and auditable access. The contextual layer ties this to Autopilot because Autopilot nodes are managed by Google, so node-level IAM is abstracted and Workload Identity becomes the primary identity mechanism for workloads.
Provider Requirements And Configuration Workflow
GKE Autopilot can be enabled for your Kubernetes cluster by adding the variable enable_autopilot = true to your GKE Terraform configuration.
The example workflow for enabling GKE Autopilot on a Kubernetes cluster using Terraform is:
First, create a Terraform file that contains the GKE cluster.
Gke.tf
:
Write out a Terraform configuration to provision a GKE Autopilot cluster using google_container_cluser and enable Autopilot for that cluster. Please note that while using Autopilot, you do not have to specify the number of nodes required; they will be automatically calculated for you.
The configuration fragment is:
```
variable "gkeusername" {
default = ""
description = "gke username"
}
variable "gkepassword" {
default = ""
description = "gke password"
}
GKE cluster
resource "googlecontainercluster" "primary" {
name = "${var.projectid}-gke"
location = var.region
network = googlecomputenetwork.vpc.name
subnetwork = googlecompute_subnetwork.subnet.name
Enabling Autopilot for this cluster
enable_autopilot = true
}
```
Make sure to choose the correct version of the Google Cloud Terraform provider for your cluster: It must be 3.63.0, or later
The network and subnetwork references tie the cluster to a VPC. The name interpolation uses projectid. No node pool blocks are required. The enableautopilot flag instructs the API to operate in Autopilot mode.
The impact for CI/CD pipelines is that the same configuration can be applied across dev, staging, and production by changing variables. The contextual layer connects to reproducibility: Setting this up through Terraform gives you reproducible infrastructure that you can version control and apply across environments.
Automation Maintenance Windows And SRE Shift
GKE Autopilot provides management of nodes, pre-configuration of clusters, auto-scaling, auto-upgrades and security by Google Cloud so you can focus just on the development and not on the underlying infrastructure.
In the automation page, you can adjust the maintenance window after cluster creation.
GKE Autopilot is now active and providing automated node management, improved utilization, security, and reduced cost of maintenance. Users can leverage Google Cloud’s SRE tooling to maintain their nodes and pods.
The shift of SRE responsibilities means teams no longer schedule node upgrades or patch cycles. Google performs auto health-monitoring, checks, compute calculation, and auto-repair. The maintenance window adjustment provides a limited control point for compliance windows.
Google Cloud offers a 99.95% SLA for the control plane of its GKE Autopilot clusters, and a 99.9% SLA for GKE Autopilot pods, while reducing the overall operational load required for managing the clusters.
The SLA commitments quantify the operational risk transfer. The 99.95% control plane SLA and 99.9% pod SLA are platform level guarantees that apply once Autopilot is enabled. The impact is that service level expectations can be documented without building custom monitoring for node health.
Operational Impact Cost Utilization SLA
GKE Autopilot gives you a hands-off approach to using Kubernetes on Google Cloud by eliminating node management operations and maximizing your cluster efficiency.
The key difference between Autopilot and Standard GKE clusters is that with Autopilot:
- Google manages node infrastructure
- No manual node pool configuration required
- Resource utilization is optimized by Google
Efficient per-pod billing changes cost modeling from node-hour to pod-hour. Teams pay for actual pod resource usage rather than idle node capacity.
The contextual layer connects to the module variants. Private clusters add networking controls but do not change the billing model. Public clusters provide easier access for initial testing but expose endpoints.
A comparison of both standard and autopilot modes can be found in Google Cloud’s GKE documentation.
The operational load reduction is explicit: Autopilot helps shift several site reliability engineering responsibilities from your team to Google Cloud’s, specifically for nodes and control planes where they help with cluster provisioning and maintenance.
Conclusion
GKE Autopilot with Terraform gives you a production-ready Kubernetes cluster with minimal operational burden. The enableautopilot = true flag is the single configuration point that moves node management, auto-scaling, auto-upgrades and security to Google Cloud. The Terraform Google Kubernetes Engine module surfaces this through beta-autopilot-private-cluster and beta-autopilot-public-cluster variants, each using the google-beta provider for access to pre-GA capabilities. Private variants expose enableprivateendpoint, enableprivatenodes, masteripv4cidrblock, privateendpointsubnetwork and masterglobalaccess_enabled while public variants expose a simplified endpoint model.
Provider version 3.63.0 or higher is required, and a configured gcloud SDK and Google Cloud account are prerequisites. Workload Identity integration and private networking are the recommended companion patterns for secure production use. The combination yields automated node management, improved utilization, security, and reduced cost of maintenance with a 99.95% control plane SLA and 99.9% pod SLA.
The workflow remains reproducible through Terraform. The same googlecontainercluster resource with enable_autopilot = true, network and subnetwork references, and project-scoped naming can be applied across environments. Maintenance windows can be adjusted post-creation, and SRE responsibilities for nodes and control planes are absorbed by Google Cloud.