About cluster configuration choices

This page explains the main cluster configuration choices you can make whencreating a cluster in Google Kubernetes Engine (GKE), whether you're using theGoogle Cloud console, the Google Cloud CLI, or Terraform. These options let youcustomize a wide range of cluster attributes and behavior to meet your needs,from whether the cluster is accessible from public networks to how you want itto receive version upgrades.

Many of the options discussed in this guidecan't be changed after a clusteris created. These include choices that affect a cluster'savailability andnetwork. If youdoneed to change these options, you must create a new cluster then migrate trafficto it, which might be disruptive.

Best practice:

Because many cluster configuration options can't be changed after cluster creation, plan and design yourcluster configuration with your organization's Admins and architects,Cloud architects, Network administrators, or any other team responsiblefor defining, implementing, and maintaining the GKE andGoogle Cloud architecture.

This page is for Admins and architects who define IT solutions and systemarchitecture in accordance with company strategy. To learn more about commonroles and example tasks that we reference in Google Cloud content, seeCommon GKE user roles and tasks.

Before reading this page you should be familiar with the following, as well asbasic Kubernetesconcepts:

Level of cluster management

Before discussing cluster options, it's important to understand the level offlexibility, responsibility, and control that you require for your cluster. Thelevel of control that you require determines the mode of operation to use inGKE, and thecluster configuration choicesthat you need to make.

When you create a cluster in GKE, you do so by using one ofthe following modes of operation:

  • Autopilot (recommended): Provides a fully-provisioned andmanaged cluster configuration. Autopilot clusters arepre-configured with an optimized cluster configuration that is ready forproduction workloads.

  • Standard: Provides advanced configuration flexibility over thecluster's underlying infrastructure. For clusters created using theStandard mode, you determine the configuration needed for yourproduction workloads.

For more information about these modes, and to learn more aboutAutopilot, seeGKE modes ofoperation and theAutopilotoverview.

You can find a detailed side-by-side comparison of the two modes inCompareGKE Standard andAutopilot.

Cluster configuration choices

After you have chosen a mode of operation, you then select the configuration yourequire for your cluster. Because Autopilot clusters are more fullymanaged and configured by Google Cloud than Standard clusters, theyhave fewer available configuration choices.

Configuration options for all clusters fall into the following categories:

  • Name and other metadata: Each cluster must have an identifying name thatis unique within its project. You can also optionally add a clusterdescription and labels.
  • Availability and scalability: Specify where you want your clustercontrol plane and nodes to run, and if you want multiple control planereplicas. All Autopilot clusters areregional, which means theyhave multiple control planes across multiple compute zones in a Google Cloudregion.
  • Fleet membership: Choose whether you want your cluster to be a member ofa fleet.
  • Networking: Networking options including the Virtual Private Cloud (VPC)network and subnet the cluster is in, and whether you want your cluster tobe accessible from public networks.
  • Versions and upgrade management: Userelease channels to choose yourpreferred balance between new features and stability when upgrading thiscluster's software, and set maintenance windows and exclusions to choosewhen upgrades can and can't occur.
  • Security: This includes whether the cluster uses Workload Identity Federation for GKEand the service account used by the cluster's nodes to authenticate toGoogle Cloud.
  • Cluster features: Enable and configure additional GKE andGoogle Cloud features for this cluster, including backups and observability.Standard mode also lets you create short-livedalpha clusters totry out alpha Kubernetes features.

In addition to these, Standard clusters also have options in thefollowing category:

  • Node pools: Specify details about your cluster's nodes, including nodepools, node operating system, and node sizing.

The following sections look at some of these categories in more detail,particularly those with options where you can't change the setting after youcreate your cluster. For a complete list of configuration options, seeConfiguration reference.

The following table compares available options in some key areas forAutopilot and Standard clusters:

Cluster choicesMode
AutopilotStandard
Availability typeRegionalRegional orZonal
Release channelRapid,Regular, orStableAny channel
Cluster versionsDefault or another available versionDefault or another available version
Network routingVPC-nativeVPC-native orRoutes-based
Network isolationCustomizableCustomizable
Kubernetes featuresProductionProduction orAlpha

Cluster availability

With GKE, you can create a cluster tailored to theavailability requirements of your workload and your budget. You can choosebetween regional clusters that have multiple control plane replicas acrossmultiple compute zones in a Google Cloud region, or zonal clusters with a singlecontrol plane in a single zone. Autopilot clusters are always regional.

To help you choose which cluster type to create in Standard mode, seeChoosing a regional or zonal controlplane.

These settings can't be updated after cluster creation: a zonal cluster can'tbecome a regional cluster, and a regional cluster can't become a zonal cluster.

Best practice:

For production workloads,use regional clusters because they generally offer higher availability than zonalclusters. For development environments, use regional clusters with zonal nodepools. A cluster with a regional control plane and zonal node pools has the samecosts as a zonal cluster.For more information about region-specific considerations, seeGeography and regions.

Regional clusters

Aregional cluster hasmultiple replicas of the control plane, running in multiple zones within yourspecified Google Cloudregion. You always need tospecify a region when creating an Autopilot or other regional cluster.

For regional Standard clusters only, you can also choose in which zonesthe cluster's nodes run. Nodes in a regional cluster can run in multiple zonesor a single zone depending on the configured node locations. By default,GKE replicates each node pool across three zones of the controlplane's region. When you create a regional Standard cluster or when you add anew node pool, you can change the default configuration by specifying thezone(s) in which the cluster's nodes run. All zones must be within the sameregion as the control plane.

Use regional clusters to run your production workloads, as they offer higheravailability than zonal clusters.

You can't change a regional cluster's region after cluster creation.

Zonal clusters

Zonal clusters have a single control plane in a singlezone. Workloads still run during a clusterupgrade or an outage of the zone where the control plane runs. However, thecluster, its nodes, and its workloads can't be configureduntil the control plane is available. Depending on your workload availabilityrequirements, you can choose to distribute your nodes for your zonal cluster ina single zone or in multiple zones.

To create a zonal cluster, seeCreating a zonalcluster.

Location and distribution of the nodes

Whether you use regional or zonal clusters, you can precisely determine the locationand distribution of your nodes across zones. You canconfigure the default zones for all future node pools, as well as assign orchange the specific zones for nodes within existing node pools.

Single-zone clusters

A single-zone cluster—which can be a regional or zonal cluster—runs workloads onnodes located in only onezone. If that zoneexperiences an outage, all workloads become unavailable.

Zonal clusters are created by default as single-zone clusters, butyou can update this configuration to multi-zonal clusters.

Multi-zonal clusters

A multi-zonal cluster—which can be a regional or zonal cluster—enhancesworkload availability by distributing nodes across multiplezones within a single region. This lets yourun workloads across multiple zones in a region. If you run aworkload in multiple zones and a zonal outage occurs, the workload is disruptedin that zone but remains available in other zones.

Distributing GKE nodes across multiple zones can incur charges forcross-zone network egress when nodes need to communicate with peerslocated in a different zone within the region.

Regional clusters are created by default asmulti-zonal clusters, but you can update this configuration to single-zone clusters.

AI zones

AI zones are specialized zones used for AI/ML training and inference workloads. These zones provide significantML accelerator capacity. For more information, see theAI zones documentation.

Note: In this document and the GKE documentation, "standard zones" or "zones" refer to non-AI zones within a Google Cloud region.

Before you use an AI zone in GKE, consider the followingcharacteristics:

By default, GKE doesn't deploy your workloads in AI zones. To usean AI zone, you must configure one of the following options:

  • (Recommended) ComputeClasses: set your highest priority to requeston-demand TPUs in an AI zone. ComputeClasses help you define a prioritizedlist of hardware configurations for your workloads. For an example, seeAbout ComputeClasses.
  • Node auto-provisioning: use anodeSelector ornodeAffinity in your Podspecification to instruct node auto-provisioning to create a node pool in theAI zone. If your workload doesn't explicitly target an AI zone, nodeauto-provisioning considers only standard zones or zones from--autoprovisioning-locationswhen creating new node pools.This configuration ensures that workloads that don't run AI/ML models remain in standardzones unless you explicitly configure otherwise. For an example of a manifestthat uses anodeSelector, seeSet the default zones for auto-created nodes.
  • GKE Standard: if you directly manage your nodepools, use an AI zone in the--node-locations flag when you create a nodepool. For an example, seeDeploy TPU workloads in GKE Standard.

Fleet membership

If your organization uses multiple clusters, you can simplify multi-clustermanagement by adding the clusters to afleet: a logical grouping of Kubernetesclusters. Creating a fleet helps your organization uplevel management fromindividual clusters to entire groups of clusters, and lets you use fleet-enabledfeatures such asMulti Cluster Ingress,Config Sync, andPolicy Controller.

Although you can add clusters to a fleet at any time,we strongly recommend registering new clusters to a fleet duringcluster creation. This is because these "born in the fleet" clusters are createdwith your chosen fleet-level default settings for a number of enterprisefeatures, and with recommended logs and metrics already enabled. You can learnmore about these in the following guides:

This settingcan be updated after cluster creation to register or unregisterthe cluster, although we don't recommend moving clusters with live workloadsfrom one fleet to another.

You can learn much more about adding clusters to fleets inCreate fleets tosimplify multi-clustermanagement.

Networking settings

When creating a GKE cluster, you can specify a number ofnetworking settings, including the network the cluster is in, the networkrouting mode, and whether you want your cluster nodes to be accessible frompublic networks.

If you are not a network administrator, you should consult with yourorganization's Networking specialists before creating a production-readycluster, as many of these options can't be changed after cluster creation. Ifyouare a network administrator, you can find out much more aboutGKE networking inAbout GKEnetworking, with bestpractices for networking options inBest practices for GKEnetworking. This sectiondescribes only a subset of our possible networking options.

Network and subnet

The Virtual Private Cloud (VPC)network that a cluster is indetermines which other Compute Engine resources it is able to communicatewith. By default, GKE clusters are created in your project'sdefault network, though you can choose another network if you or youradministrator have created one. If available, you can specify that you want yourcluster to belong to a specific VPC subnet: again otherwise thedefault subnet is used. You can also optionally specify that you want to use aparticular IP address range within that subnet for your Pods and Services.

These settings can't be updated after cluster creation.

Network isolation choices

You can customize network isolation in your cluster by considering the followingtwo aspects:

  • Access to the control plane: By default, both the internal endpoint andexternal endpoint of the control plane are enabled, and the DNS-based endpointis disabled. You can choose to:

    • Disable both the external and internal endpoint and use only the DNSendpoint.
    • Disable the external endpoint only to prevent access to externalclients.
    • Enable authorized networks to control which IP addresses reach thecontrol plane endpoints.

  • Cluster networking configuration: You can choose to enableprivatenodes in your cluster to completely isolate workloads from public networks.You can enable private nodes for entire clusters or at the node pool (forStandard) or workload (for Autopilot) level. Enablingprivate nodes at the node pool or workload level overrides any nodeconfiguration at the cluster level.

These settings can be changed after cluster creation.

For more information on network isolation, seeAbout customizing networkisolation andCustomizeyour networkisolation.

Best practice:

UseCloud NATto provide GKEPodswith access to resources with public IP addresses. Cloud NAT improves theoverall security posture of the cluster because Pods are not directly exposed tothe internet, but are still able to access internet-facing resources.

VPC-native and routes-based clusters

In GKE, clusters can be distinguished according to the way theyroute traffic from one Pod to another Pod. A cluster that uses Alias IPaddresses is called aVPC-nativecluster. A cluster that usesGoogle Cloud routes is called aroutes-basedcluster.

By default, all new GKE clusters use VPC-nativerouting, which is our recommended option. You can change this setting at clustercreation to create a routes-based cluster in Standard mode only. Thissetting can't be updated after cluster creation.

You can learn more about VPC-native clusters and their benefits,including any special requirements they have, inVPC-nativeclusters.

Best practice:

Use the VPC-native network mode for your clusters. Thisis the default for Autopilot clusters.

Versions and upgrades

Withrelease channels,GKE picks software versions for a cluster with your chosenbalance between feature availability and stability. When you create a cluster,you can choose which release channel you want. New clusters (bothAutopilot and Standard) are enrolled in the Regular releasechannel by default, though you can choose a specific version during clustercreation if required.

Autopilot clustersalways use release channels. Standardclusters use release channels by default, however you can choose not to enrollyour cluster in a release channel (although we don't recommend this because thissetting gives you more limited access to cluster features).

GKE automatically upgrades all clusters over time, regardless ofrelease channel enrollment. GKEautomatically upgrades the cluster's control plane and its nodes as new versionsbecome available in that release channel. You can control the timing and scopeof upgrades withmaintenance windows andexclusions.

You can change a cluster's release channel at any time.

For information regarding upcoming automatic upgrades, see theGKE release notes.

Best practice:

Choose a release channel for GKE to select versions for yourcluster with your chosen balance between feature availability and stability. Usemaintenance windows and exclusions to control the timing and scope of automaticupgrades.

Alpha features (Standard clusters only)

New features in Kubernetes are listed asAlpha, Beta, orStable,depending upon their status in development. In most cases, Kubernetes featuresthat are listed as beta or stable are included with GKEclusters.

If you want to experiment with very new features that are not production ready,alpha features are available in special GKE alpha clusters.Analpha cluster has allKubernetes alpha APIs (sometimes called feature gates) enabled. You can usealpha clusters for early testing and validation of Kubernetes features. Alphaclusters are not supported for production workloads, can't be upgraded or addedto release channels, and expire within 30 days.

Alpha features are not available for Autopilot clusters.

To create an alpha cluster, seeCreating an alphacluster.

Security settings

GKE has a number of security settings that you can specify atcluster creation. These include encryption settings, security features such asBinary Authorization, the service account you want touse for the cluster's nodes (discussed in more detail in the next section), andwhether your cluster uses Workload Identity Federation for GKE.

As with other settings, you should consult with expert colleagues — inthis case, your organization's Security specialists — before creating aproduction-ready cluster. You can learn more about GKEsecurity in ourSecurityoverview andHarden yourcluster security.

Service account for nodes

GKE uses IAM service accounts that are attached to your nodes to run system tasks like logging and monitoring. At a minimum, thesenode service accounts must have theKubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) role on your project. By default, GKE uses theCompute Engine default service account, which is automatically created in your project, as the node service account.

If your organization enforces theiam.automaticIamGrantsForDefaultServiceAccounts organization policy constraint, the default Compute Engine service account in your project might not automatically get the required permissions for GKE.

Note: If your organization was created on or after May 3, 2024, this constraint is enforced by default.

If you use the Compute Engine default service account for other functions in your project or organization, the service account might have more permissions than GKE needs, which could expose you to security risks.

Best practice: Instead of using the Compute Engine default service account, create acustom service account for your nodes to use and give it only the permissions that GKE needs to run system tasks. For more information, seeConfigure a custom node service account.

You can't change the service account for Autopilot mode clusters orfor Standard mode node pools after creation.

Node pool settings (Standard clusters only)

As you know from theCluster administrationoverview andGKE modes ofoperation, if you useAutopilot for your clusters you don't need to worry about nodeconfiguration because GKE configures your nodes for you.Autopilot cluster nodes are all fully managed by GKE andall use the samenode operating system(OS).

If you choose to create a Standard cluster, you can specify a number ofnode options when creating a cluster, including:

  • The name, number, size, andlocation ofnodepools you want to use; nodepools are groups of nodes within your cluster that share a commonconfiguration.
  • The node OS you want to use for new nodes.
  • Whether you want to use ephemeralspotVMs for nodes.
  • The Compute Enginemachine type you wantto use for nodes.
  • The service account you want to use for nodes, as described inSecuritysettings.

Some of a cluster's node pool settings can be changed after cluster creation,though all Standard clusters require at least one node pool. If youdon't specify a number of nodes and machine type when creating aStandard cluster, its default node pool consists of three nodes in eachof the cluster's zones, with the defaultnodeimagecos_containerd, and ageneral-purpose machine type.

You can learn more about node pool configuration inAbout nodepools andAdd and manage nodepools.

Configuration reference

Find a complete list of possible configuration options in the followingreference guides:

What's next

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2026-02-18 UTC.