This page explains the main types of clusters you can create in Google Kubernetes Engine. As a rule, the choices discussed here can't be changed after a cluster is created. These choices impact a cluster's availability, version stability, whether the cluster is VPC-native or routes-based, and isolation of workloads.
Cluster availability choices
With GKE, you can create a cluster tailored to the availability requirements of your workload and your budget.
A single-zone cluster has a single control plane (master) running in one zone. This control plane manages workloads on nodes running in the same zone.
You can create a single-zone cluster.
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.
You can create a multi-zonal 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.
You can create a regional cluster.
Cluster version choices
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.
If you know the level of stability you need for a given cluster, you can enroll the cluster in a 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 stability and real-world performance, and is changed regularly. 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.
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.
You can create an alpha cluster.
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.
The default cluster network mode depends on the way the cluster is created. See the chart here for details.
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 RFC 1918 IP addresses to Pods and nodes, and workloads are completely isolated from public networks.
You can create a private cluster.
Workload supply-chain security
Binary Authorization provides software supply-chain security your GKE workloads. Binary Authorization works with images that you deploy to GKE from Container Registry or another container image registry. With Binary Authorization, you can ensure that internal processes that safeguard the quality and integrity of your software have successfully completed before an application is deployed to your production environment.
For more information, see Creating a cluster with Binary Authorization enabled in the Binary Authorization documentation.