Kubernetes v1.37 moves the Pod-Level Resource Managers feature to Beta, introduces a new feature gate (PodLevelResourceManagers) that is disabled by default, and expands the v1 PodResources gRPC service with top‑level cpu_ids and memory fields. This gives operators the ability to let the Kubelet’s Topology, CPU, and Memory managers consume pod‑level .spec.resources directly, enabling a hybrid allocation strategy that separates primary containers from sidecars.
Feature Graduation and API Additions
The graduation to Beta is controlled by the PodLevelResourceManagers feature gate; clusters must explicitly enable it in the Kubelet configuration. The API change adds cpu_ids and memory at the pod level in the PodResourcesLister response, allowing monitoring tools and device plugins to query exclusive assignments without aggregating per‑container data. No new runtime flags are introduced beyond the gate, but the presence of the new fields signals that the node’s resource managers are now operating on pod‑level declarations.
Hybrid Allocation Model
Previously, exclusive NUMA‑aligned CPU cores or memory required every container in a pod to request integer resources, forcing operators to over‑provision sidecars that do not need dedicated cores. With Pod-Level Resource Managers, the Kubelet can reserve exclusive, NUMA‑local resources for the main application containers while placing auxiliary containers—such as logging agents or telemetry exporters—into a pod‑isolated shared pool. The sidecars still benefit from NUMA locality and protection from other pods, but they no longer consume whole cores, reducing waste and improving overall node utilization.
Operational Considerations
- Configuration: Enable the feature gate and verify that the Kubelet’s resource manager settings (e.g.,
cpuManagerPolicy,topologyManagerPolicy) are compatible with pod‑level declarations. - Observability: Update monitoring pipelines to read the new
cpu_idsandmemoryfields from the PodResources API. This avoids double‑counting when aggregating resource usage across containers. - Capacity Planning: Re‑evaluate node capacity models because exclusive core allocation will now be scoped to a subset of containers, potentially increasing the number of pods that can be scheduled on a node.
- Security & Isolation: The exclusive allocation improves isolation for latency‑critical workloads, while sidecars remain isolated at the pod level. Practitioners should still treat sidecar placement as a shared‑resource scenario and apply appropriate runtime security policies.
Related CloudNinjas coverage: Kubernetes.
What This Means For Practitioners
Enable the PodLevelResourceManagers gate on test clusters, adjust Kubelet policies to reflect pod‑level resource intent, and validate that your observability stack consumes the new PodResources fields. Expect reduced core waste for sidecar‑heavy workloads and clearer isolation boundaries for primary containers. Keep an eye on upcoming GA releases for default enablement and any further API refinements.
