Kubernetes 1.35 has been running in production clusters since mid-December 2025, but the version is turning into a September headache for platform teams. The release quietly flips a default that determines whether older Linux nodes can even boot a kubelet, and it draws a hard line under containerd’s legacy 1.x branch. Google Cloud pushed Kubernetes 1.35 into GKE’s Rapid channel on September 18, 2026, Amazon made it available in EKS on August 25, and Microsoft’s AKS has offered it since March. Each of those managed services now carries the same warning: nodes still running the old cgroup v1 resource-control system, or clusters still pinned to containerd 1.x, are on borrowed time.
This isn’t a security patch or a feature drop that most engineers can ignore until the next sprint. It’s an infrastructure compatibility deadline with a real failure mode: kubelets that won’t start. For teams running EKS, GKE, or AKS at scale, the next few Kubernetes upgrade cycles come with an unusually blunt requirement — check your node images, check your container runtime version, and do it before the cluster forces the issue.
What actually changed in Kubernetes 1.35
Kubernetes has relied on Linux control groups, or cgroups, to manage CPU, memory, and other resource limits since the project’s earliest days. The original implementation, cgroup v1, worked but was inconsistent across distributions and limited in how finely it could isolate resources. Kubernetes added support for the newer cgroup v2 hierarchy back in version 1.25, and cgroup v2 has been the default on most modern Linux distributions for several years now.
With cgroup v2 now considered the standard, the Kubernetes project used 1.35 to retire legacy cgroup v1 support. The project’s own release notes are direct about the consequence: cluster administrators still running nodes on older Linux distributions that don’t support cgroup v2 will find that the kubelet fails to start. There’s no soft warning period baked into the node itself, just a hard stop. The work is tracked publicly under KEP-5573, “Remove cgroup v1 support,” and the Kubernetes documentation on cgroups lays out the migration path for administrators who need to move node images over before their next upgrade.
The second change lands on the container runtime layer. Kubernetes 1.35 still supports containerd 1.7 and other long-term-support 1.x releases, but SIG Node has designated it the last release that will. Anyone planning to move past 1.35 needs containerd 2.0 or later already installed on their nodes. To help operators spot stragglers, the release adds a new metric, kubelet_cri_losing_support, that cluster admins can watch to identify which nodes are still running a runtime version that’s about to fall out of support. The runtime work is tracked under KEP-4033, “Discover cgroup driver from CRI.”
A third, smaller deprecation rounds out the node-and-networking cleanup: ipvs mode in kube-proxy is now deprecated, with the Kubernetes project steering users toward nftables as the modern replacement for Linux packet filtering and load balancing. That change is tracked under KEP-5495.
Why cgroup v1 removal is the one that bites
Feature deprecations in Kubernetes are usually forgiving. APIs get marked deprecated for several release cycles, warnings show up in kubectl output, and admission controllers can be configured to flag the old behavior before it breaks anything. The cgroup v1 change doesn’t work that way. It’s a node-boot-time failure, not an API-server warning, which means the blast radius is whatever workload was scheduled on that node when it stopped coming back online.
That distinction matters because cgroup version is tied to the node’s base operating system, not to a Kubernetes manifest an engineer can patch in a pull request. Older Linux distributions, and some hardened or long-term-support images that platform teams chose specifically because they don’t change often, may simply never have shipped with cgroup v2 as the default. Migrating means rebuilding node images or moving to a newer OS release, which is a much bigger lift than bumping a Helm chart version.
Google Cloud’s GKE documentation frames this in blunt operational terms for its own customers: node pools explicitly configured to use cgroup v1 will be blocked from upgrading to Kubernetes 1.35 until they’re migrated to cgroup v2. Amazon’s EKS documentation describes the same mechanism from the AWS side, noting that the kubelet refuses to start by default on cgroup-v1 nodes once a cluster moves to 1.35. Both major clouds are, in effect, using the managed control plane to enforce a change that originates in upstream Kubernetes.
The managed Kubernetes rollout, cloud by cloud
The three major managed Kubernetes services didn’t move in lockstep, which matters for anyone trying to plan a fleet-wide upgrade across multiple clouds. Microsoft’s AKS was first, listing Kubernetes 1.35 as generally available back in March 2026. Amazon’s EKS followed by late August, making the version available by August 25. Google Cloud brought up the rear, adding Kubernetes 1.35 to GKE’s Rapid release channel on September 18, 2026, the most recent of the three by a wide margin.
That gap matters for organizations running multi-cloud Kubernetes fleets, since it means a cluster on EKS could be facing the cgroup v1 cutoff for the better part of a month before the equivalent GKE cluster is even eligible to upgrade. AKS also layers on its own constraint: Microsoft requires sequential minor-version upgrades, so a cluster sitting on Kubernetes 1.33 cannot jump straight to 1.35. It has to pass through 1.34 first, adding an extra upgrade cycle, and an extra opportunity to hit compatibility surprises, for teams that let their clusters fall behind.
| Service | Kubernetes 1.35 availability | Support window | Upgrade notes |
|---|---|---|---|
| Azure AKS | General availability, March 2026 | Standard support ends March 2027 | Sequential upgrades only; 1.33 must pass through 1.34 to reach 1.35 |
| Amazon EKS | Available August 25, 2026 | Standard support ~14 months from GA, then extended support available | Kubelet refuses to start by default on cgroup v1 nodes |
| Google GKE | Rapid channel, September 18, 2026 | Follows GKE release channel cadence | Node pools on cgroup v1 blocked from upgrading until migrated |
Kubernetes 1.35 itself was originally released upstream on December 17, 2025. The project’s own support lifecycle has it entering maintenance mode on December 28, 2026, and reaching end of life on February 28, 2027. In the shorter term, the patch train keeps moving: the Kubernetes release schedule lists 1.35.8 as shipping August 11, 2026, with 1.35.9 targeted for September 15, 2026, so even teams that already upgraded need to keep pulling patch releases rather than treating 1.35 as a one-time migration.
The extended-support money question
None of this is happening in a vacuum. Cloud providers have spent the past two years building out paid extended-support tiers specifically for clusters that fall behind the standard Kubernetes support window, and the pricing on those tiers gives platform teams a direct financial incentive to keep up with releases like 1.35 rather than pay to stay behind. As shattered.io reported when Kubernetes 1.34 support fees kicked in, AWS, Azure, and Google Cloud all now charge for clusters running unsupported versions.
Amazon’s EKS extended support runs $0.60 per cluster-hour once a version ages out of standard support, combining the normal $0.10 hourly cluster-management fee with a $0.50 surcharge. Run that out over a 730-hour month and it lands around $438 per cluster. Google Cloud’s GKE extended-support fee follows a similar structure: an additional $0.50 per cluster-hour on top of the standard $0.10 management fee, for the same roughly $438-per-month total once a cluster is running an unsupported version. AWS gives clusters 14 months of standard support from a version’s general-availability date before the extended-support meter starts running, with up to 12 months of paid extended support available after that.
| Provider | Standard support fee | Extended support fee | Approx. monthly cost, extended tier |
|---|---|---|---|
| Amazon EKS | $0.10 per cluster-hour | $0.60 per cluster-hour ($0.10 base + $0.50 surcharge) | ~$438 per cluster |
| Google GKE | $0.10 per cluster-hour | $0.60 per cluster-hour ($0.10 base + $0.50 surcharge) | ~$438 per cluster |
| Azure AKS | Included in AKS pricing tier | Not publicly itemized as a per-hour rate | Not disclosed |
The practical effect is that the cgroup v1 and containerd 1.x cutoffs in Kubernetes 1.35 aren’t just an engineering compatibility problem, they’re a budget line. A fleet of a few dozen clusters that can’t clear the 1.35 upgrade because of legacy node images could be looking at tens of thousands of dollars a year in extended-support fees on AWS or Google Cloud alone, on top of whatever it eventually costs to do the node-image migration anyway.
Ingress NGINX retirement adds to the pile
Kubernetes 1.35 landed alongside another disruptive change that, while not formally part of the release itself, the project’s release notes specifically call out because of its scale of impact: the retirement of the Ingress NGINX controller. For years, Ingress NGINX was the default way countless clusters routed external traffic in, but the Kubernetes project has said maintaining it became unsustainable given a shortage of maintainers and accumulating technical debt. The controller moved to best-effort maintenance only, with a cutoff of March 2026, after which it’s archived with no further updates.
The recommended replacement is the Gateway API, which the Kubernetes project describes as a more modern, secure, and extensible standard for traffic management than the original Ingress resource. Teams that migrated to 1.35 without also planning an Ingress NGINX exit now have two separate infrastructure migrations stacked on top of each other: move off cgroup v1 nodes, and move off a networking controller that no longer receives updates.
What else shipped in 1.35
The deprecations tend to dominate the conversation, but Kubernetes 1.35 also promoted 17 enhancements to stable status, the release’s largest batch of general-availability graduations in some time. Among them: in-place update of pod resources, which lets operators adjust CPU and memory requests on running pods without a restart; fine-grained SupplementalGroups control for pod security contexts; a drop-in kubelet configuration directory that simplifies how node-level config gets layered and managed; and a Job API “managed-by” mechanism that clarifies ownership when external controllers manage Job objects.
Container image handling gets stricter
The image volume type, in beta since Kubernetes 1.33, is now enabled by default in 1.35, letting pods mount OCI container images as volumes directly. That feature specifically requires a compatible container runtime such as containerd 2.1 or later, which ties back into the same runtime-version pressure driving the broader containerd 1.x cutoff. Kubernetes also added enforced kubelet credential verification for cached images, tightening a gap where the previous imagePullPolicy: IfNotPresent setting could let a pod use a cached image without re-verifying pull credentials.
Pod stability during kubelet restarts
Restarting the kubelet service has historically caused a brief disruption in how pod status gets reported, even when the pods themselves kept running fine. Kubernetes 1.35 addresses that gap directly, reducing the window where a kubelet restart shows pods as unhealthy when nothing has actually gone wrong on the workload side. It’s a smaller change than the cgroup or containerd work, but it’s the kind of reliability fix that platform teams running large fleets tend to notice immediately.
How to check if your nodes are exposed
Before touching a cluster’s control plane version, platform teams can check node-level cgroup configuration directly. On a Linux node, the filesystem type mounted at /sys/fs/cgroup reveals which version is active: cgroup v2 mounts as a unified cgroup2 filesystem, while cgroup v1 nodes show a collection of separate hierarchies instead.
# Check cgroup version on a node
stat -fc %T /sys/fs/cgroup/
# cgroup2fs -> node is on cgroup v2, safe for Kubernetes 1.35
# tmpfs -> node is likely still on cgroup v1
# Check node OS image reported to the cluster
kubectl get nodes -o jsonpath='{.items[*].status.nodeInfo.osImage}{"\n"}'
# Check container runtime version per node
kubectl get nodes -o jsonpath='{.items[*].status.nodeInfo.containerRuntimeVersion}{"\n"}'Once a cluster is running Kubernetes 1.35, the new kubelet_cri_losing_support metric gives a live signal for which nodes are still on a container runtime version that’s about to be unsupported, letting teams target the stragglers instead of guessing across an entire fleet.
Historical context: why Kubernetes ships three releases a year
The pace of these compatibility deadlines is itself a product of a scheduling decision the Kubernetes project made years ago. Before 2021, Kubernetes shipped roughly four minor releases a year, on a tight quarterly cadence that gave the release engineering team and contributors relatively little breathing room between cycles. In 2021 the project moved to three minor releases per year instead, a deliberate trade of release frequency for more planning and testing time per cycle.
That change is part of why deprecations like the cgroup v1 removal can be flagged years in advance and still catch teams off guard: with only three releases a year, and support windows measured in months rather than a handful of release cycles, the gap between “we announced this is coming” and “this is now enforced” can still compress faster than a large organization’s change-management process can absorb it. Kubernetes moved cgroup v1 support into maintenance mode back in version 1.31, more than a year before the actual removal in 1.35, which by the project’s own cadence was still only three release cycles of runway.
Market impact for platform and DevOps teams
The combined effect of the cgroup v1 cutoff, the containerd 1.x sunset, and the Ingress NGINX retirement is a rare moment where three separate infrastructure dependencies come due at roughly the same time. For large enterprises running hundreds of clusters across AWS, Google Cloud, and Azure, that clustering of deadlines increases the odds that at least some fraction of the fleet gets caught flat-footed, either paying extended-support surcharges while migration work is scheduled, or discovering the hard way that a node pool with an outdated OS image won’t come back after an upgrade.
It also puts pressure on the ecosystem of managed node-image providers and base OS vendors, since cgroup v2 readiness now becomes a checklist item for any Linux distribution marketed toward Kubernetes workloads. Expect renewed scrutiny of long-term-support OS choices that platform teams picked years ago specifically for stability, since those same choices are now the ones most likely to be caught without cgroup v2 support.
Competitive comparison: how the big three are handling it
Of the three major managed Kubernetes services, AKS has had the most runway, since Microsoft made 1.35 generally available back in March, giving customers roughly six months of head start over GKE customers before this article’s publication date. That said, AKS’s mandatory sequential-upgrade policy partially offsets the advantage, since clusters that skipped straight from an older version have to budget time for an intermediate hop through 1.34.
EKS sits in the middle, both in terms of availability timing and in how directly AWS’s own documentation warns customers about the kubelet failure mode. Google’s GKE, despite being latest to the party with its September 18 Rapid-channel rollout, tends to move customers through release channels (Rapid, Regular, Stable) automatically over time, which means GKE customers on the Regular or Stable channels won’t feel the cgroup v1 pressure as immediately as those who opted into Rapid, but will eventually face the same wall once the version rolls forward.
What comes next
A few things look likely over the next two to three Kubernetes release cycles:
- Extended-support revenue at AWS and Google Cloud will climb through late 2026 and early 2027 as more clusters age past standard support windows rather than complete the cgroup v2 and containerd 2.0 migration in time.
- Node-image vendors and base-OS distributions marketed for Kubernetes will increasingly advertise cgroup v2-by-default as a selling point, the same way they now advertise containerd 2.x compatibility.
- Gateway API adoption should accelerate through the first half of 2027 as the Ingress NGINX archive date recedes further into the rearview mirror and teams run out of reasons to delay the migration.
- Expect at least one more high-profile cluster outage tied to the cgroup v1 cutoff to surface publicly before the end of 2026, given how many organizations still run long-term-support Linux images chosen years before cgroup v2 became the default.
- Azure is likely to publish more explicit extended-support pricing for AKS once enough customers start asking, following the pattern AWS and Google Cloud already set with their per-hour surcharge structure.
Practical steps for platform teams this quarter
Teams that haven’t already audited their fleet should treat this as a two-track problem: node operating system readiness, and container runtime version. Both can be checked without touching production traffic, and both need to be resolved before a cluster attempts the jump to Kubernetes 1.35 on any of the three major managed services.
- Inventory every node pool’s base OS image and confirm cgroup v2 is the default mount, not an opt-in configuration.
- Check container runtime versions across the fleet and flag anything still on containerd 1.x for a runtime upgrade before the next Kubernetes version bump.
- For AKS customers on versions older than 1.34, budget time for the mandatory intermediate hop rather than assuming a direct jump to 1.35.
- Set a budget alert for extended-support charges on any cluster that can’t complete migration before its standard support window closes.
- Start a parallel Gateway API migration plan if the cluster still depends on the Ingress NGINX controller, since that clock is independent of the Kubernetes version itself.
Frequently asked questions
Does Kubernetes 1.35 completely remove cgroup v1 support?
Yes. Kubernetes 1.35 retires the legacy cgroup v1 resource-control system. Nodes running on Linux distributions that don’t support cgroup v2 will have their kubelet fail to start once the cluster is on 1.35, according to the Kubernetes project’s own release notes.
Is Kubernetes 1.35 the last version to support containerd 1.x?
Yes. SIG Node designated 1.35 as the final release supporting containerd 1.7 and other 1.x long-term-support builds. Any cluster planning to upgrade past 1.35 needs containerd 2.0 or later installed first.
When did GKE, EKS, and AKS each make Kubernetes 1.35 available?
AKS reached general availability for 1.35 in March 2026, EKS made it available by August 25, 2026, and GKE added it to its Rapid release channel on September 18, 2026.
How much do extended-support fees cost on AWS and Google Cloud?
Both AWS EKS and Google GKE charge $0.60 per cluster-hour for clusters running versions outside the standard support window, roughly $438 per cluster per month, combining a base $0.10 management fee with a $0.50 surcharge.
How can I check if my nodes are still on cgroup v1?
Run stat -fc %T /sys/fs/cgroup/ on a node. A result of cgroup2fs means the node is already on cgroup v2 and safe for Kubernetes 1.35. Any other result, typically tmpfs, indicates the node is still on cgroup v1 and needs migration before upgrading.
What is replacing the Ingress NGINX controller?
The Kubernetes project recommends migrating to the Gateway API, which it describes as a more modern, secure, and extensible standard for routing traffic into clusters. Ingress NGINX moved to best-effort maintenance with a cutoff of March 2026, after which it’s archived with no further updates.
Does AKS let me upgrade directly from Kubernetes 1.33 to 1.35?
No. Azure AKS requires sequential minor-version upgrades, so a cluster on 1.33 must first upgrade to 1.34 before it can move to 1.35.
Why does Kubernetes only ship three releases a year now instead of four?
The project moved from a roughly quarterly, four-releases-a-year cadence to three releases a year starting in 2021, giving contributors and release engineering more time for planning, testing, and upgrade communication between versions.
