This page explains the main types of clusters you can create 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.
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.
|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: zonal (single-zone or multi-zonal) and regional.
To help you choose which available cluster to create in the Standard mode, see Choosing a regional or zonal control plane.
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.
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.
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.
A regional cluster has multiple replicas of the control plane, running in multiple zones within a given region. Nodes also run in each zone where a replica of the control plane runs. Because a regional cluster replicates the control plane and nodes, it consumes more Compute Engine resources than a similar single-zone or multi-zonal cluster.
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.
When you create a cluster, you can choose the cluster's specific Kubernetes version or you can make choices about its overall mix of stability and features.
Regardless of how you manage your cluster's version, it is recommended that you enable auto-upgrade for the cluster and its nodes. GKE automatically upgrades nodes for Autopilot clusters.
If you know the level of stability you need for a given cluster, you can enroll the cluster in a release channel. By default, new clusters are enrolled in the Regular release channel. Google automatically upgrades the cluster and its nodes when an update is available in that release channel. The Rapid channel receives multiple updates a month, while the Stable channel only receives a few updates a year.
If you do not use a release channel or choose a cluster version, the current default version is used. The default version is selected based on usage and real-world performance, and is changed regularly. While the default version is the most mature one, other versions being made available are GA versions that passed internal testing and qualification. Changes to the default version are announced in a release note.
If you know that you need to use a specific supported version of Kubernetes for a given workload, you can specify it when creating the cluster.
If you do not need to control the specific patch version you use, consider enrolling your cluster in a release channel instead of managing its version directly.
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.
VPC-native is the recommended network mode for new clusters. This is the default for clusters created in the Autopilot mode.
The default cluster network mode depends on the way the cluster is created in the Standard mode. For details, see the Default cluster network mode chart.
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.
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.
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.