2026年9月15日，Kubernetes官方博客发布Kubernetes v1.37的Pod-Level Resource Managers特性说明，该特性由v1.36的Alpha升级为Beta。它让Kubelet的Topology Manager、CPU Manager与Memory Manager能够直接依据Pod级的资源声明（.spec.resources）进行CPU/NUMA等硬件放置决策，为云原生负载提供更精细的算力与硬件亲和调度。本文从云原生基础设施视角解读。
从容器级到Pod级的资源模型
在以往模型中，Kubelet的资源管理器主要围绕单个容器（container）做资源分配，难以在Pod整体维度统一布局。Pod-Level Resource Managers把决策粒度提升到Pod：调度器与Kubelet可按Pod声明的资源需求，一次性为整个工作负载规划CPU与内存拓扑，使多容器之间更容易共享一致的硬件亲和性。
混合分配：主容器独占与sidecar共享池
该特性支持混合分配模型：可以为主应用容器保留独占的NUMA对齐资源，同时把非Guaranteed的sidecar放入Pod的隔离共享池。这种设计对既有性能敏感又有辅助容器的场景尤其友好——既保证了主服务的确定性，又避免了sidecar抢占关键资源。
PodResources API增强可观测性
配合该特性，PodResources v1 gRPC服务新增cpu_ids与memory字段，监控与设备插件可直接查询Pod级别的独占分配，无需自行累加容器分配。这降低了运维侧重复计算的成本，也让资源可见性更贴近真实调度结果，为弹性伸缩与容量规划提供依据。
对云原生基础设施团队的启示
对运维Kubernetes集群、特别是承载延迟敏感或性能敏感负载的团队，该特性值得在下一个周期规划验证：先在启用PodLevelResourceManagers feature gate的非生产集群上测试混合分配，评估对CPU/memory亲和性与服务SLO的影响，再考虑生产落地，以充分发挥硬件与算力的确定性收益。
小结
Kubernetes 1.37将Pod-Level Resource Managers推进到Beta，以Pod级硬件放置与PodResources能力增强为核心看点，是2026年9月云原生基础设施领域值得关注的调度与算力治理更新。