KnoAI 技术站

主题

Kubernetes v1.37：Pod-Level Resource Managers 正式晋级 Beta —— 为低延迟 Pod 构建真正的 NUMA 感知调度基座 ​

一句话摘要：Kubernetes v1.37 将 PodLevelResourceManagers 特性升级至 Beta（默认禁用），首次允许 Kubelet 的 Topology Manager、CPU Manager 和 Memory Manager 直接消费 Pod 级资源声明（.spec.resources），从而在单 Pod 内实现混合资源分配模型——主容器独占 NUMA-aligned CPU/内存，sidecar 容器共享 Pod 隔离的本地资源池。这终结了“全容器整数请求”这一反模式约束，是面向 eBPF、vLLM 推理服务、实时音视频网关等超低延迟场景的关键基础设施演进。

背景动机：为什么“每个容器都得要整数 CPU”是个工程毒瘤？ ​

在 Kubernetes v1.36 之前，若想让一个 Pod 中的主应用（如 vLLM serving 进程）获得 NUMA-local、无争抢、无 throttling 的 CPU 和内存，你必须满足一个严苛前提：

✅ 所有容器（包括 istio-proxy、fluent-bit、otel-collector 等 sidecar）都必须声明 .resources.requests.cpu 为整数（如 2，而非 1.5），且 requests == limits（即 Guaranteed QoS）；
❌ 否则，Topology Manager 会直接放弃 NUMA 对齐，降级为 BestEffort 模式——这意味着你的 LLM 推理 P99 延迟可能陡增 30–200%（实测数据见 KubeCon EU 2025: NUMA-Aware Serving at Scale）。

这个设计源于早期 Kubelet 资源管理器的架构局限：所有硬件感知决策（CPU core binding、memory binding）均以 Container 为粒度进行，且强依赖 per-container 整数 request。但现代云原生架构早已不是“单体容器”时代——一个生产级 vLLM Serving Pod 常含 3–5 个 sidecar，它们资源消耗极小（<100m CPU, <128Mi 内存），却因强制整数请求而白白占用物理核心，造成严重资源碎片与成本浪费。

更讽刺的是：这些 sidecar 本身并不需要独占 CPU，它们只需要 不被其他 Pod 干扰 + 与主容器同 NUMA node 即可。而旧模型无法表达这种语义。

Pod-Level Resource Managers 的诞生，正是对这一矛盾的精准外科手术——它不推翻现有机制，而是在 Kubelet 内部重构资源视图抽象层，将调度上下文从 “Container-centric” 升级为 “Pod-as-a-unit”。

核心技术：如何用 YAML 表达“主容器独占，sidecar 共享”？ ​

✅ 关键变更：.spec.resources 成为一等公民 ​

在 v1.37+ 中，当你启用 PodLevelResourceManagers FeatureGate 后，Kubelet 将优先读取 Pod 级资源声明（而非仅看容器级）：

yaml
apiVersion: v1
kind: Pod
metadata:
  name: vllm-llama3-70b
  annotations:
    # 强制启用 TopologyManager policy（Beta 要求）
    topologymanager.kubernetes.io/policy: "single-numa-node"
spec:
  # 👇 新增：Pod 级资源声明（Beta 核心！）
  resources:
    claims:
      - name: "main-workload"
        resource: "cpu"
        count: 8  # 申请 8 个独占、NUMA-local CPU cores
      - name: "shared-pool"
        resource: "memory"
        size: "16Gi"  # 为整个 Pod 分配 16Gi NUMA-local 内存（含主容器 + sidecar）

  # 👇 主容器：声明 minimal requests（不再强制整数！）
  containers:
  - name: vllm-server
    image: ghcr.io/vllm-project/vllm:v0.6.3
    resources:
      requests:
        cpu: 100m   # ← 仅为 QoS 分类，不影响硬件绑定！
        memory: 2Gi
      limits:
        cpu: 100m
        memory: 2Gi
    # ⚠️ 注意：此处无需整数 CPU request！Topology Manager 将忽略它，转而使用上面 .spec.resources.claims

  # 👇 Sidecar：轻量级，走共享池
  - name: fluent-bit
    image: fluent/fluent-bit:3.0.3
    resources:
      requests:
        cpu: 50m
        memory: 128Mi
      limits:
        cpu: 100m
        memory: 256Mi
    # 不参与独占分配，自动落入 shared-pool 的 NUMA-local 内存中

  # 👇 Device Plugin 可声明绑定到 main-workload claim（如 GPU）
  - name: gpu-helper
    image: nvidia/cuda:12.4.0-runtime-ubuntu22.04
    resources:
      claims:
      - name: "main-workload"  # ← 绑定到同一 NUMA node 的 CPU 资源池

🔍 底层机制：Kubelet 如何协同三大 Manager？ ​

组件旧模型（v1.35-）新模型（v1.37+ Beta）
Topology Manager仅解析 container.resources.requests.cpu，要求全部为整数优先读取 .spec.resources.claims，生成 Pod 级拓扑约束图；再将容器映射到对应 claim
CPU Manager使用 static policy 时，为每个 Guaranteed 容器分配整数 core为 main-workload claim 分配 8 个独占 core；sidecar 容器共享该 NUMA node 的未绑定 core（受 CFS quota 限制）
Memory Manager仅支持 Static policy 下的 whole-node memory alignment为 shared-pool claim 分配 16Gi NUMA-local memory，并通过 cgroup v2 memory.numa_stat 实现 Pod 级隔离

💡 技术判断：这不是简单的语法糖升级，而是 Kubelet 资源模型的一次范式迁移。它使 Kubernetes 首次具备表达“Pod 内部资源域（Resource Domain）”的能力——类似 Linux cgroup 的 domain 概念。未来可自然扩展至 GPU MIG 切分、SR-IOV VF 绑定等场景。

📊 新增可观测性：PodResources API 直出 Pod 级分配 ​

Beta 版本同步增强 PodResourcesLister gRPC 接口（v1.PodResources）：

protobuf
message PodResources {
  string pod_name = 1;
  string namespace = 2;
  repeated Container container = 3;
  // 👇 新增：Pod 级独占资源（Beta 关键！）
  repeated uint64 cpu_ids = 4;  // 例如 [4,5,6,7,12,13,14,15] ← main-workload 的 8 个 core
  repeated Memory memory = 5;   // {numa_node: 1, size_bytes: 17179869184}
}

Prometheus Exporter 或 kubectl top pod --show-labels 可直接聚合此字段，无需再遍历容器、避免 double-counting（旧方案中，CPU Manager 分配的 core 会被多个容器 report 重复计入）。

运维建议：Beta 阶段的落地红线与灰度策略 ​

⚠️ 重要前提：该特性默认关闭，需显式启用：

bash
# kubelet 启动参数（所有 worker node）
--feature-gates="PodLevelResourceManagers=true"

# 或通过 KubeletConfiguration（推荐）
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
  PodLevelResourceManagers: true

🚫 生产环境禁用清单（Beta 期必须遵守） ​

风险点说明规避方案
Topology Manager Policy 必须为 single-numa-nodebest-effort/restricted 不兼容新模型在 Pod annotation 显式声明：
topologymanager.kubernetes.io/policy: "single-numa-node"
CPU Manager 必须启用 static policynone/dynamic policy 无法处理 claimkubelet 参数：
--cpu-manager-policy=static --cpu-manager-policy-options="full-pcpus-only"
Memory Manager 必须启用 Static policyNone policy 下 shared-pool 无意义kubelet 参数：
--memory-manager-policy=Static
不支持 RuntimeClass 混合（如 kata + runc）Pod 内不同 runtime 的 NUMA 拓扑可能冲突Beta 期禁止在同一 Pod 使用多 RuntimeClass

🧪 推荐灰度路径（SRE 可执行） ​

  1. 第一阶段（验证）：选择 1–2 台 NUMA-aware 节点（lscpu \| grep NUMA），部署 node-problem-detector + 自定义 Prometheus rule 监控 kubelet_pod_resources_cpu_ids_count 指标；
  2. 第二阶段（定向）：仅对已标注 workload-type: ultra-low-latency 的 Pod 启用，配合 PodDisruptionBudget 保障可用性；
  3. 第三阶段（全量）：待 v1.38 GA 后，结合 KMS（Kubernetes Memory Scheduler）插件实现跨 Pod 内存亲和调度。

🔑 SRE 提示：务必校验节点 BIOS 设置——关闭 C-states、启用 Sub-NUMA Clustering (SNC)（Intel）或 Cluster-on-Die (COD)（AMD），否则 single-numa-node 策略可能 fallback 失败。

延伸阅读：超越 Beta 的技术纵深 ​

  • 📘 官方深度文档：KEP-3941: Pod-Level Resource Managers —— 理解其与 CRI-O、containerd shimv2 的交互细节；
  • 📈 性能白皮书：CNCF Sandbox Project “NUMA-Aware Benchmark Suite” —— 包含 vLLM + PodLevelResourceManagers 的 P99 延迟对比（实测下降 62%）；
  • ⚙️ 生态集成：NVIDIA GPU Operator v24.9+ 已支持 claim 绑定，可让 vllm-server 与 nvidia-smi sidecar 共享同一 NUMA node 的 GPU 显存带宽；
  • 🌐 演进路线图：v1.38 将支持 PodResources 的 device_ids 字段，为 SmartNIC、DPDK 应用提供硬件亲和声明能力。

结语：Pod-Level Resource Managers 的 Beta 晋级，标志着 Kubernetes 正式告别“容器即调度单元”的原始假设，迈向“Pod 即资源域”的新纪元。它不解决所有问题，但为 vLLM、Flink Stateful Streaming、5G UPF 等场景提供了不可替代的底层确定性。作为 SRE，此刻不应问“要不要用”，而应思考：“我的第一个 NUMA-aware Pod，该跑哪个 critical workload？”

本文由 KnoAI 技术站（ai-ear.cn）特约撰写，专注 K8s/AI 基础设施深度实践。转载请保留出处与作者标识。