Kubernetes 1.37: What Lands in the Next Release (and Why It Matters)

Kubernetes 1.37.0-rc.0 shipped on August 6, 2026, with the release branch open and the final GA expected within the next 2-3 weeks based on the recent cadence. The past three releases averaged 16-17 days from rc.0 to GA (1.34: 21d, 1.35: 14d, 1.36: 14d), so the standard pattern puts 1.37 GA around late August. We don't write release notes posts unless there's something platform teams genuinely need to plan around, and 1.37 has three of those: Dynamic Resource Allocation graduating to GA, Pod Certificates graduating to GA, and a stack of in-place pod vertical scaling features hitting stable. The rest of the release is mostly alpha work and bug fixes - useful to know about, but not urgent.

This is the practical view: what landed, what's safe to depend on, and what to watch for the next two releases.

What's graduating to GA in 1.37

Dynamic Resource Allocation (DRA) reaches GA-quality surface area

DRA has been the upstream answer to GPU and accelerator sharing for two releases now, and 1.37 is the release where most of the core API surface hits GA. The specific graduations in this release:

• `DRAResourceClaimDeviceStatus` is now GA. This is the per-pod status reporting that lets you see what a pod actually got allocated. GA here means it's safe to build dashboards against.
• DRA Workload resource claims graduated to Beta. Still off by default (feature gate DRAWorkloadResourceClaims), but the beta graduation is the milestone. Workload-level claims are the model that lets a workload declare shared resource needs rather than each pod declaring them individually. We expect this to be GA in 1.38 or 1.39.
• DRA metadata API graduated to Beta. Drivers now have a stable pattern for publishing device metadata (model, vendor, capabilities) into the cluster in a structured way. Drivers still need to explicitly select which versions to support.
• `DRAResourceHealth` v1 API promoted. The kubelet-side gRPC API for health monitoring hit v1 (schema unchanged from v1alpha1). One-time Go API break for drivers; v1alpha1 deprecated and slated for removal in 1.40.

For our clients running HAMi today, the relevant takeaway: DRA is no longer "experimental upstream answer." The core API surface is GA-quality. The thing that's still alpha is the NVIDIA driver itself and the observability story around it. We expect DRA to be a viable production target for new deployments in mid-2027 once the driver and ecosystem catch up.

Pod Certificates reach GA

The PodCertificateRequest feature gate is now true by default, which is the formal GA promotion for Pod Certificates. The v1beta1 fields PKIXPublicKey and ProofOfPossession were removed from the v1 API. This matters for any team building workload-identity or SPIFFE-style attestation on Kubernetes - you now have a stable API for pods to request short-lived certificates directly through the API server rather than going through an out-of-band CSI driver or admission webhook.

If you're building AI agent infrastructure on Kubernetes and you're using workload identity to bind tokens to specific pods, this is the upgrade you've been waiting for. The old pattern (custom cert-issuing sidecars, per-namespace cert-manager shims) is now replaceable with a built-in primitive.

InPlacePodVerticalScaling finishes graduating

Two graduations here:

• `InPlacePodVerticalScalingInitContainers` is GA.
• `InPlacePodVerticalScalingMemoryBackedVolumes` graduated to alpha (behind a feature gate, off by default).

The init-containers graduation closes the last gap that prevented most teams from depending on in-place pod vertical scaling in production. The memory-backed volumes work is the alpha hint at the next frontier: actually resizing volumes in place without pod restart.

If you've been avoiding in-place vertical scaling because of the init-container edge case (where resizing an init container required a pod restart and broke the workload's state), that's gone. You can now resize CPU and memory on running pods without restart, including for pods with init containers, as long as the volume resize is a future feature.

What's at beta - watch list

DRA SchedulerPreQueueingHints (beta, on by default)

A new beta feature gate that's enabled by default: scheduler plugins can provide a PreQueueingHintFn that narrows the set of pods evaluated on cluster events. The DRA plugin implements this to optimize ResourceClaimTemplate-based workloads. In plain English: scheduling throughput for DRA workloads got better, automatically, because the scheduler is no longer re-evaluating every pod on every cluster event.

This is the kind of change you'll feel in p99 scheduling latency on large clusters running DRA workloads. Worth running benchmarks before and after the upgrade.

DRA resource availability visibility (alpha, behind DRAResourcePoolStatus)

The ResourcePoolStatusRequest controller now counts partitionable and consumable devices correctly (each device counted once, AdminAccess ignored, taints treated as unavailable). The accounting fixes change the numbers reported by 1.36 - so if you have any tooling reading these numbers, expect them to shift on upgrade.

DRA device compatibility groups (alpha, behind DRADeviceCompatibilityGroups)

DRA drivers can now declare opaque compatibilityGroups on each device.consumesCounters[] entry of a ResourceSlice. The scheduler only co-allocates devices drawing from the same counter set when their declared groups intersect (per PR #139795). This is the mechanism that lets you express "this NIC and this GPU need to come from the same physical machine" or "these two H100s need to be in the same NVLink domain."

This is a meaningful feature for AI infrastructure teams running multi-host inference or distributed training, where the topology constraint is the whole point.

DRA derived attributes (alpha)

Claims can define virtual attributes using CEL expressions and use them in device constraints. The example in the KEP: co-allocation of GPUs and NICs on the same NUMA node, even if their drivers publish physical attributes differently. We see this as the building block for sophisticated topology-aware scheduling that platform teams will build on top.

DRA optional node operations (alpha, behind DRAOptionalNodeOperations)

A SkipNodeOperations field in ResourceSlice and ResourceClaim lets drivers skip node-level preparation and cleanup. The use case is performance: skip the CDI injection step when the claim doesn't actually need it.

Volume health reporting APIs

The implementation of APIs required for reporting volume health landed. This is the precursor to VolumeHealth becoming a thing kubelet and CSI drivers can publish. Not user-visible yet, but it's the foundation.

Pod-level resources (alpha, new metric)

A new alpha kubelet metric, pod_level_resources_admission_total, tracks feature adoption for KEP-2837 (Pod-Level Resources) by resource configuration mode and QoS class. The metric is the leading indicator for whether pod-level resources will graduate in 1.38 or 1.39.

What's at alpha - in flight

DRA node allocatable resources (alpha)

Updates to DRANodeAllocatableResources that include direct allocations (DRA drivers modeling CPU/memory/hugepages as a resource), overhead allocations, in-place resizing of standard resource requests and limits for pods with DRA claims, and scheduler enforcement of claim sharing rules. This is the work that will eventually let DRA replace device plugins entirely for GPU workloads. Still alpha, but the scope is becoming clearer.

Bind mount options per container volume mount (alpha)

Users can specify noexec, nodev, nosuid per container volume mount. This closes a security gap that's been on the platform security wishlist for years.

EmptyDir volume directory mode bits (alpha)

Users can set Unix permission bits (0000-01777) through the mode field on emptyDir volume directories at creation time. Small but useful for multi-tenant clusters where the default 0777 isn't acceptable.

KubeletInUserNamespace graduated to Beta

KEP-2033 - allows running kubelet inside a user namespace. Relevant for rootless container scenarios and for Kubernetes-in-Kubernetes use cases (CI runners, edge deployments).

TLS for gRPC container probes (alpha, behind feature gate, KEP-4939)

Kubelet now supports TLS when using gRPC container probes. Previously gRPC probes were plaintext. This matters if your probes carry sensitive data (which they shouldn't, but often do in practice) or run over untrusted networks (edge, multi-tenant bare metal).

Atomic write volume file owner (alpha, behind AtomicWriteVolumeUserFields)

Alpha support for users to define the desired file owner of atomically written volume files. Useful for compliance scenarios where you need to prove that secret files were written by a specific user.

PLEGOnDemandRelist graduated to GA

Pod lifecycle event generator on-demand relisting is now GA. If you've ever tuned kubelet for large clusters, you know what this is. GA means it's safe to enable unconditionally.

PodReadyToStartContainers condition promoted to GA

Another GA graduation for a feature that's been beta for multiple releases. Safe to depend on for readiness checks.

What you should actually do

If you're on 1.36 today:

• You don't need to do anything for 1.37 right now. It's prerelease. Wait for 1.37.1 (typically 4-6 weeks after GA) before considering production upgrades.
• Start testing 1.37 in non-production if you have GPU workloads - DRA graduation is the largest surface area change in this release.
• Audit your Pod Certificate usage. If you've been using v1beta1 fields, your API calls will need updating.
• Watch the InPlacePodVerticalScaling memory-backed volumes feature gate. It's alpha, but the graduation pattern is clear - GA in 1.38 or 1.39. If your workload depends on in-place volume resize, this is the release to start designing around.

If you're on 1.35 or earlier:

• Skip 1.36 entirely. 1.37 will be out before 1.36 has aged into your normal upgrade window. Plan for a 1.35 -> 1.37 jump with 1.36 skipped.
• Plan your upgrade window now. 1.37 will be the release where the core DRA API surface is GA, so any team holding off on DRA adoption should be planning their migration timeline against the 1.37 or 1.38 release.

If you're evaluating Kubernetes for new AI workloads:

• DRA is no longer "experimental." The API surface is GA-quality. The driver maturity question is real - NVIDIA's DRA driver (kubernetes-sigs/dra-driver-nvidia-gpu) has ComputeDomains (MNNVL) officially supported, while GPU allocation is not yet officially supported and the GPU kubelet plugin is disabled by default in the upstream Helm chart - but the upstream API story is solid. For teams planning Kubernetes GPU workloads, this is the moment to start the DRA evaluation.
• Pod Certificates GA is meaningful if you need workload identity for AI agents or multi-tenant inference. It's the missing primitive that makes the pattern safe.

What we expect in 1.38

Based on what's at beta and what KEPs are tracking toward the 1.38 release branch:

• DRA Workload resource claims to GA. The feature has been beta for one release; the typical graduation cadence puts GA in 1.38.
• DRA metadata API to GA. Beta in 1.37, GA in 1.38 is the standard path.
• More DRA driver ecosystem maturity. Not a Kubernetes release item per se, but worth tracking.

We don't have insider visibility into KEP approvals, so treat that as informed speculation, not commitment.

Sources and further reading

• Kubernetes 1.37.0-rc.0 release notes: CHANGELOG-1.37.md (upstream)
• KEP-1287: Dynamic Resource Allocation
• KEP-5677: DRA Resource Availability Visibility
• KEP-2033: KubeletInUserNamespace
• KEP-4939: TLS for gRPC container probes
• KEP-2837: Pod-Level Resources
• Kubernetes Pod Certificates GA documentation
• NVIDIA DRA driver: kubernetes-sigs/dra-driver-nvidia-gpu

If you're planning a Kubernetes 1.37 upgrade or evaluating DRA for production AI workloads, book an Assessment Workshop. We'll walk through your current version, your GPU footprint, and your workload topology constraints - and tell you whether 1.37 is the right upgrade target, what to test in your staging environment, and what the realistic DRA production timeline looks like for your stack. Need help planning the migration? Our Kubernetes consulting team and AI infrastructure practice can scope the work end to end.