Kubernetes v1.37: Pod-Level Resource Managers graduated to Beta

Kubernetes v1.37 marks an important milestone with Pod-Level Resource Managers moving from Alpha to Beta status. While the feature remains disabled by default, this graduation signals that the Kubernetes community considers it stable enough for wider testing and real-world evaluation. If you’re running Kubernetes clusters and struggling with resource contention between containers in the same pod, this feature deserves your attention.

Pod-Level Resource Managers addresses a fundamental challenge in Kubernetes: managing CPU and memory resources across containers that share the same pod. Previously, you could set resource requests and limits at the container level, but you had limited control over how those resources were actually allocated and managed when multiple containers competed for them. This new feature lets you define policies at the pod level that govern how the Linux kernel distributes CPU cycles and memory among containers. Under the hood, it works by leveraging Linux cgroups v2 and kernel resource control mechanisms—when enabled, Kubernetes automatically configures the cgroup hierarchy to enforce your pod-level policies before applying container-level constraints. This two-tier approach gives you finer-grained control without requiring changes to your application code.

The practical benefits become clear when you examine common real-world scenarios. Consider a pod running a primary application container alongside a sidecar for logging or monitoring. If your main application suddenly spikes in CPU usage, a pod-level resource manager can prevent it from starving out the sidecar, ensuring observability stays intact. Similarly, in data processing workloads where a pod contains both a worker process and a resource-intensive cache, you can now guarantee minimum resources for critical components. This is especially valuable in multi-tenant clusters where pods from different teams share nodes—pod-level policies add another layer of isolation and predictability.

To get started, you’ll need to enable the PodResourceManagers feature gate in your cluster (check your Kubernetes distribution’s documentation for the specific steps). Once enabled, you can define resource management policies in your pod spec, though the exact API is still evolving as the feature matures through Beta. This is a good time to test it in non-production environments and provide feedback to the community. If you’re currently patching over resource contention issues with manual pod placement or oversizing your nodes, Pod-Level Resource Managers offers a more elegant, Kubernetes-native solution worth experimenting with.