Kubernetes v1.36：Pod 级资源管理器（Alpha）

Kubernetes v1.36 将 Pod 级资源管理器作为 Alpha 特性引入，为性能敏感型工作负载带来更灵活、更强大的资源管理模型。该增强扩展了 kubelet 的 Topology、CPU 和 Memory Manager，使其支持 Pod 级资源规格（.spec.resources），从严格的按容器分配模型演进为以 Pod 为中心的模型。

为什么需要 Pod 级资源管理器？

在运行机器学习（ML）训练、高频交易应用或低延迟数据库等性能关键型工作负载时，你通常需要为主要应用容器提供独占且 NUMA 对齐的资源，以确保可预测的性能。

然而，现代 Kubernetes Pod 很少只包含一个容器。它们通常会包含用于日志、监控、服务网格或数据摄取的 sidecar 容器。

在该特性出现之前，这会带来一种权衡：为了给主应用获取 NUMA 对齐的独占资源，你必须为 Pod 中的每个容器分配独占的、基于整数的 CPU 资源。这对轻量级 sidecar 来说可能是浪费。如果不这样做，就会完全放弃该 Pod 的 Guaranteed 服务质量（QoS）类别，从而失去性能收益。

引入 Pod 级资源管理器

为资源管理器启用 Pod 级资源支持（通过 PodLevelResourceManagers 和 PodLevelResources 特性门控）后，kubelet 可以创建混合资源分配模型。这在不牺牲 NUMA 对齐的情况下，为高性能工作负载带来灵活性和效率。

真实使用场景

以下是几个实际场景，展示该特性如何根据配置的 Topology Manager 作用域进行应用：

1. 紧密耦合的数据库（Topology Manager 的 Pod 作用域）

设想一个对延迟敏感的数据库 Pod，其中包含一个主数据库容器、一个本地指标导出器和一个备份代理 sidecar。

当配置为 Pod Topology Manager 作用域时，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"

设想一个 Pod 运行 GPU 加速的 ML 训练工作负载，同时运行一个通用服务网格 sidecar。

在容器 Topology Manager 作用域下，kubelet 会单独评估每个容器。你可以为 ML 容器授予独占、NUMA 对齐的 CPU 和内存，以获得最高性能。同时，服务网格 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 共享池的容器会在 Pod 级别强制执行 CPU CFS 配额，确保它们不会消耗超过 Pod 剩余预算的资源。

如何启用 Pod 级资源管理器

使用该特性需要 Kubernetes v1.36 或更新版本。要启用它，必须使用相应的特性门控和策略配置 kubelet：

1. 启用 PodLevelResources 和 PodLevelResourceManagers 特性门控。
2. 使用非 none 的策略配置 Topology Manager（即 best-effort、restricted 或 single-numa-node）。
3. 通过 KubeletConfiguration 中的 topologyManagerScope 字段，将 Topology Manager 作用域设置为 pod 或 container。
4. 使用 static 策略配置 CPU Manager。
5. 使用 Static 策略配置 Memory Manager。

可观测性

为帮助集群管理员监控和调试这些新的分配模型，在启用特性门控时，我们引入了多个新的 kubelet 指标：

• resource_manager_allocations_total：统计由管理器执行的独占资源分配总数。source 标签（“pod”或“node”）用于区分分配来自节点级资源池，还是来自预分配的 Pod 级资源池。
• resource_manager_allocation_errors_total：统计独占资源分配期间遇到的错误，并按预期分配来源（“pod”或“node”）进行区分。
• resource_manager_container_assignments：跟踪以特定分配类型运行的容器累计数量。assignment_type 标签（“node_exclusive”、“pod_exclusive”、“pod_shared”）提供对工作负载分布方式的可见性。

当前限制与注意事项

虽然该特性开启了新的可能性，但在 Alpha 阶段仍有一些事项需要注意。请务必查看官方文档中的限制与注意事项，以获取有关兼容性、要求和降级说明的完整细节。

开始使用并提供反馈

如需深入了解该特性的技术细节和配置，请查看官方概念文档：

• Pod 级资源管理器

如需了解整体 Pod 级资源特性以及如何为 Pod 分配资源，请参见：

• 分配 Pod 级 CPU 和内存资源

随着该特性推进 Alpha 阶段，你的反馈非常宝贵。请通过标准 Kubernetes 沟通渠道报告任何问题或分享你的使用经验：

• 正文：Slack：#sig-node
• 邮件列表
• 开放的社区 Issue/PR

• ← 上一篇
• 下一篇 →