当业务对延迟和带宽极其敏感时，单纯依靠Kubernetes默认的调度逻辑已经不够用。默认调度器主要看CPU和内存总量是否充足，却很少关心这些资源在物理机器上的位置关系。比如一个容器被分到了NUMA节点0的CPU，但内存却被分配在NUMA节点1，每次访存都要跨越NUMA边界，性能会明显下滑。拓扑感知调度与拓扑管理器正是为了解决这类“资源位置错配”问题而存在的两套机制，它们分别工作在调度和节点执行两个层面。
拓扑管理器在节点侧的工作机制
拓扑管理器是kubelet内部的一个组件，它在Pod所有容器真正启动之前介入。它的核心任务是把容器请求的各种拓扑相关资源（例如CPU、内存、GPU、网卡）的分配结果进行对齐校验。Kubernetes里与之配合的还有CPU管理器、设备管理器以及内存管理器，它们各自先给出资源分配建议，拓扑管理器再根据配置的拓扑策略进行对齐。
拓扑管理器支持几种策略，最常用的是none、best-effort、restricted和single-numa-node。其中single-numa-node要求所有Requested资源必须来自同一个NUMA节点，否则该容器无法启动；restricted则允许跨NUMA但会拒绝无法对齐的分配；best-effort只做优化尝试但不阻断启动。这些策略通过kubelet参数--topology-manager-policy设置，并在Pod的topology.kubernetes.io/affinity等注解或QoS类配合下生效。
下面是一段kubelet配置拓扑策略的简化示例，展示如何强制开启单NUMA对齐：
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
topologyManagerPolicy: single-numa-node
topologyManagerScope: pod
cpuManagerPolicy: static
memoryManagerPolicy: Static
reservedMemory:
- numaNode: 0
limits:
memory: 1Gi
从实现角度看，拓扑管理器维护了一个“拓扑提示”集合。每个资源分配器在分配前会提供自己倾向的NUMA节点列表，拓扑管理器取交集。如果交集为空且策略严格，就返回错误，kubelet会拒绝运行该容器。这种机制把资源错配问题拦截在节点本地，避免了调度器远端无法感知硬件细节的缺陷。
调度器侧的拓扑感知能力
虽然拓扑管理器能兜底，但最好别让Pod被调度到根本无法满足拓扑条件的节点上，否则只会反复失败。Kubernetes调度器从1.18左右开始逐步引入拓扑相关的插件，例如NodeResourceTopologyMatch插件，它依据节点上报的NodeResourceTopology CR对象来判断节点是否能满足Pod的拓扑诉求。
节点会通过资源拓扑发现程序（如Topology Manager与设备插件协作）生成类似“NUMA 0有16核、32G内存、2块GPU；NUMA 1有16核、32G内存”的描述，并以CR形式暴露在集群里。调度器读取这些信息后，可以在过滤阶段就把不满足NUMA对齐要求的节点剔除。例如下面这段Pod定义希望调度器优先选到能提供单NUMA节点的机器：
apiVersion: v1
kind: Pod
metadata:
name: numa-aware-app
annotations:
topology.kubernetes.io/affinity: prefer-single-numa-node
spec:
containers:
- name: app
image: registry.ipipp.com/example/app:v1
resources:
limits:
cpu: "4"
memory: 4Gi
nvidia.com/gpu: 1
与节点侧管理器不同，调度器侧的感知是“预判式”的。它不能保证最终kubelet分配绝对成功，因为节点状态可能变化，但它显著降低了错误调度率。在生产中，往往同时开启调度器插件和kubelet拓扑策略，形成“远端筛选加本地校验”的双保险结构。
两者协同与典型配置误区
很多团队误以为只要开了调度器的拓扑插件就万事大吉，结果Pod卡在节点上起不来，原因正是调度器认为节点“看起来”能满足，但kubelet实际分配时因为已用资源碎片导致交集为空。此时如果拓扑策略是restricted或single-numa-node，容器就会被驱逐或一直Pending。因此协同的关键在于：调度器掌握的拓扑数据必须和kubelet真实状态尽量一致，且策略严格度要匹配业务容忍度。
另一个常见误区是混淆QoS与拓扑策略的关系。只有当Pod是Guaranteed QoS（即CPU和内存都设了相同的limits和requests）时，CPU管理器的static策略才会把专用核分配给容器，拓扑管理器也才能做精确的NUMA对齐。如果Pod是Burstable，多数资源走共享池，拓扑对齐效果会大打折扣。下面代码展示了正确的Guaranteed Pod写法：
apiVersion: v1
kind: Pod
metadata:
name: guaranteed-numa
spec:
containers:
- name: c
image: registry.ipipp.com/example/c:v1
resources:
requests:
cpu: "2"
memory: 2Gi
limits:
cpu: "2"
memory: 2Gi
从运维角度，建议先在非核心业务上用best-effort观察拓扑对齐率，再逐步切换到restricted。同时配合调度器的TopologyMatch插件，让不匹配的节点直接过滤掉。这样既能享受拓扑优化带来的低延迟，又不会因为策略过严导致大面积不可用。理解两套机制职责边界，是构建高性能 Kubernetes 集群的基础。
Kubernetes拓扑感知调度拓扑管理器修改时间：2026-08-13 10:01:02