Kubernetes 1.37 is scheduled for release on August 26th 2026, and it’s full of really exciting updates for security, DRA, networking and more! We exclude enhancements with the status of “Deferred” or “Removed from Milestone” and we are seeing 86 enhancements in all listed within the official tracker. What are we looking forward to in Kubernetes 1.37?

The 1.37 release includes 28 changes tracked as ‘Graduating’ in this Kubernetes release. From these, just 16 enhancements are graduating to stable, such as KYAML output for kubectl and pod-level resources, as well as device-level taints and tolerations enhancement for DRA now graduating to GA.

A long list of 34 Net New to Alpha enhancements are in the tracker, including the ability to connect to a localhost NodePort service on NFTables (IPv4 & IPv6) using a userspace proxy (#6032) as well as an EnforcedRollingUpdate flag being added to StatefulSet rolling update strategies (#3541).

As always, let’s jump into all of the major graduations, deferred enhancements and deprecations scheduled for Kubernetes 1.37.

Kubernetes 1.37 – Editor’s pick:

Here are a few of the changes that Cloudsmith team are most excited about in the 1.37 release:

#6072 Standard numaNode device attribute for DRA

Kubernetes 1.37 introduces the standardisation of resource.kubernetes.io/numaNode (Non-Uniform Memory Access) as a globally recognised DRA device attribute. I’m excited to see this Alpha enhancement in 1.37. It unifies how hardware-specific memory topologies, like the memory controller, are exposed alongside existing attributes like pcieRoot. By establishing a single, consistent naming convention and introducing specialised helper functions into the deviceattribute library, Kubernetes users should now be able to achieve seamless, cross-driver co-placement and advanced attribute matching (matchAttribute) for complex multi-GPU, CPU, and SR-IOV hardware configs where PCIe topologies alone were insufficient. Moving this complexity out of custom code and into a native standard means platform teams can finally guarantee high-performance, low-latency hardware alignment with absolute, cross-cloud portability.

Nigel Douglas - Head of Developer Relations


#5758 Per-container ulimits configuration

I am incredibly excited to see this enhancement land in Kubernetes 1.37 because it finally tackles a long-standing headache for anyone running heavy, production-grade workloads. This new KEP introduces a ulimits field to the Container.SecurityContext within the Pod API. This grants users fine-grained, per-container control over POSIX resource limits (such as open files and process counts) on Linux nodes. This native support eliminates the need for brittle, non-portable workarounds like modifying host configs or custom entrypoint scripts, allowing high-concurrency workloads and databases to optimise performance securely and in a scalable way in multi-tenant clusters. This change will propagate these limits directly to container runtimes via the CRI, utilising a runtime handler to dynamically detect node support. For years, platform engineers have had to jump through hoops just to prevent too many file open errors. Finally bringing this natively into the Pod API is a massive win for cluster security.

Jason Myers - Technical Content Marketer

#1710 Speed up recursive SELinux label change

Seeing the SELinux mount volume (SELinuxMount) graduating to stable is great from a security standpoint. It fundamentally changes how volumes are attached to containers on systems with SELinux in enforcing mode. Traditionally, the container runtime had to recursively relabel every individual file and directory on a volume before a Pod could even start - a process that was notoriously slow for massive datasets, error-prone on near-full disks, and impossible on read-only filesystems. By switching the default behaviour to leverage the Linux kernel's native “-o context“ mount option, Kubernetes can now instantly assign the correct SELinux label to an entire volume at the mount point without a time-consuming file-system walk. While this drastically accelerates Pod startup times, its truest impact is defensive. By eliminating the need for the container runtime to dynamically change file permissions on the fly, this enhancement effectively blocks host-path exploitation techniques (like CVE-2021-25741) where an attacker attempts to trick the cluster into relabelling and exposing critical host files.

Sean Meahan - Senior Software Engineer

Apps in Kubernetes 1.37

#3541 Add Recreate Update Strategy to StatefulSet

Stage: Net New to Alpha
Feature group: sig-apps

The introduction of the Recreate Update Strategy for StatefulSets addresses a long-standing stuck rollout issue that has plagued users for years. Previously, if a StatefulSet update was triggered with a broken config (such as a non-existent Docker image), the controller would wait indefinitely for the failing Pod to become Ready before proceeding. Even if a user reverted the config to a known-good state, the StatefulSet would refuse to manage or fix the broken Pod because it was stuck in a validation loop, forcing users to manually delete the Pod to unblock the controller.

The new Recreate strategy provides a more aggressive alternative to the standard RollingUpdate. It allows the StatefulSet controller to prioritise reaching the desired state by terminating existing Pods before creating new ones, effectively bypassing the waiting for ready deadlock. This change transforms what was previously documented as a known issue into a manageable configuration, ensuring that automated pipelines can recover from misconfigurations without manual human intervention.

#5547 WAS: Integrate Workload APIs with Job controller

Stage: Major Change to Alpha
Feature group: sig-apps

The enhancement is a major step forward for native support to complex batch and AI/ML workloads. Historically, Kubernetes scheduled individual Pods independently, which caused issues for distributed training jobs that require all participants to start simultaneously (gang scheduling). This enhancement introduces the Workload API and a decoupled PodGroup object to act as a link between high-level controllers (like the Job controller) and the scheduler. By integrating these, the Job controller can now automatically generate a Workload representation of itself, allowing the scheduler to understand the resource requirements and scheduling constraints of the entire group of pods rather than treating them as isolated units.

#961 maxUnavailable for StatefulSets

Stage: Major Change to Beta
Feature group: sig-apps

This enhancement introduces a maxUnavailable parameter (either an absolute number or a percentage) to the RollingUpdate strategy for Kubernetes StatefulSets. Currently, StatefulSet updates are limited to processing one pod at a time, which can severely slow down rollouts for large clusters or applications with long startup tasks. By allowing multiple pods to be updated simultaneously, this feature brings StatefulSets closer to feature parity with Deployments, enabling significantly faster rollout times for stateful clustered applications that can tolerate having multiple replicas or followers offline at once.

API in Kubernetes 1.37

#6164 Eliminating Internal API Types

Stage: Net New to Alpha
Feature group: sig-api-machinery

This enhancement seeks to optimise the kube-apiserver performance and simplify its codebase by eliminating the resource-heavy, traditional internal API types (__internal) that act as conversion and validation hubs. Because many APIs have matured to a stable v1 version, maintaining these distinct internal types is no longer necessary and incurs significant CPU, memory, and maintenance overhead during request processing and large list operations. The project will execute in two phases. First, it makes internal types memory-identical to preferred versioned types to achieve up to a 5.7x speedup and a 3.3x reduction in memory usage during conversions. Secondly, it replaces internal types entirely with Go type aliases before eventually removing them altogether.

#6178 Concurrent Watch Object Decode

Stage: Major Change to Beta
Feature group: sig-api-machinery

This enhancement proposes enabling the ConcurrentWatchObjectDecode feature gate by default to resolve severe API server scaling and timeout issues during CRD version migrations. Currently, when a controller establishes a watch on a cold cache, the kube-apiserver fetches the stored CRD versions from etcd and converts them sequentially to the requested version before returning them. At high scale (like, with clusters over 10,000 workloads running Kueue), this sequential conversion process can take several minutes, triggering etcd timeouts and causing the API server to fail with 500 errors. Enabling this feature by default allows the API server to decode and convert these watch events concurrently, drastically reducing processing time and preventing cluster failures during large-scale version upgrades.

#4192 Move Storage Version Migrator in-tree

Stage: Graduating to Stable
Feature group: sig-api-machinery

Added in v1.35 as beta (disabled by default), the in-tree Storage Version Migrator (SVM) controller within the Kube-Controller-Manager (KCM) is finally graduating to stable in v.1.37. This KEP simplifies and automates data rewrites for at-rest storage. Resource rewrites are essential when a preferred storage schema changes (like v1beta1 to v1) or when encryption-at-rest keys are updated. Unfortunately, performing this manually via kubectl is error-prone and scales poorly. By migrating the original out-of-tree SVM migrator controller into the core codebase under a new storagemigration.k8s.io API group, this proposal allows users to easily trigger efficient data migrations utilising the garbage collection cache. Once a migration successfully completes, the controller also handles updating the CRD status to safely remove references to old, unused storage versions.

#4222 CBOR Serialiser

Stage: Graduating to Beta
Feature group: sig-api-machinery

This proposal introduces support for the CBOR data format in Kubernetes API servers and clients as a high-performance alternative to JSON. While native Kubernetes resources use Protobuf to minimise CPU time and heap churn, CRDs cannot easily use Protobuf due to its reliance on compile-time code generation. Adopting CBOR as a self-describing binary format solves this gap. The benchmarks show it can make custom resource encoding up to 8x faster and decoding 2x faster. The rollout includes standard content negotiation (application/cbor), support for streaming via CBOR sequences, and client-side feature gates with automatic JSON fallbacks to ensure seamless backward compatibility with older API servers.

CLI in Kubernetes 1.37

#5295 KYAML

Stage: Graduating to Stable
Feature group: sig-cli

I mentioned back in the 1.34 release how the introduction of KYAML will solve the age-old “Norway” problem. Finally graduating to Stable status in the 1.37 release, KYAML is a Kubernetes-compliant YAML output format that uses a specific subset of standard YAML (called flow style) that eliminates common syntax pitfalls. By always using curly brackets {} for maps, square brackets [] for lists, and double “” quotes for strings, it removes whitespace sensitivity and type-coercion bugs while still allowing comments and trailing commas. This will definitely improve the overall reliability of Kubernetes going forward.

Kubernetes 1.37 Networking

#4762 Allows setting any FQDN as the pod's hostname

Stage: Graduating to Stable
Feature group: sig-network

This KEP introduced a new hostnameOverride field to the Kubernetes podSpec, allowing users to set any arbitrary FQDN up to 64 bytes as a pod's hostname. Aimed at easing the migration of legacy applications (like Kerberos) that relied on specific hostnames for authentication or permissions, this feature bypasses default cluster-suffix restrictions and writes the custom FQDN directly to the pod's /etc/hosts file (excluding Windows containers). To mitigate kernel limits, validation will reject strings over 64 bytes or those violating RFC 1123 standards, and the field is strictly mutually exclusive with setHostnameAsFQDN and hostNetwork.

#5311 Relaxed validation for Services names

Stage: Graduating to Stable
Feature group: sig-network

Graduating to Stable in 1.37, this relaxed ServiceName validation feature is an improvement designed to bring the naming constraints of Service resources into alignment with other standard Kubernetes objects. Historically, Services were restricted by a stricter DNS-1035 label standard (NameIsDNS1035Label), which prohibited names from starting with a numeric digit. This update transitions the validation to the more flexible NameIsDNSLabel standard, finally allowing users to create Services with names like 123-backend or 8080-proxy.

#6032 localhost NodePort userspace proxy for NFtables

Stage: Net New to Alpha
Feature group: sig-network

This net new enhancement introduces an opt-in userspace TCP proxy to the nftables kube-proxy backend. This proxy bridges a critical feature gap by allowing workloads to access NodePort services via localhost (IPv4 and IPv6) under nftables. This is a capability that currently exists for iptables but lacks a native nftables equivalent. Activated explicitly via the --nodeport-addresses flag, this Layer 4 forwarder supports key features like ClientIP session affinity and Local external traffic policies, while intentionally excluding non-TCP protocols (UDP/SCTP) and leaving the iptables and IPVS backends completely unchanged.

#5343 Make NFtables the default kube-proxy backend

Stage: Net New to Alpha
Feature group: sig-network

Continuing on from the #6032 KEP mentioned above, Kubernetes 1.37 is laying the groundwork to eventually make nftables the default backend for kube-proxy. This will ultimately replace the older iptables and IPVS systems entirely. Because this shift requires newer Linux kernels (version 5.13 or higher) and continuous stability testing, the 1.37 release focuses on preparing users rather than making an immediate switch. Starting in this version, Kubernetes will actively issue log warnings to clusters that rely on the default iptables setting, advising administrators to either explicitly lock in iptables or begin migrating to nftables before the official default switch occurs in Kubernetes 1.40. This all culminates with the removal of IPVS mode in kube-proxy (#5495).

Kubernetes 1.37 Authentication

#3926 Handling undecryptable resources

Stage: Graduating to Beta
Feature group: sig-auth

Graduating to beta, this enhancement aims to solve a long-standing issue where a resource that cannot be decrypted or decoded completely blocks Kubernetes API operations like list and delete, forcing admins to manually modify etcd storage to fix it. The proposal introduces more informative retrieval error messages to pinpoint the broken data, along with a new DeleteOption that allows admins to bypass storage checks and safely delete malformed resources directly through the K8s API. While this simplifies recovery in scenarios like lost encryption keys or stuck namespace deletions, it’s worth noting that forcefully deleting a broken resource will bypass finalisers and garbage collection, potentially leaving behind orphaned underlying processes.

#4317 Pod Certificates

Stage: Graduating to Stable
Feature group: sig-auth

Graduating to stable, this enhancement introduced a secure and automated mechanism to deliver X.509 certificates directly to pods without using bearer tokens, which helps preserve the integrity of mTLS auth. It establishes two key components: a PodCertificateRequest API specifically for pod certificate issuance, and a PodCertificate projected volume source that lets the kubelet provision keys and certs automatically. By shifting the responsibility of enforcing node security boundaries to the K8s API-Server, this mechanism makes it significantly easier and safer for both in-tree and third-party tools (like HashiCorp Vault) to issue client and server certificates via standard PKCS#10 requests.

#3257 ClusterTrustBundles

Stage: Graduating to Beta
Feature group: sig-auth

This update introduces ClusterTrustBundles (initially in certificates.k8s.io/v1alpha1), a new cluster-scoped Kubernetes API designed to safely distribute X.509 trust anchors (root or intermediate certificates) to workloads. Previously, clusters relied on clumsy workarounds like copying a ConfigMap into every namespace or hardcoding static CA certs.

To complement this, a new kubelet projected volume source allows workloads to easily consume these trust anchors directly from the container's filesystem, automatically updating them on the fly during certificate rotations without requiring application restarts.

apiVersion: v1
kind: Pod
metadata:
  namespace: client
  name: client
spec:
  containers:
    - name: main
      image: my-image
      volumeMounts:
        # 1. Mount the projected volume inside your container
        - mountPath: /var/run/signer-trust-anchors
          name: trust-volume
          readOnly: true
  volumes:
    # 2. Define the projected volume with the new clusterTrustBundle source
    - name: trust-volume
      projected:
        sources:
          - clusterTrustBundle:
              signerName: example.com/server-tls
              labelSelector:
                matchLabels:
                  example.com/cluster-trust-bundle-version: "live"
              path: ca_certificates.pem

Kubernetes 1.37 Nodes

#2837 Pod level resources

Stage: Graduating to Stable
Feature group: sig-node

This enhancement extends the Pod API to now support Pod-level resource requests and limits (specifically for CPU, memory, and hugepages) alongside existing container-centric settings. By allowing tightly coupled containers within a pod to share a unified resource pool, this feature simplifies resource management and eliminates the need for meticulous, per-container configs. Ultimately, this change enables dynamic intra-pod resource sharing, which reduces waste, improves overall resource utilisation, and better accommodates workloads with unpredictable or bursty demands.

#5474 Enable Writable cgroups for unprivileged containers

Stage: Net New to Alpha
Feature group: sig-node

Introduced as an Alpha stage feature in 1.37, we’re seeing a new CgroupWritable (or CgroupOptions) field under the container-level SecurityContext. This enhancement allows unprivileged containers to securely manage and write to their own sub-cgroups, providing fine-grained resource control directly through the Kubernetes API instead of relying on broad, less-secure runtime-level configurations.

#5328 Node Declared Features

Stage: Graduating to Stable
Feature group: sig-node

Graduating to stable in 1.37, the proposed Node Declared Features framework allows Kubernetes nodes to dynamically advertise their active, feature-gated capabilities directly to the control plane. By exposing these features, components like the scheduler and admission controllers can automatically manage version-skew issues. This includes activities like ensuring pods are only scheduled on compatible nodes and blocking unsupported API operations, all without requiring users to manually configure complex taints, tolerations, or node labels.

#5758 Per-container ulimits configuration

Stage: Net New to Alpha
Feature group: sig-node

Kubernetes 1.37 introduces a native ulimits field to Container.SecurityContext and the CRI. This allows users to configure fine-grained POSIX resource limits (like open files and process counts) per container, ultimately eliminating the need for host-level workarounds that could otherwise cause issues. To maintain system stability and cluster security, the proposal restricts the feature to the privileged (PSS) level, enforces strict validation, and even integrates with newly-graduated node-declared features to ensure pods requiring custom limits are only scheduled on compatible nodes.

Node-specific DRA enhancements in 1.37

#5945 Optional Node Preparation

Stage: Net New to Alpha
Feature group: sig-node

By allowing drivers to specify at the ResourceSlice level that node-local setup is unnecessary, the kubelet can bypass standard gRPC preparation and unpreparation calls. This bypass speeds up the container lifecycle, allowing container startup & termination to proceed immediately for supported devices.

#4817 Resource Claim Status with possible standardised network interface data

Stage: Graduating to Stable
Feature group: sig-node

Graduating to stable in 1.37, this KEP introduces a new Devices field (a slice of AllocatedDeviceStatus) to the Kubernetes ResourceClaim.Status API. This allows DRA drivers to report arbitrary, driver-specific status data, such as operational conditions and standard networking details (IPs, MAC addresses, and interface names) directly to the resource claim. The enhancement improves observability, simplifies troubleshooting, and enables third-party controllers to integrate allocated resources into higher-level network services.

#5304 Device Attributes in Downward API

Stage: Graduating to Beta
Feature group: sig-node

This framework-assisted method exposes DRA device metadata like PCIe addresses and mediated device UUIDs directly to workloads via standard JSON files mounted using the Container Device Interface (CDI). By allowing DRA drivers to populate a metadata field (either immediately during resource preparation or deferred via NRI hooks during sandbox creation), the framework automatically handles file generation, directory structuring, and container bind-mounting. This design provides proper container-level isolation per resource request, ensures backward compatibility, and eliminates the need for complex, error-prone custom controllers currently required by workloads like KubeVirt to query the Kubernetes API.

Scheduling in Kubernetes 1.37

#5836 Scheduler Preemption for In-Place Pod Resize

Stage: Net New to Alpha
Feature group: sig-scheduling

Updating the Kubernetes Scheduler to automatically actively create space for Deferred In-Place Pod Resizes by preempting (or evicting) lower-priority pods on fully-utilised nodes certainly aligns the behaviour with the preemption logic used for newly created pods. Currently, in-place resizes that exceed a node's capacity do not trigger preemption, resulting in deferred status and requiring manual intervention or risking disruptive external controller behaviours (like OOM-kills or node rescheduling). While the proposal aims to automate resource scaling and reduce workload disruptions, it intentionally keeps broader scheduling tasks (like binding) out of scope and highlights key risks, such as performance overhead from deferred pod queues, double-preemption during scheduler restarts, and the potential for over-preemption. This will all be addressed using aligned resource-fit calculation logic by Beta.

#5055 DRA: device taints and tolerations

Stage: Graduating to Stable
Feature group: sig-scheduling

Graduating to Stable in 1.37, this enhancement introduces device taints and tolerations to DRA. This improvement mirrors the existing node taint model to handle hardware issues gracefully. By applying taints via DRA drivers or user-defined DeviceTaintRules, clusters can block new pods from scheduling onto degraded or offline hardware (NoSchedule) or evict currently running pods for maintenance (NoExecute). Users can bypass specific taints by adding matching tolerations directly to their ResourceClaim. This allows workloads to run on degraded devices or during testing at their own risk. All while informational taints can be published for hardware monitoring without altering scheduling.

#6080 DRA: Derived Attributes

Stage: Net New to Alpha
Feature group: sig-scheduling

To eliminate the rigidity of exact attribute matching across different hardware vendors, this net new improvement introduces derivedAttributes to DRA. By evaluating scoped CEL expressions on candidate devices to synthesise virtual grouping keys, users can easily pair GPUs and NICs without waiting for vendors to standardise attribute names. Here’s a quick sample of bridging disparate schema within the ResourceClaim:

apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
  name: gpu-numa-alignment-claim
spec:
  devices:
    requests:
    - name: gpu
      exactly:
        deviceClassName: gpu.nvidia.com
        count: 8
        # [NEW]: Compute virtual grouping key from GPU driver
        derivedAttributes:
        - name: shared-numa-node
          expression: "device.attributes['gpu.nvidia.com'].numa"
    - name: nic
      exactly:
        deviceClassName: dranet
        count: 1
        # [NEW]: Compute virtual grouping key from dranet driver
        derivedAttributes:
        - name: shared-numa-node
          expression: "device.attributes['dra.net'].numaNode"
    constraints:
    # Match the derived attribute across both requests using existing matchAttribute
    - matchAttribute: shared-numa-node
      requests: [gpu, nic]

Storage in Kubernetes 1.37

#1710 Speed up recursive SELinux label change

Stage: Graduating to Stable
Feature group: sig-storage

Graduating to Stable in the 1.37 release, speeding-up SELinux volume mounting by replacing the slow, recursive file-by-file relabelling process with the Linux -o context mount option is a huge improvement. This change applies the required SELinux context to an entire volume at once. Having been rolled out across Kubernetes 1.36 and 1.37 through feature gates like SELinuxMountReadWriteOncePod and SELinuxMount, the new default applies context mounting automatically while providing opt-out mechanisms (SELinuxChangePolicy: Recursive) for edge cases that rely on traditional recursive relabelling.

#4049 Add storage capacity scoring

Stage: Graduating to Beta
Feature group: sig-storage

This Beta improvement proposes extending the Kubernetes VolumeBinding plugin to score nodes during dynamic persistent volume provisioning based on available storage capacity. Users can configure this global policy to either prioritise nodes with the most free space (the default, to allow for future volume expansion) or nodes with the least sufficient space (to pack workloads and reduce node count/costs).

#5936 Add user fields to atomic write volumes

Stage: Net New to Alpha
Feature group: sig-storage

Graduating to Alpha in 1.37, we’re seeing optional DefaultUser and User fields for atomic write volumes (ConfigMap, Secret, DownwardAPI, and Projected) to allow setting custom owner UIDs on mounted files. This solves a long-standing issue for apps with strict file-ownership requirements (like MongoDB or SSHD) that currently default to root ownership. It’s also worth noting it enables non-root pods running under restricted security policies to set correct file permissions without needing privileged initContainers to run chown.

Autoscaling in Kubernetes 1.37

#4951 Configurable tolerance for Horizontal Pod Autoscalers

Stage: Graduating to Stable
Feature group: sig-autoscaling

The Horizontal Pod Autoscaler (HPA) currently uses a fixed, cluster-wide default tolerance of 10% to prevent rapid scaling churn - called "flapping". Unfortunately, this is a global setting and is often too coarse. Especially for large or sensitive workloads where minor percentage shifts represent hundreds of pods or delay critical scale-ups. This KEP adds an optional, per-HPA tolerance field (within spec.behavior.scaleUp and scaleDown) that allows users to override the global default on a per-workload basis. By letting devs fine-tune scaling thresholds independently for scale-up and scale-down actions, HPAs can become significantly more responsive without altering the core scaling algorithm or introducing major operational risk.

#2021 Support scaling to/from zero pods for object/external metrics

Stage: Major Change to Beta
Feature group: sig-autoscaling

In the Kubernetes 1.37 release, there were improvements to the existing Beta release, natively allowing the HPA to scale workloads down to zero replicas (minReplicas: 0) and back up based on object or external metrics (such as message queue length). The key change to Beta introduces an explicit ScaledToZero status condition on the HPA object. This enables the controller to differentiate between an automated scale-to-zero event and a manually paused deployment. The changes here also expanded end-to-end and integration test suites to ensure safe cluster behaviour.

Instrumentation in Kubernetes 1.37

#5808 Native Histogram Support for Kubernetes Metrics

Stage: Graduating to Beta
Feature group: sig-instrumentation

Graduating from Alpha status to Beta in 1.37, this KEP introduces a NativeHistograms feature gate to expose Prometheus Native Histograms across Kubernetes control plane components alongside existing classic metrics. By transitioning from fixed bucket boundaries to dynamic exponential buckets, Native Histograms deliver a ~10x reduction in time series storage overhead and significantly sharper latency resolution for detecting performance issues. The dual-exposition model ensures full backward compatibility, allowing team-level migration without breaking existing dashboards or alerts.

Deprecations in Kubernetes 1.37

#5495 Remove IPVS mode in kube-proxy

Stage: Deprecation/Removal
Feature group: sig-network

Kubernetes 1.37 outlines the deprecation and eventual removal of the under-maintained IPVS backend mode in kube-proxy, steering users instead toward the newer nftables backend as older kernels phase out of LTS by the end of 2026. Rather than archiving the code in a separate repository, the project plans a clean, multi-release removal via the KubeProxyIPVS feature gate. The transition spans five stages: starting with deprecation warnings and documentation updates back in v1.35 (Stage 1), introducing the current feature gate in v1.37 (Stage 2), before disabling IPVS by default in v1.40 (Stage 3), and fully removing the IPVS codebase in v1.43 (Stage 4). The release team cleaned up the feature gate itself in v1.46 (Stage 5).

Deferred / Removed from Milestone

#5825 CRI List Streaming

Stage: Major Change to Beta
Feature group: sig-node
Status: Deferred

#4680 Add Resource Health Status to the Pod Status for Device Plugin and DRA

Stage: Net New to Alpha
Feature group: sig-node
Status: Deferred

#6047 Manifest-Based Authorisation via RBAC

Stage: Net New to Alpha
Feature group: sig-auth
Status: Removed from Milestone

#5978 DRA: ClusterResourceClaimTemplate

Stage: Net New to Alpha
Feature group: sig-node
Status: Removed from Milestone

Timeline of v.1.37 Kubernetes Release

Kubernetes users can expect the v1.37 release process to unfold throughout August 2026, with past milestones including the start of the cycle back in May and the Enhancements Freeze on June 16th. Upcoming technical milestones involve the Code & Test Freeze on July 22nd - the week before Kubecon Japan. The official v1.37 release comes out on Wednesday the 26th August.

Kubernetes Release Archive

• Kubernetes 1.37 – What you need to know
• Kubernetes 1.36 – What you need to know
• Kubernetes 1.35 – What you need to know
• Kubernetes 1.34 – What you need to know
• Kubernetes 1.33 – What you need to know