5 GKE support facts for cluster admins

Google Kubernetes Engine support depends on release channels, version skew, and a 14-month minor-version window.

If you manage GKE clusters, these five facts help you read the support schedule, spot upgrade deadlines, and avoid surprises. The current page lists 1.35 as the newest release, with active support ending on 28 Feb 2027.

Item	Support model	Default behavior
1.35	Active until 28 Feb 2027	Latest listed release
1.34	Active until 30 Aug 2026	Recent stable release
1.33	Active until 30 Jun 2026	Near-term upgrade target
1.32	Maintenance ended 11 Apr 2026	Past active support

1. GKE gives you two operating modes

Google Kubernetes Engine runs clusters in Standard or Autopilot mode, and the choice changes how much upgrade work you own. In Standard, you manage the underlying infrastructure. In Autopilot, Google manages the nodes and node pools for you.

• Standard: you control node management and can configure node auto-upgrade.
• Autopilot: nodes are always upgraded automatically to the control plane version.
• Control plane upgrades cannot be disabled in either mode.

That means “managed” does not mean “hands off.” You still need a version plan, especially if you run workloads with strict compatibility needs.

2. Release channels set the upgrade pace

GKE offers Rapid, Regular, and Stable release channels. Regular is the default, and all three channels are generally available. If you enroll a cluster in a channel, GKE manages the version and upgrade cadence for the cluster and its node pools.

• Rapid: fastest access to newer releases.
• Regular: default choice for most clusters.
• Stable: slower cadence for teams that want more time before upgrades.

The page notes that end-of-life dates for a release stay the same regardless of channel, so channels change timing, not the support clock.

3. Support lasts 14 months per minor version

GKE provides a total of 14 months of support for each Kubernetes minor version once it reaches the Regular channel. That is the most important planning number on the page, because it defines how long a release stays in the supported window.

Support window = 14 months from availability in the Regular channel

For example, version 1.35 is listed with active support ending on 28 Feb 2027, while 1.34 ends on 30 Aug 2026. If you are one minor version behind, you may already be inside the upgrade window.

4. Version skew limits how far behind nodes can fall

GKE follows the Kubernetes version skew policy, which means node and node pool versions can be up to two minor versions older than the control plane. That gives you some room, but not much.

• Control plane can move ahead of nodes within the allowed skew.
• Nodes older than two minor versions are outside policy.
• Static clusters still need supported versions, even without a release channel.

This matters most for teams that delay maintenance. A cluster may still run, but fall outside the supported version range sooner than expected.

5. Static clusters put upgrade ownership on you

No Channel, also called Static, means the cluster is not enrolled in a release channel. In that setup, you are responsible for the upgrade strategy, even though Google may still upgrade nodes in select security or compatibility cases.

• No Channel clusters do not get automatic channel-based cadence.
• You still must use supported GKE versions.
• Security bulletins are published alongside release information.

If your team wants control over timing, Static can work. If your team wants less maintenance, a release channel usually fits better.

How to decide

Pick Autopilot if you want Google to handle node upgrades and you are comfortable with tighter platform control. Pick Standard if you need more infrastructure control or custom node behavior. Pick a release channel if you want GKE to manage cadence for you, and use Stable when upgrade timing matters more than early access.

If you run No Channel clusters, treat the support schedule as your own responsibility. The safest move is to track the 14-month minor-version window, watch the active support end date for your current release, and plan upgrades before version skew becomes a problem.