Kubernetes 1.37 shipped on August 26, and it's a good time to check in on a couple of features that kept coming up in roadmap conversations: in-place pod resizing and Dynamic Resource Allocation (DRA). Both of these features have been building for several releases now, and 1.37 adds another layer to each. There's also a third one we think is worth watching: gang scheduling through the PodGroup API. It's been alpha since 1.35, and the beta graduation originally planned for 1.36 is now planned for the 1.37 release candidate.
In-place pod resizing lets you potentially change a pod's CPU and memory without restarting it. Before this existed, adjusting resource requests or limits meant recreating the pod, which is disruptive for stateful workloads or long-running batch jobs.
The container-scoped version of this reached general availability in Kubernetes 1.35, released in December 2025. Kubernetes 1.36 built on that by extending resizing from individual containers to the pod as a whole. In-Place Pod-Level Resources Vertical Scaling graduated to beta, giving pods with tightly coupled containers a shared resource pool that can flex together instead of resizing container by container. 1.36 also introduced Pod-Level Resource Managers as an alpha feature, extending the kubelet's topology, CPU, and memory managers to work at the pod level rather than strictly per container.
Kubernetes 1.37 extends that coverage. Init containers are now covered by in-place vertical scaling, with InPlacePodVerticalScalingInitContainers reaching GA. Pod-Level Resource Managers, the kubelet-side managers that let CPU, memory, and topology allocation work at the pod level, move to beta. (Note that restart-free resizing requires cgroup v2. With 1.37 tightening cgroup v1 deprecation defaults (failCgroupV1: true), your underlying node pools must be running cgroup v2 before workloads can take advantage of in-place scaling.)
The core Pod-Level Resources feature itself, the one that lets you set CPU, memory, and huge pages as a shared budget at the pod level, stays in beta for this release. 1.37 also adds a kubelet metric to track adoption by resource configuration and QoS class, which points to a stable release for it in 1.38 or 1.39.
Two new alpha features extend this capabilities set. Scheduler Preemption for In-Place Pod Resize lets the scheduler preempt or evict lower-priority pods to make room for a resize that's stuck waiting on node capacity. A separate feature gate adds support for resizing memory-backed volumes in place, extending the same restart-free pattern to volumes. For platform teams, this addresses the primary operational friction around Vertical Pod Autoscaling (VPA). Instead of VPA triggering disruptive pod restarts during peak traffic, rightsizing becomes a continuous, zero-downtime background optimization.
Key Takeaway: Reduces node churn and eliminates application downtime previously required for VPA-driven rightsizing.
DRA is the flexible alternative to device plugins for requesting GPUs and other specialized hardware. Instead of a static, cluster-wide device count, DRA allows workloads to specify their exact resource requirements and enables the scheduler to match them to available devices.
The core of DRA graduated to GA in Kubernetes 1.34, released in August 2025, with the stable resource.k8s.io/v1 API enabled by default. In Kubernetes 1.36, DRA admin access and prioritized device selection reached stable, while Partitionable Devices, Consumable Capacity, Device Taints and Tolerations, and Resource Health Status all reached beta with their feature gates enabled by default.
Kubernetes 1.37 continues to stabilize the operational side of DRA. Device taints and tolerations graduate to GA, mirroring the existing node-taint model so drivers or admins can mark degraded or offline hardware. This blocks new pods from scheduling onto affected devices and evicts existing pods for maintenance. Resource Claim Status also reaches GA, giving drivers a stable place to report status data back on the claim itself.
Two additional alpha features also land in Kubernetes 1.37. A standardized numaNode device attribute gives drivers a common way to report which NUMA node a device sits on. Derived attributes also allow a claim to define virtual attributes with CEL expressions and use them in device constraints, letting devices like GPUs and NICs co-allocate on the same NUMA node even if their drivers publish physical attributes differently.
Core DRA has been stable for a year now. With 1.37 stabilizing more of the failure-handling and attribute-matching pieces around it, it's reasonable to expect adoption to move past early testing, particularly on GPU-heavy AI and ML clusters where sharing accelerators cleanly really matters. From a governance perspective, device taints allow platform engineers to drain or isolate individual degraded GPUs without cordoning off an entire multi-GPU node, maximizing available cluster capacity. While DRA solves how pods request physical accelerators, Gang Scheduling solves how those accelerators are protected from sitting idle during partial batch deployments.
Key Takeaway: Enables safer multi-tenant GPU sharing and granular hardware fault isolation.
Gang scheduling addresses a specific problem: Kubernetes has always scheduled pods independently, which works fine for most workloads but breaks down for distributed training jobs that need every participant to start at once. If only some pods are scheduled, the job stalls or fails, and the partial allocation still occupies resources on the nodes that did get a pod.
Kubernetes 1.35 introduced the alpha Workload API to address this, along with a basic gang-scheduling plugin that holds pods until the minimum required count for the group can be scheduled together. Kubernetes 1.36 split that into two separate APIs: Workload as a static scheduling policy template, and a new PodGroup API as the runtime object that pods actually reference. 1.36 also added topology-aware scheduling and workload-aware preemption, both alpha, plus early integration between the Job controller and the new API.
The Kubernetes v1.37 release candidate confirms the API split is now complete. Workload and PodGroup are promoted to scheduling.k8s.io/v1beta1, and the separate GangScheduling and WorkloadAwarePreemption feature gates are gone, replaced by a single GenericWorkload gate that turns on the whole feature set.
The scheduler changes to match. Its scheduling queues now hold either individual pods or whole PodGroups, and a new PlacementFeasible extension point lets the gang-scheduling plugin stop evaluating a group early once its minimum required count can't be met.
1.37 also adds a new alpha API worth watching: CompositePodGroup, at scheduling.k8s.io/v1alpha3, built for hierarchical scheduling where a group is itself made up of smaller groups.
Upgrade Warning: v1alpha2 PodGroup resources are unsupported in 1.37. If you tested gang scheduling on 1.36, you must delete any legacy v1alpha2 manifests prior to upgrading to prevent API server validation errors.
None of this is production-ready yet, and teams testing it on 1.36 clusters will need to account for the API rework before upgrading. Still, the progression from a single combined API to a dedicated PodGroup object, and now to a beta API with real scheduler support for batch placement, is a meaningful step for anyone running distributed training or other tightly coupled batch workloads on Kubernetes.
Key Takeaway: Prevents resource lockup and partial job deadlocks during large distributed training runs.
Pod rightsizing and DRA weren't delivered fully formed in a single release, and 1.37 isn't the finish line for either one. Pod-Level Resource Managers reaching beta and init containers joining in-place scaling make automatic rightsizing more trustworthy across a wider set of workloads, even with the underlying Pod-Level Resources feature itself still a release or two from stable. DRA's continued stabilization makes GPU sharing safer to run at scale instead of just in a lab cluster. And PodGroup reaching beta is a sign that gang scheduling, one of the more persistent gaps for AI and batch workloads on Kubernetes, is closer to being a first-class capability.
Keeping up with upstream Kubernetes changes, from cgroup requirements to new API deprecations, takes continuous engineering effort. WithFairwinds Managed Kubernetes-as-a-Service, our expert SRE team handles cluster upgrades, configuration updates, and operational toil so your developers can focus on building applications rather than managing infrastructure. Schedule a call to learn more.
