This page explains the two modes of operation and main cluster configuration choices you can make when creating a cluster in Google Kubernetes Engine (GKE). As a rule, the choices discussed here cannot be changed after a cluster is created. These choices impact a cluster's availability, version stability, and network.
This page is for Admins and architects who define IT solutions and system architecture in accordance with company strategy. To learn more about common roles and example tasks that we reference in Google Cloud content, see Common GKE Enterprise user roles and tasks.
Plan and design your cluster configuration with your organization's Admins and architects, Cloud architects, Network administrators, or any other team responsible for defining, implementing, and maintaining the GKE and Google Cloud architecture.
Level of cluster management
Before we can talk about types of clusters, it's important to understand the level of flexibility, responsibility, and control that you require for your cluster. The level of control that you require determines the mode of operation to use in GKE, and the cluster configurations that you need to make.
Modes of operation
When you create a cluster in GKE, you do so by using one of the following modes of operation:
Autopilot: Provides a fully-provisioned and managed cluster configuration. For clusters created using the Autopilot mode, the cluster configuration options are made for you. Autopilot clusters are pre-configured with an optimized cluster configuration that is ready for production workloads.
Standard: Provides advanced configuration flexibility over the cluster's underlying infrastructure. For clusters created using the Standard mode, you determine the configurations needed for your production workloads.
For more information about these modes, and to learn more about Autopilot, see the Autopilot overview.
Cluster configuration choices
Based on the operation mode you chose, you then select which configurations you require for your cluster. In Autopilot mode, most of the choices are made for you. In Standard mode, you need to select the configurations that work best for your production workloads.
| Cluster choices | Mode | |
|---|---|---|
| Autopilot | Standard | |
| Availability type | Regional | Regional or Zonal |
| Version | Release channel | Release channel, Default, or Specific |
| Network routing | VPC-native | VPC-native or Routes-based |
| Network isolation | Private or Public | Private or Public |
| Kubernetes features | Production | Production or Alpha |
Cluster availability type
With GKE, you can create a cluster tailored to the availability requirements of your workload and your budget. The types of available clusters include: regional and zonal (single-zone or multi-zonal).
Clusters created in the Autopilot mode are regional.
To help you choose which available cluster to create in the Standard mode, see Choosing a regional or zonal control plane.
After you create a cluster, you cannot change it from regional to zonal or from zonal to regional. Instead, you must create a new cluster then migrate traffic to it.
Regional clusters
A regional cluster has multiple replicas of the control plane, running in multiple zones within a given region. Nodes in a regional cluster can run in multiple zones or a single zone depending on the configured node locations. By default, GKE replicates each node pool across three zones of the control plane's region. When you create a cluster or when you add a new node pool, you can change the default configuration by specifying the zone(s) in which the cluster's nodes run. All zones must be within the same region as the control plane.
Use regional clusters to run your production workloads, as they offer higher availability than zonal clusters.
To create a regional cluster in the Standard mode, see Creating a regional cluster.
To create a regional cluster in the Autopilot mode, see Creating an Autopilot cluster.
Zonal clusters
Zonal clusters have a single control plane in a single zone. Depending on your availability requirements, you can choose to distribute your nodes for your zonal cluster in a single zone or in multiple zones.
To create a zonal cluster in the Standard mode, see Creating a zonal cluster.
For production workloads, use regional clusters because they offer higher availability than zonal clusters. For development environments, use regional clusters with zonal node pools at the same costs.
Single-zone clusters
A single-zone cluster has a single control plane running in one zone. This control plane manages workloads on nodes running in the same zone. If you run a workload in a single zone, this workload is unavailable in the event of a zonal outage.
Multi-zonal clusters
A multi-zonal cluster has a single replica of the control plane running in a single zone, and has nodes running in multiple zones. During an upgrade of the cluster or an outage of the zone where the control plane runs, workloads still run. However, the cluster, its nodes, and its workloads cannot be configured until the control plane is available. Multi-zonal clusters balance availability and cost for consistent workloads. If you want to maintain availability and the number of your nodes and node pools are changing frequently, consider using a regional cluster. If you run a workload in multiple zones and there is a zonal outage, the workload is disrupted in that zone but remains available in other zones.
Release channels and cluster versions
Choose a release channel for GKE to select versions for your cluster with your chosen balance between feature availability and stability. Use maintenance windows and exclusions to control the timing and scope of automatic upgrades.
With release channels, GKE picks versions for a cluster with your chosen balance between feature availability and stability. When you create a cluster, you can choose which release channel you want. New clusters are enrolled in the Regular release channel, by default. You can also choose a specific version, if necessary.
Autopilot clusters always use release channels. Standard clusters use release channels by default, however you can choose not to enroll your cluster in a release channel.
GKE automatically upgrades all clusters over time, regardless of release channel enrollment. GKE automatically upgrades the cluster's control plane and its nodes when an upgrade is available in that release channel. You can control the timing and scope of upgrades with maintenance windows and exclusions.
For information regarding upcoming automatic upgrades, see the GKE release notes.
Cluster networking
When creating a GKE cluster, you can specify the network routing mode, and how to isolate your cluster network.
VPC-native and routes-based clusters
In Google Kubernetes Engine, clusters can be distinguished according to the way they route traffic from one Pod to another Pod. A cluster that uses Alias IPs is called a VPC-native cluster. A cluster that uses Google Cloud routes is called a routes-based cluster.
For details, see the Default cluster network mode chart.
Use the VPC-native network mode for your clusters. This is the default for clusters created in the Autopilot mode.
Network isolation choices
By default, you can configure access from public networks to your cluster's workloads. Routes are not created automatically. Private clusters assign internal addresses to Pods and nodes, and workloads are completely isolated from public networks.
To create a private cluster, see Creating a private cluster.
Use Cloud NAT to provide GKE Pods with access to resources with public IP addresses. Cloud NAT improves the overall security posture of the cluster because Pods are not directly exposed to the internet, but are still able to access internet-facing resources.
Kubernetes features
New features in Kubernetes are listed as Alpha, Beta, or Stable, depending upon their status in development. In most cases, Kubernetes features that are listed as Beta or Stable are included with GKE clusters. Kubernetes Alpha features are available in special GKE alpha clusters.
Alpha features are not available in clusters created in the Autopilot mode.
Alpha cluster
An alpha cluster has all Kubernetes alpha APIs (sometimes called feature gates) enabled. You can use alpha clusters for early testing and validation of Kubernetes features. Alpha clusters are not supported for production workloads, cannot be upgraded, and expire within 30 days.
To create an alpha cluster in the Standard mode, see Creating an alpha cluster.