This page introduces the concept ofcluster upgrades forGoogle Kubernetes Engine (GKE) clusters. If you're familiar with how clusterupgrades work, instead seeimplementing the best practices for upgradingclusters.

What are cluster upgrades?

AKubernetes cluster inGKE iscomposed of a control plane and worker nodes, which run user workloads. Both thecontrol plane and worker nodes run a version of Kubernetes. GKEautomatically upgrades the version of the control plane and nodes to ensure thatthe cluster receives new features, bug fixes, and security patches. To learnmore about how GKE chooses the version for your cluster, seeGKE versioning and support.

GKE performs the following types of cluster upgrades, whichinclude bothcontrol plane upgrades andnodeupgrades:

• Patch version upgrades: GKE automatically upgradesclusters to a newpatchas often as every week, depending on thereleasechannel.
• Minor version upgrades: Minor upgrades occur approximately three times ayear. ForExtendedchannelclusters, minor upgrades occur only when the minor version nears theend ofextendedsupport.

For clusters not enrolled in a release channel, GKE alsoautomatically upgrades both the control plane and nodes. To learn howGKE chooses auto-upgrade targets for those clusters, see theUpgrade timing row ina table comparing clusters enrolled and not enrolled ina releasechannel.

You can alsomanuallyupgrade a cluster's controlplane and nodes to an available version, rather than GKEperforming an automatic upgrade. Use GKE features to choose whenand how GKE upgrades your clusters. To learn more, seeControlcluster upgrades.

Get information about cluster upgrades

Use the following resources for details about current upgrades:

• For information about upgrades for specific clusters, including currentauto-upgrade targets, seeGet visibility into clusterupgrades.
• To retrieve general auto-upgrade targets based on a cluster's minor version,see theGKE releasenotesVersion updates, such as the2024-R33note.
• Check theGKE release schedulefor a best-case estimate of when minor versions are available for upgrades,and reachthe end of support.
• Usecluster notificationsto stay informed about upgrade events for your clusters usingCloud Logging or Pub/Sub.

• Useinsights and recommendationsto get the following cluster-specific recommendations:

  • Use release channels
  • Set maintenance windows
  • Upgrade to supported versions
  • Maintain supported version skew
  • Ensure workloads are disruption-ready

Control cluster upgrades

As a platform administrator, you want to minimize disruption to your workloadswhile keeping them performant, reliable, and secure. GKE'sresponsibility as part of theGKE shared responsibilitymodel is to upgradeyour cluster to keep it running to serve your workloads.

As part ofyour sharedresponsibilitywith GKE, you must prepare your workloads for cluster upgrades.You can't completely disable automatic upgrades, but you can control when andhow GKE performs the upgrades.

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

• Release channels:Choose a release channel to get cluster versions with your chosen balance offeature availability and stability.
• Maintenancewindows:Specify a recurring window of time whencertain types of GKEclustermaintenance,such as upgrades, can occur.
• Maintenanceexclusions:Prevent cluster maintenance from occurring for a specific time period.
• Node upgradestrategies:If using Standard node pools, choose how your nodes areupdated–surge, blue-green, or autoscaledblue-green (Preview)upgrades–to minimize disruption to your workloads.
• Rolloutsequencing:Qualify upgrades in a pre-production environment before GKEupgrades your production clusters.
• Manual upgrades:Manually upgrade your cluster, and perform such actions as canceling,resuming, rolling back, and completing automatic or manual in-progressupgrades.

After learning about the preceding capabilities, you'll be able to implement theBest practices for upgradingclusters.

To maximize your workload availability, also use the recommendations andtechniques described inmanaging and monitoring yourcluster,andpreparing yourworkloads.

What are automatic cluster control plane upgrades?

On a regular basis, GKE automatically upgrades thecontrolplane of acluster to newer stable minor versions and patches of Kubernetes.GKE chooses new versions for your cluster based on the cluster'srelease 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 usemaintenanceexclusionsto temporarily prevent all control plane upgrades—including minor and patchupgrades—for up to 30 days, regardless of whether your cluster is enrolled in arelease channel. For clusters enrolled in a release channel, you can preventminor version upgrades until the minor version reaches the end of support.

You can usemaintenancewindowsto set a recurring period of time when GKE can upgrade thecontrol plane.

What are automatic cluster node upgrades?

GKE performs automatic cluster node upgrades in the followingways, depending on the type of cluster and nodes:

• For Autopilot clusters,nodes arealwaysupgradedautomatically to theversion of the control plane.

• For Standard clusters, GKE does the following:

  • For Standard node pools, by default, nodes are upgradedautomatically to the appropriateauto-upgradetarget,like the control plane. Although we don't recommend it, you candisablenodeauto-upgrades.You can also manually upgrade this type of node pool.
  • ForAutopilot-managed nodepools,nodes are automatically upgraded to the version of the control planeover time. You can also manually upgrade this type of node pool.

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

• For clusters enrolled in a release channel, you can use maintenanceexclusions to prevent node auto-upgrades until the minor version of the nodesreaches the end of support.
• For Standard clusters not enrolled in a release channel, at thecluster level, you can prevent node auto-upgrades for up to 30 days. At theStandard node pool level, you candisableauto-upgradesuntil the minor version of the node pool reaches the end of standard support.

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

• Nodes can't be more than two minor versions behind the control planeversion.
• Nodes can't run a version newer than the cluster's current control planeversion.
• Nodes can't run a minor version that has reached the end of support. Forclusters in most release channels, this means theend of standardsupport. Forclusters enrolled in the Extended channel, this means theend of extendedsupport. To checkwhether a minor version is still supported in your cluster's channel, seetheEstimated schedule for releasechannels.

For more details about these constraints, see theGKE versionskew 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 Standard node poolwhen your cluster isn't enrolled in a release channel, GKE mightautomatically upgrade your cluster for security and compatibility purposes incertain cases. Some of the reasons for GKE to upgrade yourcluster regardless of these blockers include the following:

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

For more details, seeAutomatic upgrades at the end ofsupport, andAmanaged platform and sharedresponsibility.

Upgrades and updates with GKE cluster lifecycle management

In GKE, clusterupgrades and clusterupdates have relatedmeanings.

In GKE, the termclusterupgrades—or justupgrades—refers to updatingthe Kubernetes version of the control plane (control plane upgrades) or nodes(node upgrades), or both. When using Standard clusters, node upgradescan also be referred to asnode pool upgrades because GKE usesa single operation to upgrade a node pool of nodes.

The termcluster updates—or justupdates—is a more general term referring to any type of control plane or nodechanges, including updating their versions. GKE actively managesyour cluster environment by performing upgrades, other types of updates, andnecessary maintenance operations. These actions ensure your cluster remainsperformant, secure, and up-to-date with the latest features and bug fixes.GKE uses tools likenode upgradestrategies andmaintenance policiesto minimize disruption during these processes.

To learn more about managing all cluster lifecycle changes, includingupgrades, seeManage cluster lifecycle changes to minimizedisruption.

What's next

• Learn more aboutAutopilot cluster upgrades.
• Learn more aboutStandard cluster upgrades.
• Learn more aboutGKE versioning and support.
• Learn more aboutGKE release notes.
• Learn how toconfigure node auto-upgrades.