Versioning
This page explains GKE on Azure versioning.
GKE on Azure versions
Each release of GKE on Azure supports several Kubernetes minor versions, each of which can have several GKE patch versions. The following GKE on Azure versions are fully supported, offering the latest patches and updates for security vulnerabilities, exposures, and issues affecting GKE on Azure:
Minor version | Patch releases |
---|---|
1.31 |
|
1.30 |
|
1.29 |
|
Properties of unsupported versions
Versions not listed in the preceding table are unsupported. After a minor version reaches its end of life, the following rules apply:
- End-of-life patch versions can't be used to create clusters.
- End-of-life events don't disrupt your control planes and workloads. Regular operations on existing clusters can continue with end-of-life versions. To ensure support from Google and avoid potential bug-related failures or security vulnerabilities, you must manually upgrade your clusters and node pools to a supported version as soon as possible.
- Upgrades of existing clusters and node pools to newer versions can occur even if the upgraded version is at end of life. However, you must eventually upgrade to one of the supported versions.
- New node pools can still be created with an end-of-life version, but this isn't recommended. Upgrades to a supported version should be prioritized.
Check available Kubernetes versions
To see all available versions, including those which have reached their end of life and are unsupported, run this command:
gcloud container azure get-server-config \
--location=GOOGLE_CLOUD_LOCATION
Replace GOOGLE_CLOUD_LOCATION
with the Google Cloud
location from which you manage your clusters.
The supported versions are returned with their enabled
flag set to true
.
Any end of life patch versions are returned in the output with their
end_of_life
flag set to true
.
Versioning scheme
GKE on Azure uses Kubernetes
semantic versioning to refer to supported
Kubernetes versions, but appends a GKE patch version. This
results in a version number of the form: x.y.z-gke.a
For example, the most recently-supported Kubernetes version is 1.31.1-gke.1800.
- Kubernetes major version (x)
- Major versions are typically incremented if any backwards incompatible
changes are introduced to the public API. A major version increments the
Kubernetes version from
x.y
tox+1.y
. - Kubernetes minor version (y)
- Kubernetes releases a new minor version
three times a year.
Each release cycle is approximately 15 weeks long. Deprecated
APIs might
be removed with a new minor version. A minor version increments the
Kubernetes version from
1.y
to1.y+1
; for example, Kubernetes 1. 29 is the minor release that follows Kubernetes 1.28. - Kubernetes patch release (z)
- New Kubernetes patch releases (such as 1.21.1) for use with GKE on Azure are normally released once a month. Patch releases only include security and bug fixes.
- GKE patch release (-gke.a)
- A patch release with a higher -gke.a suffix (such as 1.24.1-gke.a) includes security updates and bug fixes for GKE on Azure alongside the open source upstream Kubernetes software. These updates or fixes are required for compatibility and interoperability with Google Cloud and Azure.
Version notes
Each GKE on Azure release comes with Kubernetes version notes. These are similar to release notes but are specific to a Kubernetes version and might offer more technical detail. These version notes are listed on the GKE on Azure version notes page.
Version skew
Nodes and node pool versions can be up to two minor versions older than the control plane, but, in accordance with Kubernetes OSS version skew policy, cannot be newer than the control plane version. We strongly recommend that your nodes always use a supported version regardless of version skew guidelines.
Support for versions
To learn more about the support period, see the GKE Enterprise Version Support Policy, which GKE on Azure follows.