This page explains the main types of clusters you can create in Google Kubernetes Engine (GKE). 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 network isolation.
For more information to help you decide between cluster types, see Choosing a regional or zonal control plane.
Cluster availability choices
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.
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, 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.
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 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.
Cluster networking choices
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.
The default cluster network mode depends on the way the cluster is created. 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.
You can create a private cluster.
Kubernetes feature choices
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.
You can create an alpha cluster.
Workload supply-chain security
Binary Authorization is a feature of the Anthos platform and provides software supply-chain security to 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.