Topology Manager 设计方案
September 10, 2020
注：本文翻译自 Node Topology Manager 概要 # 越来越多的系统将 CPU 和硬件加速器组合使用，以支撑高延迟和搞吞吐量的并行计算。 包括电信、科学计算、机器学习、金融服务和数据分析等领域的工作。这种的混血儿构成了一个高性能环境。 为了达到最优性能，需要对 CPU 隔离、内存和设备的物理位置进行优化。 然而，在 kubernetes 中，这些优化没有一个统一的组件管理。 本次建议提供一个新机制，可以协同 kubernetes 各个组件，对硬件资源的分配可以有不同的细粒度。 启发 # 当前，kubelet 中多个组件决定系统拓扑相关的分配： CPU 管理器 CPU 管理器限制容器可以使用的 CPU。该能力，在 1.8 只实现了一种策略——静态分配。 该策略不支持在容器的生命周期内，动态上下线 CPU。 设备管理器 设备管理器将某个具体的设备分配给有该设备需求的容器。设备通常是在外围互连线上。 如果设备管理器和 CPU 管理器策略不一致，那么 CPU 和设备之间的所有通信都可能导致处理器互连结构上的额外跳转。 容器运行时（CNI） 网络接口控制器，包括 SR-IOV 虚拟功能（VF）和套接字有亲和关系，socket 不同，性能不同。 相关问题： 节点层级的硬件拓扑感知（包括 NUMA） 发现节点的 NUMA 架构 绑定特定 CPU 支持虚拟函数 提议：CPU 亲和与 NUMA 拓扑感知 注意，以上所有的关注点都只适用于多套接字系统。 内核能从底层硬件接收精确的拓扑信息（通常是通过 SLIT 表），是正确操作的前提。 更多信息请参考 ACPI 规范的 5.2.16 和 5.2.17 节。 目标 # 根据 CPU 管理器和设备管理器的输入，给容器选择最优的 NUMA 亲和节点。 集成 kubelet 中其他支持拓扑感知的组件，提供一个统一的内部接口。 非目标 # 设备间连接：根据直接设备互连来决定设备分配。此问题不同于套接字局部性。设备间的拓扑关系， 可以都在设备管理器中考虑，可以做到套接字的亲和性。实现这一策略，可以从逐渐支持任何设备之间的拓扑关系。 大页：本次提议有 2 个前提，一是集群中的节点已经预分配了大页； 二是操作系统能给容器做好本地页分配（只需要本地内存节点上有空闲的大页即可）。 容器网络接口：本次提议不包含修改 CNI。但是，如果 CNI 后续支持拓扑管理， 此次提出的方案应该具有良好的扩展性，以适配网络接口的局部性。对于特殊的网络需求， 可以使用设备插件 API 作为临时方案，以减少网络接口的局限性。 用户故事 # 故事 1: 快速虚拟化的网络功能 ...