容器自动适配NUMA需满足：硬件为多路服务器且BIOS启用NUMA；K8s集群≥v1.18并使用支持NUMA的ECS规格；通过numactl/lscpu验证NUMA节点；安装ack-koordinator≥v1.2.0并启用CPU/内存拓扑感知；Pod需设置static CPU manager policy、guaranteed QoS及明确资源请求；最终通过numastat/perf验证本地访存占比＞95%。
确认底层硬件与集群支持
容器要自动适配 numa，前提是运行环境本身具备 numa 拓扑且被正确识别。需确保：
- 宿主机是多路服务器（如 2 路/4 路 Intel 至强或 AMD EPYC），且 BIOS 中已启用 NUMA（部分厂商默认开启）
- Kubernetes 集群为 ACK Pro 或兼容的托管版，版本 ≥ v1.18
- Worker 节点使用支持 NUMA 感知的 ECS 实例规格，例如 ecs.ebmc8i.48xlarge、ecs.g8i.48xlarge 等八代神龙裸金属机型
- 通过 numactl --hardware 登录节点验证输出含多个 node（如 available: 2 nodes (0-1)），并检查 lscpu | grep -i numa 显示 NUMA node(s) 数量
安装并启用 NUMA 感知调度组件
原生 Kubernetes 不具备 NUMA 拓扑感知能力，需依赖增强型调度器：
- 安装 ack-koordinator（v1.2.0-ack1.2 及以上），它已整合 resource-controller 功能；若旧集群已部署 resource-controller，须先卸载再安装
- 启用 CPU 拓扑感知调度（CPU Manager + Topology Manager），确保 Pod 的 CPU 分配与 NUMA 节点对齐
- 在 ack-koordinator 配置中开启 内存就近访问加速（Memory Locality Acceleration），该功能会自动触发远端内存向本地 NUMA 节点迁移
- 验证组件运行状态：kubectl get pods -n kube-system | grep koordinator 应全部 Running
为工作负载声明 NUMA 亲和策略
仅靠组件无法自动生效，Pod 必须显式表达资源诉求：
- 设置 resource limits/requests 明确 CPU 和内存需求（如 cpu: 8, memory: 32Gi），Topology Manager 才能据此匹配 NUMA 边界
- 添加 topology.kubernetes.io/region 或自定义 label 标识 NUMA 意图（非必须，但便于策略控制）
- 关键：启用 static CPU manager policy 并配合 guaranteed QoS（即 requests == limits），这是触发 NUMA 绑定的前提条件
- 可选进阶：通过 pod topology spread constraints 避免多个高内存 Pod 挤在同一 NUMA 节点上造成带宽争抢
验证与调优效果
配置后不能只看是否调度成功，要确认实际访存行为是否本地化：
- 进入 Pod 容器执行 numastat -p $(pidof your_app)，观察 numa_hit 占比应 >95%，numa_miss / numa_foreign 接近 0
- 在宿主机侧用 perf stat -e mem-loads,mem-stores -p $(pgrep -f your_app) 对比跨节点访存事件比例
- 对比启用前后延迟敏感指标：数据库 P99 响应时间、AI 训练 step time、缓存命中率等，典型提升在 15%–30%
- 若发现迁移滞后，可调大 ack-koordinator 中 memory-migration 模块的扫描频率与单次迁移页数阈值
