# GKE Clusters Incurring Extended Support Charges Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/gke-clusters-incurring-extended-support-charges GKE supports each minor version for 14 months of standard support. Clusters enrolled in the Extended release channel can stay on a minor version for up... By: PointFive Updated: 2026-09-28 [Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) The short version GKE supports each minor version for 14 months of standard support. PointFive Research Cloud cost research at PointFive GCP service [GCP GKE](https://www.pointfive.co/efficiency-hub/cloud-services/gcp-gke) Category [Compute](https://www.pointfive.co/efficiency-hub/service-category/compute) Reference CER-0560 Type Outdated Version ## 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. - [About release channels docs.cloud.google.com](https://docs.cloud.google.com/kubernetes-engine/docs/concepts/release-channels) - [Google Kubernetes Engine pricing cloud.google.com](https://cloud.google.com/kubernetes-engine/pricing) - [GKE release schedule docs.cloud.google.com](https://docs.cloud.google.com/kubernetes-engine/docs/release-schedule) - [Cluster notifications docs.cloud.google.com](https://docs.cloud.google.com/kubernetes-engine/docs/concepts/cluster-notifications) - [gcloud container clusters get-upgrade-info docs.cloud.google.com](https://docs.cloud.google.com/sdk/gcloud/reference/container/clusters/get-upgrade-info) ## Related inefficiencies [Browse the library](https://www.pointfive.co/efficiency-hub) - GCP GKE CER-0287 ### [Spot-Only GKE Capacity Without Standard Fallback](https://www.pointfive.co/efficiency-hub/inefficiencies/spot-only-gke-capacity-without-standard-fallback) Workloads are constrained to run only on Spot-based capacity with no viable path to standard nodes when Spot capacity is reclaimed or unavailable. While Spot reduces unit cost, rigid dependence can create hidden costs by requiring standby... Compute - GCP GKE CER-0193 ### [Orphaned and Overprovisioned Resources in GKE Clusters](https://www.pointfive.co/efficiency-hub/inefficiencies/orphaned-and-overprovisioned-resources-in-gke-clusters) As environments scale, GKE clusters tend to accumulate artifacts from ephemeral workloads, dev environments, or incomplete job execution. PVCs can continue to retain Persistent Disks, Services may continue to expose public IPs and... Compute - GCP GKE CER-0270 ### [Orphaned Kubernetes Resources in GKE](https://www.pointfive.co/efficiency-hub/inefficiencies/orphaned-kubernetes-resources) In GKE environments, it is common for unused Kubernetes resources to accumulate over time. Examples include Persistent Volume Claims (PVCs) that retain provisioned Persistent Disks, or Services of type LoadBalancer that continue to front... Compute --- Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.