--- title: "Kubernetes 1.37: What You Need to Know | Key Features" description: "Explore what's coming in Kubernetes 1.37, including key enhancements across security, DRA, networking, and SIG-apps ahead of the August 2026 release." canonical_url: "https://cloudsmith.com/blog/kubernetes-1-37-what-you-need-to-know" last_updated: "2026-07-21T10:03:24.681Z" --- # Kubernetes 1.37: What You Need to Know | Key Features [**Kubernetes 1.37**](https://www.kubernetes.dev/resources/release/#kubernetes-v137) 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**](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs++). What are we looking forward to in Kubernetes 1.37? The 1.37 release includes **28 changes** tracked as ‘[**Graduating**](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-status%3ADeferred%2C%22Removed+from+Milestone%22+enhancement-type%3AGraduating)’ in this Kubernetes release. From these, just [**16 enhancements**](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-status%3ADeferred%2C%22Removed+from+Milestone%22+enhancement-type%3AGraduating+stage%3AStable) are graduating to stable, such as **KYAML** output for kubectl and **pod-level resources**, as well as [**device-level taints and tolerations**](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-status%3ADeferred%2C%22Removed+from+Milestone%22+enhancement-type%3AGraduating+stage%3AStable&pane=issue&itemId=192389275&issue=kubernetes%7Cenhancements%7C5055) enhancement for DRA now graduating to GA. A long list of [**34 Net New to Alpha**](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-status%3ADeferred%2C%22Removed+from+Milestone%22+enhancement-type%3A%22Net+New%22+stage%3AAlpha) enhancements are in the tracker, including the ability to connect to a localhost NodePort service on NFTables (IPv4 & IPv6) using a userspace proxy ([**#6032**](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-status%3ADeferred%2C%22Removed+from+Milestone%22+enhancement-type%3A%22Net+New%22+stage%3AAlpha&pane=issue&itemId=191511709&issue=kubernetes%7Cenhancements%7C6032)) as well as an `EnforcedRollingUpdate` flag being added to StatefulSet rolling update strategies ([**#3541**](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-status%3ADeferred%2C%22Removed+from+Milestone%22+enhancement-type%3A%22Net+New%22+stage%3AAlpha&pane=issue&itemId=191511657&issue=kubernetes%7Cenhancements%7C3541)). 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**](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs++numa&pane=issue&itemId=192389433&issue=kubernetes%7Cenhancements%7C6072) Kubernetes 1.37 introduces the standardisation of `resource.kubernetes.io/numaNode` ([Non-Uniform Memory Access](https://edera.dev/stories/numa-part-1-cores-memory-and-the-distance-between-them)) 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](https://learn.microsoft.com/en-us/windows-hardware/drivers/network/overview-of-single-root-i-o-virtualization--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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-status%3ADeferred%2C%22Removed+from+Milestone%22+enhancement-type%3A%22Net+New%22+stage%3AAlpha+ulimits&pane=issue&itemId=195260967&issue=kubernetes%7Cenhancements%7C5758)** 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](https://en.wikipedia.org/wiki/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**](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-status%3ADeferred%2C%22Removed+from+Milestone%22+enhancement-type%3AGraduating+SELinux&pane=issue&itemId=191511643&issue=kubernetes%7Cenhancements%7C1710) 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](https://access.redhat.com/security/cve/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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-apps&pane=issue&itemId=191511657&issue=kubernetes%7Cenhancements%7C3541) _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**](https://github.com/kubernetes/kubernetes/issues/67250) 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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-apps&pane=issue&itemId=195035647&issue=kubernetes%7Cenhancements%7C5547) _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**](https://kubernetes.io/docs/concepts/scheduling-eviction/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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-apps&pane=issue&itemId=195507839&issue=kubernetes%7Cenhancements%7C961) _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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-api-machinery&pane=issue&itemId=196648127&issue=kubernetes%7Cenhancements%7C6164) _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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-api-machinery&pane=issue&itemId=197763324&issue=kubernetes%7Cenhancements%7C6178) _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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-api-machinery&pane=issue&itemId=193320712&issue=kubernetes%7Cenhancements%7C4192) _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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-api-machinery&pane=issue&itemId=193320721&issue=kubernetes%7Cenhancements%7C4222) _CBOR Serialiser_ **Stage:** Graduating to Beta **Feature group:** sig-api-machinery This proposal introduces support for the [**CBOR**](https://en.wikipedia.org/wiki/CBOR) data format in Kubernetes API servers and clients as a high-performance alternative to JSON. While native Kubernetes resources use [**Protobuf**](https://kubernetes.io/docs/reference/using-api/api-concepts/#protobuf-encoding) 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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+sig%3Asig-cli&pane=issue&itemId=195035537&issue=kubernetes%7Cenhancements%7C5295) _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**](https://thenewstack.io/kubernetes-is-getting-a-better-yaml/). 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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-network&pane=issue&itemId=191511676&issue=kubernetes%7Cenhancements%7C4762) _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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-network&pane=issue&itemId=191511692&issue=kubernetes%7Cenhancements%7C5311) _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**](https://sithara-wanigasooriya.medium.com/understanding-rfc-1035-the-backbone-of-the-domain-name-system-d8e6df25ab10) 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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-network&pane=issue&itemId=191511709&issue=kubernetes%7Cenhancements%7C6032) _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**](https://kubernetes.io/blog/2025/02/28/nftables-kube-proxy/) 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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-network&pane=issue&itemId=197559786&issue=kubernetes%7Cenhancements%7C5343) _Make NFtables the default kube-proxy backend _**Stage:** Net New to Alpha **Feature group:** sig-network Continuing on from the [#6032](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-network&pane=issue&itemId=191511709&issue=kubernetes%7Cenhancements%7C6032) 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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-network&pane=issue&itemId=192943076&issue=kubernetes%7Cenhancements%7C5495)). ## **Kubernetes 1.37 Authentication** [#3926](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-auth&pane=issue&itemId=191511660&issue=kubernetes%7Cenhancements%7C3926) _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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-auth&pane=issue&itemId=191511666&issue=kubernetes%7Cenhancements%7C4317) _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**](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process:~:text=a%20PEM%2Dencoded-,PKCS%2310,-signing%20request%20in). [#3257](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-auth&pane=issue&itemId=191511654&issue=kubernetes%7Cenhancements%7C3257) 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. ```json { "_key": "760d78e52075", "_type": "code", "code": "apiVersion: v1\nkind: Pod\nmetadata:\n namespace: client\n name: client\nspec:\n containers:\n - name: main\n image: my-image\n volumeMounts:\n # 1. Mount the projected volume inside your container\n - mountPath: /var/run/signer-trust-anchors\n name: trust-volume\n readOnly: true\n volumes:\n # 2. Define the projected volume with the new clusterTrustBundle source\n - name: trust-volume\n projected:\n sources:\n - clusterTrustBundle:\n signerName: example.com/server-tls\n labelSelector:\n matchLabels:\n example.com/cluster-trust-bundle-version: \"live\"\n path: ca_certificates.pem", "filename": null, "language": "yaml", "markDefs": null } ``` ## **Kubernetes 1.37 Nodes** [#2837](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-node&pane=issue&itemId=198587429&issue=kubernetes%7Cenhancements%7C2837) _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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-node&pane=issue&itemId=191511694&issue=kubernetes%7Cenhancements%7C5474) _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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-node&pane=issue&itemId=192847559&issue=kubernetes%7Cenhancements%7C5328) _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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-node&pane=issue&itemId=195260967&issue=kubernetes%7Cenhancements%7C5758) _Per-container ulimits configuration _**Stage:** Net New to Alpha **Feature group:** sig-node Kubernetes 1.37 introduces a native [**ulimits**](https://www.ibm.com/docs/el/aix/7.1.0?topic=u-ulimit-command) 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**](https://kubernetes.io/docs/concepts/security/pod-security-standards/)) 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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-node+DRA%3A&pane=issue&itemId=192389377&issue=kubernetes%7Cenhancements%7C5945) _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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-node+DRA%3A&pane=issue&itemId=191511680&issue=kubernetes%7Cenhancements%7C4817) _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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-node+DRA%3A&pane=issue&itemId=192389281&issue=kubernetes%7Cenhancements%7C5304) _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**](https://docs.docker.com/build/building/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**](https://kubevirt.io/) to query the Kubernetes API. ## **Scheduling in Kubernetes 1.37** [#5836](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-scheduling&pane=issue&itemId=192389357&issue=kubernetes%7Cenhancements%7C5836) _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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-scheduling&pane=issue&itemId=192389275&issue=kubernetes%7Cenhancements%7C5055) _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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-scheduling&pane=issue&itemId=197763287&issue=kubernetes%7Cenhancements%7C6080) _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`: ```json { "_key": "d3360d6e1c0d", "_type": "code", "code": "apiVersion: resource.k8s.io/v1\nkind: ResourceClaim\nmetadata:\n name: gpu-numa-alignment-claim\nspec:\n devices:\n requests:\n - name: gpu\n exactly:\n deviceClassName: gpu.nvidia.com\n count: 8\n # [NEW]: Compute virtual grouping key from GPU driver\n derivedAttributes:\n - name: shared-numa-node\n expression: \"device.attributes['gpu.nvidia.com'].numa\"\n - name: nic\n exactly:\n deviceClassName: dranet\n count: 1\n # [NEW]: Compute virtual grouping key from dranet driver\n derivedAttributes:\n - name: shared-numa-node\n expression: \"device.attributes['dra.net'].numaNode\"\n constraints:\n # Match the derived attribute across both requests using existing matchAttribute\n - matchAttribute: shared-numa-node\n requests: [gpu, nic]", "filename": null, "language": "yaml", "markDefs": null } ``` ## **Storage in Kubernetes 1.37** [#1710](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-storage&pane=issue&itemId=191511643&issue=kubernetes%7Cenhancements%7C1710) _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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-storage&pane=issue&itemId=191511663&issue=kubernetes%7Cenhancements%7C4049) _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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-storage&pane=issue&itemId=191511704&issue=kubernetes%7Cenhancements%7C5936) _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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-autoscaling&pane=issue&itemId=191511685&issue=kubernetes%7Cenhancements%7C4951) _Configurable tolerance for Horizontal Pod Autoscalers _**Stage:** Graduating to Stable **Feature group:** sig-autoscaling The Horizontal Pod Autoscaler ([**HPA**](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/)) currently uses a fixed, cluster-wide default tolerance of 10% to prevent rapid scaling churn - called "[**flapping**](https://learn.microsoft.com/en-us/answers/questions/525145/what-is-flapping-in-app-service-autoscale)". 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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-autoscaling&pane=issue&itemId=191511646&issue=kubernetes%7Cenhancements%7C2021) _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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+sig%3Asig-instrumentation&pane=issue&itemId=193855223&issue=kubernetes%7Cenhancements%7C5808) _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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-status%3ADeferred%2C%22Removed+from+Milestone%22+-enhancement-type%3ADocs+prr-status%3AApproved+stage%3ADeprecation%2FRemoval&pane=issue&itemId=192943076&issue=kubernetes%7Cenhancements%7C5495) _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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-enhancement-type%3ADocs+prr-status%3A%22Removed+from+milestone%22&pane=issue&itemId=195260975&issue=kubernetes%7Cenhancements%7C5825) _CRI List Streaming _**Stage:** Major Change to Beta **Feature group:** sig-node **Status:** Deferred [#4680](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-enhancement-type%3ADocs+prr-status%3A%22Removed+from+milestone%22&pane=issue&itemId=192389243&issue=kubernetes%7Cenhancements%7C4680) _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](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-enhancement-type%3ADocs+prr-status%3A%22Removed+from+milestone%22&pane=issue&itemId=191511712&issue=kubernetes%7Cenhancements%7C6047) _Manifest-Based Authorisation via RBAC _**Stage:** Net New to Alpha **Feature group:** sig-auth **Status:** Removed from Milestone [#5978](https://github.com/orgs/kubernetes/projects/264/views/1?filterQuery=-is%3Adraft+-enhancement-type%3ADocs+prr-status%3A%22Removed+from+milestone%22&pane=issue&itemId=196578273&issue=kubernetes%7Cenhancements%7C5978) _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**](https://www.kubernetes.dev/resources/release/) 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. ```json { "_key": "8ec0341c4f31", "_type": "tableBlock", "caption": "Timeline of the Kubernetes 1.37 release", "firstRowIsHeader": true, "markDefs": null, "table": { "rows": [ { "_key": "1c35ea0a-b8ec-4f52-aa86-d8c6f2447069", "_type": "tableRow", "cells": [ "What is happening?", "By whom?", "And when?" ] }, { "_key": "47fc2916-3cc3-4106-9c85-a200931aabe1", "_type": "tableRow", "cells": [ "Release cycle begins", "Lead", "Monday 18th May 2026" ] }, { "_key": "fc6b0f85-74de-4d45-8197-859f605e052c", "_type": "tableRow", "cells": [ "v1.37.0-alpha.1 released", "Branch Manager", "Wednesday 10th June 2026" ] }, { "_key": "ff0cb9b5-7d78-4285-bcac-b17c7f489945", "_type": "tableRow", "cells": [ "Enhancements freeze", "Enhancements Lead", "Tuesday 16th June 2026" ] }, { "_key": "ccfc1e05-de62-45e6-a809-7f782118b550", "_type": "tableRow", "cells": [ "v1.37.0-alpha.2 released", "Branch Manager", "Wednesday 24th June 2026" ] }, { "_key": "b39f4fb4-f733-4754-8669-2f8ff7952fb8", "_type": "tableRow", "cells": [ "Code & test freeze", "Branch Manager", "Wednesday 22nd July 2026" ] }, { "_key": "4824764b-f43d-4620-b18a-7c62ce01970d", "_type": "tableRow", "cells": [ "Kubecon Japan", "CNCF Event", "Tuesday 28th July 2026" ] }, { "_key": "a797fe54-557a-44ed-87ae-fa2b816c9873", "_type": "tableRow", "cells": [ "release-1.37 branch created", "Branch Manager", "Wednesday 5th August 2026" ] }, { "_key": "c59552bc-d172-4da8-bde9-f41970a728ac", "_type": "tableRow", "cells": [ "Kubernetes v1.37.0 released", "Branch Manager", "Wednesday 26th August 2026" ] } ] } } ``` ## **Kubernetes Release Archive** - [**Kubernetes 1.37 – What you need to know**](https://cloudsmith.com/blog/kubernetes-1-37-what-you-need-to-know) - [**Kubernetes 1.36 – What you need to know**](https://cloudsmith.com/blog/kubernetes-1-36-what-you-need-to-know) - [**Kubernetes 1.35 – What you need to know**](https://cloudsmith.com/blog/kubernetes-1-35-what-you-need-to-know) - [**Kubernetes 1.34 – What you need to know**](https://cloudsmith.com/blog/kubernetes-1-34-what-you-need-to-know) - [**Kubernetes 1.33 – What you need to know**](https://cloudsmith.com/blog/kubernetes-1-33-what-you-need-to-know)