Versioning in GKE

This page explains versioning in Google Kubernetes Engine (GKE).

Note: The Kubernetes API is versioned separately from Kubernetes itself. Refer to the Kubernetes API documentation for information about Kubernetes API versioning.

Versioning

GKE clusters support running Kubernetes versions from any supported minor release. At least two, if not three, minor versions are available at any given time. However, subsequent intermediate releases might change what versions are available for new clusters.

Versioning scheme

Minor versions (1.X)

Kubernetes releases a new minor version approximately every three months. A minor version increments the Kubernetes version from 1.X to 1.X+1; for example, Kubernetes 1.10 is the minor release that follows Kubernetes 1.9.

Patch releases (1.X.Y)

New Kubernetes patch releases (such as 1.9.7) for use with GKE typically become available each week. Patch releases are rolled out to each zone incrementally.

Security updates and bug fixes (1.X.Y-gke.N)

A patch release with a -gke.N suffix (such as 1.9.7-gke.N) includes security updates and/or bug fixes for GKE alongside the open-source upstream Kubernetes software. These updates or fixes are required for compatibility and interoperability with Google Cloud.

Checking available and default versions

For information on available versions, see the GKE release notes.

You can also check which Kubernetes versions are available and default in a given zone from Google Cloud Console or by using the gcloud command-line tool.

gcloud

To see which versions are available and default, run one of the following gcloud commands for your cluster type.

Note: If you run this command before a version rollout has completed, the command's output might not be accurate for your location.

Regional clusters

gcloud container get-server-config --region COMPUTE_REGION

Replace COMPUTE_REGION with your cluster's compute region, such as us-east1.

Zonal clusters

gcloud container get-server-config --zone COMPUTE_ZONE

Replace COMPUTE_ZONE with your cluster's compute zone, such as us-central1-a.

Console

To see which versions are available and default, perform the following steps:

1. Visit the Google Kubernetes Engine menu in Cloud Console.

   Visit the Google Kubernetes Engine menu

2. Click Create.

3. Choose the Standard cluster mode, then click Configure.

4. In the Location type section, choose a location type and the desired location for your cluster.

5. In the Control plane version section, select a release channel. All currently available versions are listed for that channel. The default version is automatically selected.

Note: If you use Cloud Console to create a cluster before a version rollout has completed, the lists of available versions might not be accurate for your zone.

Specifying cluster version

This section applies only to clusters created in the Standard mode.

When you create or upgrade a cluster using the gcloud tool, you can specify a cluster version using the --cluster-version flag. You can use a specific version, such as 1.9.7-gke.N. You can also use a version alias:

• latest: Specifies the highest supported Kubernetes version currently available on GKE in the cluster's zone or region.
• 1.X: Specifies the highest valid patch+gke.N patch release in the 1.X minor version
• 1.X.Y: Specifies the highest valid gke.N patch in the 1.X.Y patch release.
• -: For cluster control planes, specifies the default Kubernetes version for control planes. For node upgrades, specifies the version that the cluster control plane is currently running.

Creating or upgrading a cluster by specifying the version as latest does not provide automatic upgrades. Enable node auto-upgrades to ensure that the nodes in your cluster are up-to-date with the latest stable version.

Specifying node version

This section applies only to clusters created in the Standard mode. In Autopilot clusters, nodes are upgraded automatically.

When you create or upgrade a node pool, you can specify its version. By default, nodes run the same version of GKE as the control plane. Nodes can be no more than two minor versions older than control planes.

With rare exceptions, node versions remain available even if the cluster version is no longer available.