Kubernetes 1.37 lands on Wednesday, August 26, 2026, and it closes the book on a networking default that has run underneath the project since 2016. IPVS mode in kube-proxy is now formally deprecated, nftables takes over as the default packet-forwarding backend, and static pods lose the ability to reference secrets or config maps at all. None of that is optional. Operators who skip the pre-upgrade audit are the ones who will find out the hard way, sometime after the cluster comes back up.

The release ships roughly 86 tracked enhancements, with 16 graduating to stable and 22 landing as first-time alpha features, according to pre-release coverage from Cloudsmith and independent Kubernetes trackers. It arrives eight days after this article publishes, on a project that the Cloud Native Computing Foundation says now runs in production at 82% of organizations that use containers at all, up from 66% just two years ago. That adoption curve is exactly why a “boring” point release still makes front-page news in the cloud world: when 4 out of 5 container shops are running the software, a deprecated networking mode is not a footnote, it is a Tuesday-morning maintenance window for thousands of platform teams.

What’s Actually Shipping in Kubernetes 1.37

The headline promotion is metrics.k8s.io, the core Metrics API that kubectl top and the Horizontal Pod Autoscaler depend on. It graduates to General Availability after spending close to nine years in beta, according to the official Kubernetes v1.37 Sneak Peek post published by the project on July 31, 2026. Nine years in beta is not a typo. It is one of the longest-running beta features in Kubernetes history, and its graduation says something about how conservative the project has become about locking in APIs that millions of clusters already depend on informally.

SELinuxMount also reaches GA and, critically, ships enabled by default. Instead of relabeling a volume file by file on every mount, the kubelet now mounts with a context=<label> option and the whole volume gets the correct SELinux label in a single operation. That is a real performance win on large volumes, but it also changes runtime behavior on any cluster that has SELinux turned on, and several pre-release writeups flagged it as a feature that “may break existing workloads in Kubernetes clusters with SELinux enabled.” Cluster operators running RHEL, Fedora CoreOS, or other SELinux-enforcing nodes need to test this before the upgrade, not after.

KYAML output for kubectl also graduates to stable, giving operators a cleaner, more compact YAML serialization format directly from the CLI. Pod-level resource requests and device-level taints and tolerations for Dynamic Resource Allocation round out the stable graduations, continuing a multi-release effort to make GPU and specialized-hardware scheduling a first-class citizen rather than a bolt-on.

Kubernetes 1.37 Feature Graduation Table

FeatureStatus in 1.37What changes
metrics.k8s.io Metrics APIStable (GA)Graduates after ~9 years in beta; kubectl top and HPA now rely on a locked API
SELinuxMountStable, on by defaultWhole-volume relabeling in one pass; can break SELinux-enforcing clusters
KYAML output (kubectl)StableCompact YAML serialization becomes a supported CLI output format
Pod-level resourcesStableResource requests/limits can be set at the pod level, not just per container
DRA device-level taints/tolerationsStableFiner-grained scheduling control for GPUs and specialized hardware
Rootless kubeletBetaRuns the node agent without root privileges, narrowing the node attack surface
CompositePodGroup APIAlpha (new)New primitive for grouping pods, part of ~22 first-time alpha features
Topology-aware volume snapshotsAlpha (new)Snapshot behavior becomes zone/topology aware
StatefulSet Recreate strategyAlpha (new)Adds a third update policy alongside RollingUpdate and OnDelete

The Three Deprecations Cluster Operators Can’t Ignore

Three changes in 1.37 are being called out repeatedly across pre-release coverage because they break existing setups rather than just adding new options. First, kubectl run loses its --filename (or -f) flag entirely. The command is meant to generate a pod from CLI arguments like NAME and --image, not from a manifest file, and the project is finally enforcing that split.

Second, static pods can no longer reference secrets or config maps through configMapRef or secretRef. The PreventStaticPodAPIReferences feature gate, which previously let operators opt into or out of this restriction, has been removed outright, so the behavior is now unconditional. Any static pod manifest that leaned on this pattern for bootstrapping credentials will fail to start after the upgrade, full stop.

Third, and the one with the longest tail, kube-proxy’s IPVS mode is formally deprecated under KEP-5495, with nftables becoming the default backend for new installs. IPVS has been a supported, often-recommended kube-proxy mode since it was introduced as an alternative to iptables back in Kubernetes 1.11. Full removal isn’t scheduled until roughly v1.43, several releases away, but the deprecation clock is now running, and clusters that standardized on IPVS for its lower CPU overhead at scale need a migration plan.

Layered on top of those three is the continuing phase-out of cgroup v1. As of 1.37, the kubelet refuses to initialize on cgroup v1 nodes by default unless an operator explicitly overrides the check. Combined with the SELinuxMount default flip, that means a meaningful share of the upgrade risk in this release sits in node-level runtime behavior rather than in the API surface most teams are used to auditing.

Release Timeline: From Alpha to GA

The 1.37 cycle followed the standard cadence documented on the project’s Kubernetes Release Cycle page. The first alpha, 1.37.0-alpha.1, landed June 10, 2026. Enhancements freeze, the point at which every KEP targeting the release has to be locked in, hit on June 17, 2026. Code freeze followed on July 22-23, docs freeze landed August 5-6, and the first release candidate, 1.37.0-rc.0, shipped August 6, 2026. A second candidate, rc.1, followed on August 19. General availability is scheduled for August 26, 2026, roughly 16 to 17 days after rc.0, which tracks closely with the last three releases: 1.34 took 21 days from rc.0 to GA, while 1.35 and 1.36 each took 14.

That predictability is itself part of the story. Kubernetes moved from four releases a year down to three several years ago specifically to make each cycle less rushed and more testable, and 1.37’s clean run through alpha, freeze, and two release candidates without a slip is the project working the way it was redesigned to work.

Historical Context: Kubernetes Doesn’t Break Things Often, But When It Does…

Kubernetes has a track record of long, telegraphed deprecation cycles rather than sudden breaks, and 1.37 fits that pattern even where it stings. The most disruptive precedent is dockershim, the shim that let the kubelet talk to the Docker Engine directly. It was removed in Kubernetes 1.24 in 2022, more than a year after the project announced the plan, and it still caught teams off guard because so many CI pipelines and internal tools assumed Docker was always present under the hood. PodSecurityPolicy followed a similar arc: deprecated for several releases, then removed in Kubernetes 1.25, also in 2022, in favor of Pod Security Admission.

The IPVS deprecation in 1.37 is being handled the same way the project has handled its biggest breaking changes before: a formal deprecation notice, a multi-release runway (removal isn’t expected until roughly v1.43), and a documented migration path to nftables. The static-pod secret reference removal and the SELinuxMount default flip are more abrupt by comparison, closer in spirit to how PodSecurityPolicy’s replacement forced immediate manifest changes on anyone still using the old pattern.

Why This Release Matters for the AI Infrastructure Boom

The timing of 1.37 lines up with a broader shift the CNCF has been tracking for a year now. The foundation’s CNCF Annual Cloud Native Survey, released in January 2026, put Kubernetes production usage at 82% of container users, up from 66% in 2023, and specifically framed the project as the de facto operating system for AI workloads. Two-thirds of organizations running generative-AI models told the CNCF they use Kubernetes for inference. That is a very different workload profile than the stateless web services Kubernetes was originally built to orchestrate, and it explains why Dynamic Resource Allocation and device-level GPU scheduling keep showing up as stable features release after release, including in 1.37.

Pod-level resource requests, which graduate to stable in this release, matter more in an AI-inference context than they ever did for a typical microservice. A single inference pod might run several tightly coupled containers, a model server plus a sidecar for batching or telemetry, and being able to set resource limits at the pod level instead of summing per-container guesses makes capacity planning for GPU nodes noticeably less error-prone.

Managed Kubernetes: When Will EKS, AKS, and GKE Actually Support 1.37?

Upstream GA on August 26 doesn’t mean every managed Kubernetes service ships it that day. The three major clouds have very different version-adoption speeds, and that gap has real operational consequences for teams that can’t run self-managed control planes.

Google Kubernetes Engine moves fastest, typically making a new minor version available within 0 to 2 weeks of the upstream release, which tracks with Google’s origin as the company that created and open-sourced Kubernetes in the first place. Azure Kubernetes Service runs on a documented 12-month support policy for GA versions and, based on its own published version table, typically needs several weeks to move a new upstream release from preview to GA on the service. For the prior cycle, AKS listed 1.34 as upstream in August 2025, preview in October 2025, and GA in November 2025, a roughly three-month lag from upstream release to full AKS availability.

Amazon EKS runs the most conservative rollout of the three. According to AWS’s own documentation, new GA versions are typically supported on EKS “at the first patch version release” rather than the initial .0 release, and once a version does land, it gets 14 months of standard support followed by 12 months of extended support, for roughly 26 months of total availability on the platform. That conservatism is a feature for regulated workloads that can’t tolerate day-one bugs, but it also means EKS customers are routinely running Kubernetes versions that are two to three point releases behind what GKE customers already have in production.

Managed Kubernetes Version-Adoption Comparison

ProviderTypical lag from upstream GASupport window once releasedNotes
Google Kubernetes Engine (GKE)0-2 weeksRapid, Regular, Stable, and Extended channels, staggeredFastest adoption; Google originated the project
Azure Kubernetes Service (AKS)Several weeks to preview, ~3 months to GA12 months from GA1.34 took upstream Aug 2025 to AKS GA Nov 2025
Amazon EKSTypically at first patch release (1.X.1), sometimes later14 months standard + 12 months extended (~26 months total)Most conservative rollout of the three major clouds

Market Impact: Platform Teams Are Bracing for a Non-Trivial Upgrade Cycle

Kubernetes point releases don’t usually generate much noise outside SRE Slack channels, but 1.37 is landing differently because three separate changes compound into one upgrade window: a networking default flip, a mandatory security-labeling change, and a hard removal of a credential-mounting pattern in static pods. Independent trackers covering the release candidate cycle have been explicit that these three items alone justify treating 1.37 as a planned migration project rather than a routine bump, especially for clusters that mix IPVS, SELinux enforcement, and static pods with embedded credentials, which describes a meaningful slice of regulated, on-prem, and government Kubernetes deployments.

For FinOps and platform teams, the metrics.k8s.io graduation to stable is arguably the quieter but more consequential change. Every autoscaling and cost-attribution tool that reads from the Metrics API, including the Horizontal Pod Autoscaler itself, now depends on a locked, versioned contract instead of a nine-year beta that could technically change shape between releases. That stability is what lets third-party cost and capacity tools build more confidently on top of Kubernetes without chasing a moving target.

Competitive Comparison: How the Big Three Clouds Differ on Kubernetes Risk

The three major managed Kubernetes services aren’t just racing on version speed, they carry structurally different risk profiles that 1.37’s changes will interact with differently. GKE’s fast adoption cuts both ways: customers get new features sooner, but they also inherit new breaking changes, like the SELinuxMount default flip, on a shorter runway to test against. AKS’s middle-of-the-road pace gives operators a slightly longer buffer, and Microsoft’s own documentation shows the service maintaining parallel support windows across two or three concurrent minor versions, which helps teams stagger a 1.37 migration behind a validated 1.36 baseline.

EKS customers get the most breathing room by default, since AWS typically waits for the first patch release before shipping a new minor version at all, giving the upstream community time to surface and fix early 1.37 bugs before EKS customers ever touch it. The tradeoff is that EKS customers are structurally further behind on features like the DRA device-level taints and tolerations that ship stable in 1.37, which matters more the more a given organization’s workloads lean on GPU scheduling for AI inference.

What Platform Teams Should Do Before Upgrading

The pre-upgrade checklist circulating among Kubernetes operators ahead of the 1.37 GA date boils down to four items. Audit every static pod manifest for configMapRef or secretRef usage and migrate those credentials to a supported injection method before upgrading, since the removal is unconditional and has no override flag. Confirm whether any nodes are still running cgroup v1, since the kubelet will now refuse to start on them without an explicit override. Test SELinuxMount behavior in a staging cluster if SELinux enforcement is active anywhere in the fleet. And inventory kube-proxy configuration to see whether IPVS mode is in use, since it still works in 1.37 but is now on a deprecation clock with removal targeted for roughly v1.43.

# Check kube-proxy mode currently in use
kubectl get configmap kube-proxy -n kube-system -o yaml | grep mode

# Check for cgroup version on a node
stat -fc %T /sys/fs/cgroup/

# Search static pod manifests for the removed reference pattern
grep -rE "configMapRef|secretRef" /etc/kubernetes/manifests/

Predictions: Where Kubernetes Goes Next

Based on the release’s own trajectory and the surrounding ecosystem data, a few outcomes look likely over the next two to three release cycles.

  • IPVS usage will keep declining well before its v1.43 removal target. With nftables now the default and IPVS formally deprecated, most new clusters will never opt into the old mode, shrinking the migration population each release cycle.
  • DRA and GPU-aware scheduling will keep graduating features toward stable. Given that two-thirds of organizations running generative-AI models already use Kubernetes for inference per CNCF’s own survey, expect device-level scheduling controls to keep landing as stable, not alpha, in 1.38 and 1.39.
  • Rootless kubelet will be a 2027 GA candidate. It enters beta in 1.37, and Kubernetes’ typical alpha-to-GA arc for security-sensitive node features runs two to four releases, putting stable graduation somewhere around late 2026 to mid-2027.
  • EKS’s version lag will become a bigger competitive talking point. As GPU scheduling features increasingly ship stable upstream before EKS customers can use them, expect more head-to-head “which cloud gets Kubernetes features first” comparisons from AI infrastructure teams choosing a platform.
  • Expect a 1.38 release around late November to December 2026. On the project’s roughly three-releases-a-year cadence, with 1.37 landing August 26, the next enhancements freeze would fall in the same rhythm as prior cycles, pointing to a GA date in the final weeks of 2026.

Frequently Asked Questions

When exactly does Kubernetes 1.37 release?

General availability is scheduled for Wednesday, August 26, 2026, following release candidates rc.0 on August 6 and rc.1 on August 19, per the project’s own release schedule.

Will Kubernetes 1.37 break my existing cluster?

It can, depending on configuration. Static pods referencing secrets or config maps will fail to start, nodes on cgroup v1 will fail kubelet initialization by default, and clusters with SELinux enforcement enabled may see mount behavior changes since SELinuxMount is now on by default.

Is IPVS mode removed in Kubernetes 1.37?

No. IPVS mode in kube-proxy is deprecated, not removed, under KEP-5495. It still works in 1.37, but nftables is now the default backend for new installations, and full removal is targeted for roughly v1.43, several releases away.

When will EKS, AKS, and GKE support Kubernetes 1.37?

GKE typically supports a new version within 0-2 weeks of upstream GA. AKS has historically taken roughly three months from upstream release to full GA on the service. EKS is the slowest, typically waiting for the first patch release (1.37.1) rather than shipping the initial .0 release.

What is metrics.k8s.io and why does its graduation matter?

It’s the core Kubernetes Metrics API that powers kubectl top and the Horizontal Pod Autoscaler. It graduates to stable in 1.37 after nearly nine years in beta, giving autoscaling and cost-monitoring tools a locked, versioned contract to build against.

How many features are new in Kubernetes 1.37?

Pre-release tracking counted roughly 86 enhancements overall, with 16 graduating to stable and 22 landing as first-time alpha features, though the fully authoritative count ships in the official changelog on GA day.

How often does Kubernetes release new versions?

Roughly three times a year, down from four releases a year in the project’s earlier history. The change was made deliberately to give each cycle more testing time and reduce the risk of rushed features.

What should I check before upgrading to Kubernetes 1.37?

Audit static pod manifests for secret and config map references, confirm no nodes are still on cgroup v1, test SELinuxMount behavior if SELinux is enforced, and check whether kube-proxy is running in IPVS mode so you can plan a future migration to nftables.