协会地址：上海市长宁区古北路620号图书馆楼309-313室
Kubernetes v1.36：Pod级别资源管理器，Alpha
原文链接:https://kubernetes.io/blog/2026/05/01/kubernetes-v1-36-feature-pod-level-resource-managers-alpha/
Kubernetes v1.36 引入了 Pod-Level Resource Managers（Pod 级资源管理器） 作为 alpha 特性，为性能敏感型工作负载带来了更灵活、更强大的资源管理模型。该增强扩展了 kubelet 的拓扑管理器、CPU 管理器和内存管理器，使其支持 Pod 级资源规格（.spec.resources），从严格的按容器分配模型演变为以 Pod 为中心的模型。
为什么需要 Pod 级资源管理器？
在运行机器学习训练、高频交易应用或低延迟数据库等性能关键型工作负载时，你通常需要为主应用容器提供独占的、NUMA 对齐的资源，以确保可预测的性能。
然而，现代 Kubernetes Pod 很少只包含一个容器。它们通常包含用于日志记录、监控、服务网格或数据采集的 sidecar 容器。
在此特性之前，这会造成一种权衡：为了让主应用获得 NUMA 对齐的独占资源，你必须为 Pod 中的 每个 容器分配独占的、基于整数的 CPU 资源。这对于轻量级 sidecar 来说可能是浪费。如果你不这样做，就会完全丧失 Pod 的 Guaranteed QoS 类，从而失去性能优势。
引入 Pod 级资源管理器
为资源管理器启用 Pod 级资源支持（通过 PodLevelResourceManagers 和 PodLevelResources 特性门控），允许 kubelet 创建 混合资源分配模型。这为高性能工作负载带来了灵活性和效率，同时不牺牲 NUMA 对齐。
实际用例
以下是一些实际场景，展示了如何根据配置的拓扑管理器作用域应用此特性：
1\. 紧耦合数据库（拓扑管理器的 Pod 作用域）
考虑一个延迟敏感的数据库 Pod，其中包含一个主数据库容器、一个本地指标导出器和一个备份代理 sidecar。
当配置为 pod 拓扑管理器作用域时，kubelet 会根据整个 Pod 的预算执行一次 NUMA 对齐。数据库容器从该 NUMA 节点获得其独占的 CPU 和内存切片。Pod 预算中的剩余资源构成一个新的 Pod 共享池。指标导出器和备份代理在此 Pod 共享池中运行。它们彼此共享资源，但与数据库的独占切片以及节点的其余部分严格隔离。
这允许你将辅助容器安全地放置在与主工作负载相同的 NUMA 节点上，而无需为它们浪费专用核心。
apiVersion: v1
kind: Pod
metadata:
name: tightly-coupled-database
spec:
# Pod-level resources establish the overall budget and NUMA alignment size.
resources:
requests:
cpu: "8"
memory: "16Gi"
limits:
cpu: "8"
memory: "16Gi"
initContainers:
- name: metrics-exporter
image: metrics-exporter:v1
restartPolicy: Always
- name: backup-agent
image: backup-agent:v1
restartPolicy: Always
containers:
- name: database
image: database:v1
# This Guaranteed container gets an exclusive 6 CPU slice from the pod's budget.
# The remaining 2 CPUs and 4Gi memory form the pod shared pool for the sidecars.
resources:
requests:
cpu: "6"
memory: "12Gi"
limits:
cpu: "6"
memory: "12Gi"
2\. 带有基础设施边车（Sidecar）的 ML 工作负载（拓扑管理器（Topology Manager）的容器作用域）
想象一个 Pod 中同时运行着 GPU 加速的 ML 训练工作负载和一个通用的服务网格边车（Service Mesh Sidecar）。
在拓扑管理器（Topology Manager）的 container 作用域下，kubelet 会单独评估每个容器。你可以为 ML 容器分配独占的、NUMA 对齐的 CPU 和内存，以获得最佳性能。与此同时，服务网格边车（Service Mesh Sidecar）无需 NUMA 对齐，它可以在整个节点的通用共享池中运行。整体资源消耗仍然安全地受限于 Pod 的总限制，但你只将 NUMA 对齐的独占资源分配给那些实际需要它们的特定容器。
apiVersion: v1
kind: Pod
metadata:
name: ml-workload
spec:
# Pod-level resources establish the overall budget constraint.
resources:
requests:
cpu: "4"
memory: "8Gi"
limits:
cpu: "4"
memory: "8Gi"
initContainers:
- name: service-mesh-sidecar
image: service-mesh:v1
restartPolicy: Always
containers:
- name: ml-training
image: ml-training:v1
# Under the 'container' scope, this Guaranteed container receives exclusive,
# NUMA-aligned resources, while the sidecar runs in the node's shared pool.
resources:
requests:
cpu: "3"
memory: "6Gi"
limits:
cpu: "3"
memory: "6Gi"
CPU 配额（CFS）与隔离
在 Pod 内运行这些混合工作负载时，根据资源分配方式的不同，隔离机制也有所区别：
- 独占容器： 被授予独占 CPU 分片的容器，其容器级别的 CPU CFS 配额强制执行被禁用，从而允许它们不受 Linux 调度器的节流限制而运行。
- Pod 共享池容器： 归属于 Pod 共享池的容器，其 CPU CFS 配额在 Pod 级别强制执行，确保它们不会消耗超出剩余 Pod 预算的资源。
如何启用 Pod 级资源管理器
使用此功能需要 Kubernetes v1.36 或更高版本。要启用它，您必须使用相应的特性门控和策略配置 kubelet：
- 启用
PodLevelResources和PodLevelResourceManagers特性门控。 - 配置 拓扑管理器，使用除
none之外的策略（即best-effort、restricted或single-numa-node）。 - 使用 KubeletConfiguration 中的
topologyManagerScope字段，将 拓扑管理器作用域 设置为pod或container。 - 配置 CPU 管理器，使用
static策略。 - 配置 内存管理器，使用
Static策略。
可观测性
为了帮助集群管理员监控和调试这些新的分配模型，我们在启用特性门控后引入了几个新的 kubelet 指标：
resource_manager_allocations_total：统计管理器执行的独占资源分配总数。source标签（”pod” 或 “node”）用于区分是从节点级池还是从预分配的 Pod 级池进行的分配。resource_manager_allocation_errors_total：统计独占资源分配过程中遇到的错误，通过预期的分配source（”pod” 或 “node”）进行区分。resource_manager_container_assignments：跟踪运行特定分配类型的容器的累计数量。assignment_type标签（”node_exclusive”、”pod_exclusive”、”pod_shared”）提供了工作负载分布的可视性。
当前限制与注意事项
虽然此功能开辟了新的可能性，但在其 Alpha 阶段需要注意一些事项。请务必查阅官方文档中的 限制与注意事项，以获取关于兼容性、要求和降级说明的完整详细信息。
开始使用与提供反馈
如需深入了解此功能的技术细节和配置，请查看官方概念文档：
要了解有关整体 Pod 级资源功能以及如何为 Pod 分配资源的更多信息，请参阅：
随着此功能在 Alpha 阶段推进，您的反馈至关重要。请通过标准的 Kubernetes 沟通渠道报告任何问题或分享您的经验：
