Versioning and Upgrades

This page explains versioning and automatic upgrades in Google Kubernetes Engine.

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 compute zone incrementally; the rollout schedule is published in the GKE release notes.
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 Platform.

Checking available and default versions

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

gcloud

To see which versions are available and default, run the following command:

gcloud container get-server-config --zone [COMPUTE_ZONE]

where [COMPUTE_ZONE] is 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 GKE menu in GCP Console.

    Visit the GKE menu

  2. Click Create cluster.

  3. Click the Master version drop-down menu. All currently available versions are listed. The default version is automatically selected.
  4. From Node pools, under the default pool, click Advanced edit.
  5. Click the Node version drop-down menu. All currently available versions are listed. The default version for nodes matches the current default version for cluster masters.

Specifying cluster version

When you create or upgrade a cluster using gcloud, 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 masters, specifies the default Kubernetes version for masters. For node upgrades, specifies the version that the cluster master is currently running.

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

Upgrades

New GKE clusters are created with a default version, a stable release of a recent Kubernetes minor version or patch release. Versions newer than the default are also generally available on a weekly basis.

Automatic cluster master version upgrades

Periodically, the GKE team performs automatic upgrades of your cluster master on your behalf. Cluster masters are upgraded to newer stable versions of Kubernetes. Automatic upgrades are typically performed in stages over multiple weeks.

You can also manually initiate a master upgrade to a version newer than the default.

Automatic node version upgrades

Nodes created using GCP Console are automatically upgraded by default. If you want nodes created with the gcloud command line tool or the GKE API to be upgraded automatically, you can enable automatic node upgrades.

Consider the following when choosing the version for your GKE nodes:

  • Nodes must run a version that is currently available.
  • Nodes cannot run a version newer than the cluster's current master version.
  • Nodes cannot be more than two minor versions behind the master version.
Was this page helpful? Let us know how we did:

Send feedback about...

Kubernetes Engine