This page explains automatic upgrades in Google Kubernetes Engine (GKE).
GKE follows a 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 (rollouts are paused during weekends/holidays), and includes a buffer of time to observe and monitor for problems.
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
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. Infrastructure security is high priority for GKE, and as such control planes are upgraded on a regular basis, and cannot be disabled. However, you can apply maintenance windows and exclusions to temporarily suspend upgrades for control planes and nodes.
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"
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.
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.
Automatic node upgrades for security and compatibility
If your clusters are not opted into node auto-upgrades, there are select cases where Google may automatically upgrade your nodes for security and compatibility purposes. The top reasons for automatic upgrades include but are not limited to:
- Clusters using an end of life version.
- Node(s) running end of life versions.
- Abandoned clusters, defined as clusters in a running state with no activity (that is, no API calls, traffic, or subnets).
- State-looping clusters, defined as clusters with looping states from running to degraded, repairing, or suspended and back to running.