Explanation
Why the waste happens and who it affects.
Clusters enrolled in the Extended release channel can stay on a minor version for up to 24 months in total, receiving security patches for roughly 10 more months during the extended support period. Once a cluster's minor version enters that period, GKE adds an extended period cluster management fee on top of the normal cluster management fee, for every hour the cluster stays on that version.
Teams usually pick the Extended channel to slow down upgrades for compatibility or change-control reasons, and the channel itself costs nothing extra during standard support. The charge starts automatically when the version crosses its end of standard support date, so clusters that were meant to buy a few weeks of upgrade time can end up paying the extended fee for months. Fleets with many small clusters are hit hardest, because the fee is flat per cluster regardless of size.
Billing model
The pricing dimensions that drive this cost.
- Cluster management fee
- A flat hourly fee per GKE cluster, charged in one-second increments, for all modes and topologies
- Extended period cluster management fee
- An additional hourly fee per cluster, in addition to the standard fee, for clusters on the Extended channel whose minor version is past end of standard support
- Extended channel during standard support
- No additional charge, and the cluster can upgrade to a version in standard support at any time
How to detect
4 checks to find it in your estate.
- List clusters whose releaseChannel is EXTENDED and record each cluster's current control plane minor version
- Run gcloud container clusters get-upgrade-info for each cluster to see its end of support timelines, or compare the minor version with the end of standard support dates on the GKE release schedule
- Subscribe to GKE cluster notifications and watch for UpgradeInfoEvent notifications with eventType END_OF_SUPPORT, sent 30 days before and at end of standard or extended support
- In the Cloud Billing report or billing export, filter to Kubernetes Engine and look for the extended support cluster management SKU to find clusters already paying it
How to fix
4 ways to remove the waste.
- Upgrade the cluster to a minor version that is still in standard support before the extended support period begins, or as soon as possible if it has already started
- Move clusters that do not need long version pinning to the Regular or Stable channel so GKE keeps them on supported versions automatically
- Work through upgrade blockers such as deprecated Kubernetes APIs early; GKE auto-upgrades clusters near the end of extended support unless deprecated features or APIs block it, and forces the upgrade at the end regardless
- Reserve the Extended channel for clusters with a documented need for long support windows, and track their end of standard support dates as a planned cost
Documentation
Vendor references for pricing and configuration.