Kubernetes 1.37 Release: New Features, Beta & Stable Changes

Kubernetes v1.37 is scheduled for release on Wednesday, August 26, 2026. In this release, some features become stable, some move to beta, and some new ones land in alpha.

In this Kubernetes v1.37 sneak peek, we cover the biggest stable features, what's moving to beta, new alpha experiments, and what's being deprecated or removed. This is a pre-release preview, so some details may change before the final release.

Kubernetes 1.37: Stable (GA) Features

1. Metrics API Graduates

Feature Group: SIG Instrumentation | KEP: KEP-5207

The metrics.k8s.io API has been in beta for years. It's the API behind kubectl top and the Horizontal Pod Autoscaler's CPU and memory metrics. In v1.37, it finally graduates to stable.

There's no functional change here. Both v1 and v1beta1 continue to work, so you don't need to change anything right now. But if you're building tools that use this API, you can now use v1 with confidence because it's stable and won't change unexpectedly. 

2. Pod-Level Resources

Before this, you had to set resource requests and limits for each container in a pod, even if the containers were meant to work together. 

Pod-level resources let you set CPU, memory, and hugepages requests/limits at the pod level instead of (or alongside) the container level.

spec:
  resources:
    requests:
      cpu: "1"
      memory: "512Mi"
    limits:
      cpu: "2"
      memory: "1Gi"
  containers:
  - name: app
    image: my-app
  - name: sidecar
    image: my-sidecar

‍

All containers in the pod can then share the same resource pool instead of each having its own fixed allocation. This reduces wasted resources and works better for multi-container workloads with bursty resource usage.

3. DRA: Device Taints and Tolerations

Feature Group: SIG Scheduling | KEP: KEP-5055 

This brings the node taint model to Dynamic Resource Allocation (DRA). DRA drivers or a DeviceTaintRule you write yourself can taint a specific device (say, a GPU that's overheating or being drained for maintenance).

A NoSchedule taint prevents new pods from using that device, while a NoExecute taint removes pods that are already using it. If a workload still needs to use the device, it can add a matching toleration to its ResourceClaim.  

This lets you isolate a single GPU or NIC instead of cordoning the entire node.

4. HPA Configurable Tolerance

Feature Group: SIG Autoscaling | KEP: KEP-4951

The Horizontal Pod Autoscaler (HPA) has always used a fixed 10% tolerance across the entire cluster to avoid scaling because of small changes in metrics. But the same 10% doesn't make sense for every workload. A 10% change for a workload with 500 pods is very different from one with 5 pods.

With this feature now stable, you can set a custom tolerance for each HPA, with separate values for scale-up and scale-down under spec.behavior.scaleUp and spec.behavior.scaleDown. This lets each workload scale more appropriately without changing the cluster-wide default.

5. Pod Certificates

Feature Group: SIG Auth | KEP: KEP-4317 

This gives pods a native way to get short-lived X.509 certificates without going through bearer tokens. A new PodCertificateRequest API handles the issuance, and a PodCertificate projected volume lets the kubelet hand the key and cert straight to the pod, with automatic rotation.

This makes mTLS setups (including third-party tools like HashiCorp Vault) easier to wire up natively, without the extra sidecar or webhook plumbing a lot of service meshes use today.

6. KYAML Output for kubectl

Feature Group: SIG CLI | KEP: KEP-5295 

KYAML is a stricter, Kubernetes-flavored subset of YAML: curly braces for maps, square brackets for lists, double quotes for strings. It still allows comments and trailing commas, but removes the classic YAML footguns, like no silently parsing as boolean false (the "Norway problem").

It's now a stable output option for kubectl, so you can generate manifests in this format without worrying about accidental type coercion breaking your config.

7. Speed Up Recursive SELinux Label Change (SELinuxMount)

Feature Group: SIG Storage | KEP: KEP-1710

On SELinux-enabled nodes, Kubernetes used to relabel every file on a volume one by one before a pod could start. On a volume with millions of files, that alone could take minutes.

SELinuxMount graduates to GA and is enabled by default in v1.37. Instead of relabeling file by file, volumes get mounted with -o context=<label>; the whole volume gets the right label in one mount operation. This only kicks in when the volume's CSI driver opts in through CSIDriver.spec.seLinuxMount: true.

An important thing to remember: a single mount can only carry one SELinux context. If you currently have pods with different SELinux labels sharing the same volume on the same node (which worked fine under the old recursive relabeling), those pods may now fail to start. If you need that old behavior for a specific workload, set seLinuxChangePolicy: Recursive on the pod spec. Clusters without SELinux enabled see no change at all.

Kubernetes 1.37 Beta Features

8. Kubelet in User Namespace (Rootless Mode)

Feature Group: SIG Node | KEP: KEP-2033

Node components like the kubelet normally run as root on the host. If the kubelet is compromised, an attacker could gain root access to the node.

Kubelet in UserNS runs the kubelet inside a Linux user namespace instead. It still appears to run as root inside the namespace, but on the actual host it's mapped to an unprivileged user. This feature moves to beta in Kubernetes v1.37 and adds an extra layer of isolation without changing how you use the kubelet day to day.

9. HPA Scale To/From Zero for Object and External Metrics

Feature Group: SIG Autoscaling | KEP: KEP-2021 

The Horizontal Pod Autoscaler (HPA) has been able to scale to zero replicas using object or external metrics for some time. But there was no easy way to know whether the HPA scaled a workload to zero or if someone set it to zero some other way.

Kubernetes v1.37 adds a ScaledToZero status condition to the HPA object, making that difference clear. This is especially useful for event-driven workloads, such as those using queue depth or KEDA-style triggers, that scale down to zero when idle and scale back up when new work arrives.

10. CBOR Serializer

Feature Group: SIG API Machinery | KEP: KEP-4222 

Built-in Kubernetes resources use Protobuf to keep API calls fast, but CRDs can't easily use Protobuf since it needs compile-time code generation. CBOR is a binary format that doesn't have that requirement, and early benchmarks show up to 8x faster encoding and 2x faster decoding for custom resources compared to JSON. Clients negotiate it automatically and fall back to JSON against older API servers, so this rolls out safely.

Kubernetes 1.37 Alpha Features

These are alpha: not production-ready, but worth trying in a staging cluster.

11. Volume Health Monitor

Feature Group: SIG Storage | KEP: KEP-1432

Right now, if a CSI volume has a storage-level problem, you usually only find out through a failed mount or an I/O hang; there's no structured signal to act on. This introduces four new CSI RPCs so drivers can report volume health in a way controllers can act on. On the controller side, ControllerListVolumeHealth lists unhealthy volumes and ControllerGetVolumeHealth checks a specific one; a controller-side health monitor polls these and writes the result into PersistentVolumeClaim.status.healthStatus. On the node side, the kubelet calls NodeGetVolumeHealth for individual volumes (recorded in Pod.status.volumeHealth) and NodeGetStorageHealth for the health of the drivers on that node. This gives remediation controllers something machine-readable to act on instead of cross-referencing vendor dashboards by hand. 

12. Per-Container ulimits

Feature Group: SIG Node | KEP: KEP-5758 

Some applications, such as databases and high-concurrency applications, need higher POSIX limits, like the maximum number of open files or processes, than the container runtime provides by default. Until now, the usual options were custom entrypoint scripts or changing the host configuration.

Kubernetes v1.37 adds a ulimits field to Container.SecurityContext. The kubelet passes these limits to the container runtime. This feature currently works only with the Privileged Pod Security Standards profile, and Kubernetes checks node support before scheduling the pod, so it doesn't run on a node that can't apply the required limits.

13. DRA: Derived Attributes

Feature Group: SIG Scheduling | KEP: KEP-6080

DRA can already match devices on shared attributes, but only if different hardware vendors use the same attribute name, which they usually don't. Say you want a GPU and a fast NIC on the same NUMA node: the scheduler needs matching attribute names and values, but each vendor describes topology in its own way.

Derived attributes let you write a CEL expression in your device request that builds a virtual attribute from whatever the driver already exposes. That gives you one common key, like a NUMA node ID, that the scheduler can match on. So you can pair GPUs and NICs on the same NUMA node without waiting for every vendor to agree on one naming scheme.

This is alpha and the API is still taking shape, so try it in a staging cluster and check the KEP for the exact fields before using it.

Deprecations and Removals in Kubernetes 1.37

a. kubectl run --filename (-f)

The -f option for kubectl run is being deprecated. Pods created with kubectl run are always built from command-line arguments such as NAME and --image anyway. Stop passing -f to kubectl run and use kubectl apply -f for file-based Pod creation.

b. Static Pods referencing Secrets/ConfigMaps

A bug that allowed Static Pods to use secretRef and configMapRef has been fixed. The PreventStaticPodAPIReferences feature gate that allowed you to opt out has also been removed. Static Pods can no longer read Secrets or ConfigMaps, so move that configuration into the Static Pod manifest itself.

c. ipvs mode in kube-proxy

The deprecation of ipvs mode continues, with removal planned for Kubernetes v1.43. By v1.40, ipvs mode is expected to be disabled by default. Check which mode your cluster uses and start planning a migration to nftables.

d. cgroup v1

failCgroupV1 has defaulted to true since Kubernetes v1.35, so the kubelet won't start on cgroup v1 nodes unless you use an override. Migrate your nodes to cgroup v2. The override is only a short-term fix, and features such as In-Place Pod Resize require cgroup v2 anyway.

To check which kube-proxy mode you're running:

kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'

‍

Solving Kubernetes resource management with PerfectScale by DoiT

New Kubernetes releases add more configuration options: pod-level resources, per-container ulimits, and DRA device taints, but more knobs also mean more ways to get sizing wrong. PerfectScale by DoiT is a Kubernetes governance platform that continuously watches your workloads for resource-driven risk (OOMKilled pods, CPU throttling, evictions) and turns that into right-sizing recommendations you can apply manually or on autopilot, so your clusters stay healthy as you adopt every new release.

Real teams like Paramount Pictures and Creditas already run PerfectScale to keep their Kubernetes costs and reliability in check.

Sign up or book a demo to see it on your own cluster.

FAQ: Kubernetes v1.37

When is Kubernetes v1.37 releasing?

Kubernetes v1.37 is scheduled for release on Wednesday, August 26, 2026.

How many enhancements are in Kubernetes 1.37?

The full list is in the official Kubernetes enhancements tracker on GitHub, and the exact number keeps changing right up to release day. So instead of a count, this post covers the biggest stable, beta, and alpha changes.

What is being removed or deprecated in Kubernetes v1.37?

kubectl run --filename is being deprecated, static pods can no longer reference Secrets or ConfigMaps, ipvs mode in kube-proxy continues its multi-release deprecation, and cgroup v1 support keeps moving toward removal.

Is Kubernetes v1.37 safe to upgrade to?

Stable (GA) features are production-ready. Alpha and beta features should stay in staging until they graduate further. Before upgrading, check whether you're relying on kubectl run -f, static pods with Secret/ConfigMap references, or ipvs mode, and fix those first.

What is the release name for Kubernetes v1.37?

Not announced yet as of this writing. It's revealed on release day.