This page explains automatic upgrades in Google Kubernetes Engine (GKE).
Rollout schedule
GKE follows a predictable multi-day rollout schedule for making new versions available, as well as auto-upgrading cluster control planes (masters) and nodes. The rollout generally spans four or more business days, and includes a buffer of time to observe and monitor for problems. Zones and regions are updated in a predictable order.
Automatic upgrades
New GKE Standard 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. Autopilot clusters are enrolled in a
release channel (defaults to
standard
) instead.
You can also control when auto-upgrades can and cannot occur by configuring maintenance windows and exclusions.
Learn about GKE versions in Versioning.
Automatic cluster control plane upgrades
Periodically, the GKE team performs automatic upgrades of your cluster control plane on your behalf, regardless of whether your cluster is enrolled in a release channel or not. Control planes are upgraded to newer stable versions of Kubernetes. Automatic upgrades are typically performed in stages over multiple weeks.
To manage when automatic upgrades can or cannot occur, configure maintenance windows and exclusions.
To see when the control plane was recently updated, run the following command:
gcloud container operations list --filter="TYPE:UPGRADE_MASTER AND TARGET:CLUSTER_NAME"
Replace CLUSTER_NAME
with the name of your cluster.
Automatic node upgrades
This section applies only to clusters created in the Standard mode. In Autopilot clusters, nodes are always upgraded automatically to the version of the control plane.
Nodes created
using Cloud Console are automatically upgraded
by default. If you want nodes created with the gcloud
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 control plane version.
- Nodes cannot be more than two minor versions behind the control plane version.