Kubernetes 1.37 moves pod-level resource managers to beta

With Kubernetes 1.37, the Pod-Level Resource Managers feature graduates to beta (disabled by default): the Topology Manager, CPU Manager, and Memory Manager now read .spec.resources declarations directly. Latency-critical workloads can reserve exclusive NUMA cores for the primary container while sidecars share an isolated pod-level pool.

August 26, 2026. Kubernetes 1.37 is released. September 15. The SIG Node team documents the graduation of Pod-Level Resource Managers to beta. The feature stays disabled by default, behind a feature gate. Why it matters: until now, getting exclusive, NUMA-aligned CPUs or memory forced a binary choice — reserve dedicated resources for every container in the pod, or give up alignment. The beta removes that block for workloads that mix a critical primary container with lightweight sidecars.

The old impossible choice: all or nothing on exclusive cores

The problem the feature solves is as easy to describe as it was expensive to work around. For a latency-critical workload — an in-memory database, a telecom control plane, a data proxy — exclusive cores and local NUMA memory are a performance requirement, not a comfort. A process whose thread migrates between cores on different sockets, or that touches remote memory, suffers latencies measured in tens of microseconds and paid out in tail percentiles.

The old model imposed a strict discipline: to benefit from the exclusive allocation of the CPU Manager and Topology Manager, you had to declare integer resource requests on all the pod’s containers, from the application container down to the logging sidecar. The result: a sidecar that only needs a fraction of a core was reserved an entire physical core, wasted. The alternative — leaving the sidecar Burstable — cost the whole pod its NUMA alignment. Between wasted capacity and degraded latency, platform teams usually picked the lesser evil and documented the exception.

What the beta changes: hybrid allocation

The Pod-Level Resource Managers feature, introduced in alpha in Kubernetes 1.36, builds on the Pod-Level Resources stabilized in 1.34 to equip the kubelet’s three resource managers — Topology Manager, CPU Manager, and Memory Manager — to read .spec.resources declarations directly at the pod level rather than the container level.

The concrete payoff is a hybrid allocation model. The kubelet can reserve exclusive NUMA-aligned cores for the application’s primary container, while placing non-Guaranteed sidecars in a pod-isolated shared pool. The primary container gets unthrottled, NUMA-local cores; the sidecars get local NUMA alignment and protection from interference by other pods, without consuming a dedicated physical core. That is the end of the binary choice: you no longer sacrifice the critical workload’s latency to spare a few cores for sidecars.

The beta graduation also brings an API change. The PodResourcesLister gRPC service (v1) now exposes top-level cpu_ids and memory fields on PodResources responses. Monitoring tools and device plugins can query pod-level exclusive assignments without double-counting container allocations — a detail that matters when an observability agent has to report the real topology of allocations.

How to enable it

The feature is disabled by default in 1.37: it must be turned on explicitly through the PodLevelResourceManagers feature gate on the relevant cluster components. That is the expected behaviour for a beta — the entry point is deliberately manual, so teams can validate behaviour on a narrow scope before rolling it out.

bash

# Example: enabling the feature gate on the kubelet (kubeadm)
# Add to the kubelet configuration file, then restart the service.
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
  PodLevelResourceManagers: true

Once the gate is on, the kubelet reads the pod’s .spec.resources declarations and hands them to the managers. The official documentation ships a full configuration tutorial — from declaring pod-level resources to verifying the allocation — plus a dedicated task on assigning pod-level CPU and memory resources. Feedback is being collected on the #sig-node Slack channel and the group’s mailing list, a sign that the path to GA still depends on field reports.

Verdict

Pod-Level Resource Managers in beta is one of those quiet changes that fix a structural unfairness: you should never have to choose between a critical workload’s latency and the waste of physical cores on sidecars. If you run latency-critical workloads with sidecars — databases, control planes, data nodes — enable the gate on a test cluster and measure the effect on your percentiles before rolling it out; the gain shows up in the latency tail, not the average. If you maintain monitoring agents or device plugins, prepare to read the new cpu_ids and memory fields on the PodResourcesLister service: that is the data that will finally tell you who owns which core, without double counting. If you are behind on versions, remember this beta rests on building blocks stabilized in 1.34 — the upgrade path is a prerequisite, not an option.

Kubernetes 1.37 moves pod-level resource managers to beta

The old impossible choice: all or nothing on exclusive cores

What the beta changes: hybrid allocation

How to enable it

Verdict

References

The cyber brief, every Tuesday

On the same topic

Cilium 1.20 widens the Gateway API, enables ENI IPv6 on AWS, and opens the datapath to plugins

Native histograms go beta and cut Prometheus time series by up to 90%