Kubernetes 1.37 Sets Timelines to Retire IPVS Mode and kube-dns Packages as EKS and GKE Offer Rollback and EKS Prices Extended Support

Overview

Three separate threads in Kubernetes operations were reported in 2026: the Kubernetes 1.37 release set out timelines for retiring older components, managed services added ways to reverse a control-plane upgrade, and Amazon EKS publishes a per-cluster price for staying on a version past its standard support window. Read together, the sources describe the trade-offs an operator faces when deciding how quickly to upgrade. This analysis keeps the reported facts apart from what follows from them.

Background

The project’s support window. The Kubernetes project’s patch-release page says the community supports an active patch release series for roughly fourteen months: a twelve-month standard period followed by a two-month maintenance mode, after which the series reaches end of life. The same page lists Kubernetes 1.34 as having entered maintenance mode on August 27, 2026, with an End of Life date of October 27, 2026. It lists October 28, 2027 as the End of Life date for 1.37. By the date of this article, November 3, 2026, the 1.34 date has passed.

The managed-service window. For Amazon EKS, AWS’s version documentation says a minor version is under standard support for the first 14 months after release on EKS, then enters extended support for the next 12 months, for 26 months in total. The same page says “Extended support is enabled by default.” AWS’s pricing page states a charge of $0.10 per hour for each EKS cluster and $0.60 per hour for each cluster running a version covered by extended support, a rate that includes the $0.10.

The “one way door.” AWS’s announcement of EKS version rollbacks, dated July 1, 2026, says upgrading a control plane “has long been a one way door” because open-source Kubernetes does not support control-plane rollback. AWS writes that this has pushed organizations toward “bake periods, stagger groups, automated sign offs, and months long upgrade cycles”, and that teams managing hundreds of clusters often delay upgrades, leaving “clusters stuck on older versions”. Google’s blog post, dated November 5, 2025, uses similar language: “Upgrading a Kubernetes cluster has always been a one-way street”. Both statements appear in the vendors’ own posts.

The Herald has covered two related items. A Briefing on the kubelet and cgroup v1 described a Kubernetes Blog post saying the kubelet does not start on cgroup v1 nodes by default since v1.35. An earlier preview of Kubernetes 1.37 covered the release before it shipped.

Current Situation

What 1.37 schedules for removal. The Kubernetes 1.37 release announcement says the release consists of 67 enhancements: 16 graduated to Stable, 23 to Beta, 27 entering Alpha, and 1 deprecation or removal. Its deprecations section gives three timelines for older components:

• kube-dns. The project says it has retired the kube-dns subproject and that “It is expected that no new packages will be built for kube-dns after v1.40.” It tells operators to plan migration to CoreDNS. DevClass reports the same item in different words: those running kube-dns “must update their clusters before Kubernetes 1.40, or they will stop working.”
• kube-proxy IPVS mode. The release announcement says that by v1.40 ipvs mode “is expected to be disabled by default (still selectable via the feature gate)” and that by v1.43 support “would be removed entirely”. Network World reports the same roadmap, to disable the IPVS backend in 1.40 and remove it in 1.43, and says the transition began when Kubernetes 1.35 deprecated the IPVS mode. Sascha Grunert, a principal engineer on the OpenShift Node team at Red Hat, told Network World: “The main story is the iptables-to-nftables transition.”
• cgroup v1. The release announcement says that since v1.35 failCgroupV1 has defaulted to true, so the kubelet fails to initialize on nodes that still rely on cgroup v1 unless an explicit override is applied. It says the override “should be considered a short-term fix” and that cgroup v1 support is planned for removal in a future release. DevClass describes the override as one that “will be supported for a limited time.”

None of these three timelines carries a calendar date in the sources. The kube-dns and IPVS targets are version numbers (1.40 and 1.43), and the cgroup v1 removal has no version. The project’s patch-release page lists end-of-life dates only for releases that exist.

DevClass also cites a CNCF January survey, saying approximately 82 percent of container users run Kubernetes in production. That figure is DevClass’s report of the survey, not a count of how many clusters use the components above.

What rollback now offers. InfoQ, in a report dated July 26, 2026, says EKS lets practitioners revert a cluster’s control plane to its previous Kubernetes version within 7 days of an upgrade. Per InfoQ, rollbacks go one minor version at a time, and EKS runs cluster insights to check rollback readiness. AWS’s announcement says control-plane rollbacks apply to all EKS clusters, node rollbacks are available for clusters running EKS Auto Mode, and the feature carries no additional cost. AWS’s documentation adds two limits: to roll back to a version in extended support, the cluster’s upgrade policy must first be changed, and “Clusters that were automatically upgraded at the end of extended support cannot be rolled back.”

InfoQ compares providers. It reports that Azure AKS offers only partial support, limited to node pool rollbacks, and that GKE introduced control-plane minor-version rollbacks with GKE 1.33. Google’s post describes the mechanism as “KEP-4330: Compatibility Versions”, which creates an “emulated version” for the control plane: the binary is upgraded first while the emulated version stays at the previous one, giving a validation window before the emulated version is advanced. AWS’s post contrasts this with its own approach, saying EKS returns a cluster to “a fully validated previous version that ran in production, not an emulation of it.”

InfoQ also relays reactions from practitioners. Ismail Baig, a senior cloud and DevOps leader at Uniphore, wrote that before this, teams relied on blue/green cluster deployments that “doubled infra cost during upgrades” or manual snapshots. Corey Quinn, chief cloud economist at The Duckbill Group, wrote in his newsletter: “An undo button for Kubernetes upgrades, arriving only after years of ops teams building bake periods and month-long ceremonies to avoid the one-way door.”

What staying put costs. The AWS pricing page works an example: a cluster created on the day a version is released on EKS and left on it for 26 months pays $0.10 per hour for the first 14 months and $0.60 per hour for the remaining 12, an average of $0.33 per hour. The Herald’s own arithmetic, from AWS’s two published rates: the $0.50 per hour difference comes to $4,380 per cluster over 8,760 hours, the number of hours in a 365-day year. AWS’s documentation also says that at the end of extended support, control planes are updated automatically at a time AWS cannot specify, and that nodes in self-managed groups and managed node groups remain on the previous version.

Implications

The points below describe what the cited sources say follows from these developments, and where they leave gaps.

Upgrade timing is now partly a pricing decision on EKS. The project’s own window is roughly fourteen months, and the EKS documentation says its standard window is 14 months after a version reaches EKS and that extended support is on by default. The documented rates mean a cluster that stays on a version past standard support pays six times the base cluster fee. Whether that is material depends on cluster count, which none of the sources reports.

Rollback addresses one risk, not the whole removal schedule. AWS presents rollback as a response to teams delaying upgrades for lack of a recovery path. The documented limits bound that: a seven-day window, one minor version at a time, a policy change before returning to an extended-support version, and no rollback for clusters upgraded automatically at the end of extended support. The removals described above are, in the sources’ wording, tied to nodes (the kubelet refusing to start on cgroup v1 nodes) and to a networking component (kube-proxy’s IPVS mode). The sources describe EKS rollback as reverting the control plane, plus Auto Mode nodes. They do not say how rollback interacts with node-level or kube-proxy changes in a given cluster, so that interaction is an open question.

Two vendors describe the same problem in different ways. AWS and Google both call the status quo a one-way path, and both describe a rollback feature as the remedy. They differ in design, which Google’s and AWS’s posts each state in their own terms: an emulated-version validation window on one side, a return to a previously running version on the other. InfoQ’s report adds that AKS currently offers a narrower form, at node-pool level. Quinn’s comment frames the feature as late rather than novel. These are the accounts the sources give; no independent comparison of how the features behave in production appears in them.

The retirement targets are expressed as versions. Operators running kube-dns or IPVS mode have targets of 1.40 and 1.43, and the kube-dns wording differs slightly between the project (no new packages after v1.40) and DevClass (clusters “will stop working”). The sources do not say whether that difference reflects a technical distinction or a paraphrase. Operators who want to see which kube-proxy mode they run can use the command the release announcement provides.

What the sources do not establish. They do not give calendar dates for Kubernetes 1.40 or 1.43. They do not report how many clusters still use kube-dns, IPVS mode or cgroup v1 nodes, how many EKS customers are on extended support, or how often rollbacks are used, since EKS rollback is recent. They also do not compare the Azure AKS and GKE offerings in operational detail beyond the summary InfoQ gives.