About GKE cluster upgrades

This page introduces the concept of cluster upgrades for Google Kubernetes Engine (GKE) clusters. If you're familiar with how cluster upgrades work, instead see implementing the best practices for upgrading clusters.

What are cluster upgrades?

A Kubernetes cluster in GKE is composed of a control plane and worker nodes, which run user workloads. Both the control plane and worker nodes run a version of Kubernetes. GKE automatically upgrades the version of the control plane and nodes to ensure that the cluster receives new features, bug fixes, and security patches. To learn more about how GKE chooses the version for your cluster, see GKE versioning and support.

GKE performs the following types of cluster upgrades, which include both control plane upgrades and node upgrades:

  • Patch version upgrades: GKE automatically upgrades clusters to a new patch as often as every week, depending on the release channel.
  • Minor version upgrades: Minor upgrades occur approximately three times a year. For Extended channel clusters, minor upgrades occur only when the minor version nears the end of extended support.

For clusters not enrolled in a release channel, GKE also automatically upgrades both the control plane and nodes. To learn how GKE chooses auto-upgrade targets for those clusters, see the Upgrade timing row in a table comparing clusters enrolled and not enrolled in a release channel.

You can also manually upgrade a cluster's control plane and nodes to an available version, rather than GKE performing an automatic upgrade. Use GKE features to choose when and how GKE upgrades your clusters. To learn more, see Control cluster upgrades.

Get information about cluster upgrades

Use the following resources for details about current upgrades:

Control cluster upgrades

As a platform administrator, you want to minimize disruption to your workloads while keeping them performant, reliable, and secure. GKE's responsibility as part of the GKE shared responsibility model is to upgrade your cluster to keep it running to serve your workloads.

As part of your shared responsibility with GKE, you must prepare your workloads for cluster upgrades. You can't completely disable automatic upgrades, but you can control when and how GKE performs the upgrades.

To manage GKE cluster upgrades, optimized for your workloads, use the following capabilities:

  • Release channels: Choose a release channel to get cluster versions with your chosen balance of feature availability and stability.
  • Maintenance windows: Specify a recurring window of time when certain types of GKE cluster maintenance, such as upgrades, can occur.
  • Maintenance exclusions: Prevent cluster maintenance from occurring for a specific time period.
  • Node upgrade strategies: If using Standard clusters, choose how your nodes are updated–surge upgrades or blue-green upgrades–to minimize disruption to your workloads.
  • Rollout sequencing: Qualify upgrades in a pre-production environment before GKE upgrades your production clusters.
  • Manual upgrades: Manually upgrade your cluster, and perform such actions as canceling, resuming, rolling back, and completing automatic or manual in-progress upgrades.

After learning about the preceding capabilities, you'll be able to implement the Best practices for upgrading clusters.

To maximize your workload availability, also use the recommendations and techniques described in managing and monitoring your cluster, and preparing your workloads.

What are automatic cluster control plane upgrades?

On a regular basis, GKE automatically upgrades the control plane of a cluster to newer stable minor versions and patches of Kubernetes. GKE chooses new versions for your cluster based on the cluster's release channel enrollment.

Across the entire fleet of GKE clusters, automatic upgrades are typically performed in stages over multiple weeks. As infrastructure security is a high priority for GKE, control planes upgrades happen regularly and can't be disabled.

Although you can't disable control plane upgrades, you can use maintenance exclusions to temporarily prevent all control plane upgrades—including minor and patch upgrades—for up to 30 days, regardless of whether your cluster is enrolled in a release channel. For clusters enrolled in a release channel, you can prevent minor version upgrades until the minor version reaches the end of support.

You can use maintenance windows to set a recurring period of time when GKE can upgrade the control plane.

What are automatic cluster node upgrades?

For Autopilot clusters, nodes are always upgraded automatically to the version of the control plane. For Standard clusters, by default nodes are upgraded automatically to the version of the control plane.

For both modes of clusters, you can use maintenance windows and exclusions to control the timing and scope of node upgrades, as follows:

  • For clusters enrolled in a release channel, you can use maintenance exclusions to prevent node auto-upgrades until the minor version of the nodes reaches the end of support.
  • For Standard clusters not enrolled in a release channel, at the cluster level, you can prevent node auto-upgrades for up to 30 days. At the node pool level, you can disable auto-upgrades until the minor version of the node pool reaches the end of standard support.

Whenever planning to postpone node auto-upgrades, consider the following constraints for the nodes of a GKE cluster:

  • Nodes can't be more than two minor versions behind the control plane version.
  • Nodes can't run a version newer than the cluster's current control plane version.
  • Nodes can't run a minor version that has reached the end of support. For clusters in most release channels, this means the end of standard support. For clusters enrolled in the Extended channel, this means the end of extended support. To check whether a minor version is still supported in your cluster's channel, see the Estimated schedule for release channels.

For more details about these constraints, see the GKE version skew policy.

Automatic cluster upgrades for security and compatibility

If you're preventing cluster upgrades with maintenance windows and exclusions, or you've disabled node auto-upgrades for a specific node pool when your cluster isn't enrolled in a release channel, GKE might automatically upgrade your cluster for security and compatibility purposes in certain cases. Some of the reasons for GKE to upgrade your cluster regardless of these blockers include the following:

  • Cluster control planes running an end of support version.
  • Cluster nodes running end of support versions.
  • State-looping clusters, defined as clusters with looping states from running to degraded, repairing, or suspended and back to running.

For more details, see Automatic upgrades at the end of support, and A managed platform and shared responsibility.

Upgrades and updates with GKE cluster lifecycle management

In GKE, cluster upgrades and cluster updates have related meanings.

In GKE, the term cluster upgrades—or just upgrades—refers to updating the Kubernetes version of the control plane (control plane upgrades) or nodes (node upgrades), or both. When using Standard clusters, node upgrades can also be referred to as node pool upgrades because GKE uses a single operation to upgrade a node pool of nodes.

The term cluster updates—or just updates—is a more general term referring to any type of control plane or node changes, including updating their versions. GKE actively manages your cluster environment by performing upgrades, other types of updates, and necessary maintenance operations. These actions ensure your cluster remains performant, secure, and up-to-date with the latest features and bug fixes. GKE uses tools like node upgrade strategies and maintenance policies to minimize disruption during these processes.

To learn more about managing all cluster lifecycle changes, including upgrades, see Manage cluster lifecycle changes to minimize disruption.

What's next