AI工作负载如何重塑Kubernetes自动扩缩容
内容提要
Kubernetes调度器与自动扩缩器长期独立分工，在AI加速器场景下导致Pod待调度而加速器闲置。社区通过动态资源分配（DRA）统一硬件描述语言，解决预留容量、拓扑亲和与设备共享问题；但组调度等仍需二者协同。目前SIG-Autoscaling正推动集成API，让扩缩器感知调度需求，避免重复模拟与资源浪费。
延伸解读
调度与扩缩容的“语言不通”是闲置的根源
文章指出，Pod 待调度而加速器闲置，有时并非区域容量耗尽，而是自动扩缩器愿意添加的节点与调度器愿意使用的节点不一致。扩缩器只回答“是否加节点”，却不判断节点形状是否适合工作负载。这种分工在通用计算时代合理，但在加速器场景下，两个控制循环对“可用节点”的定义出现分歧，导致昂贵硬件空转。读者遇到 Pod 长期 Pending 时，应先排查两个循环是否对节点能力有共识，而非直接归因于容量不足。
DRA 统一硬件描述，但只解决“共同语言”
动态资源分配（DRA）让工作负载以结构化声明表达需求，例如加速器与为其供料的网络接口之间的关系，调度器可直接读取这些声明。DRA 感知的扩缩器也开始在模拟容量时使用相同信息，减少双方对可行节点的误判。但文章强调，共享词汇不等于协同行动：组调度等场景仍需两个循环作为整体决策，而扩缩器目前仍逐个 Pod 推理，可能为部分成员加节点却让整个任务无法启动。
组调度暴露“螺栓式”桥接的局限
工作负载感知调度让调度器将一组 Pod 视为全有或全无的单元，但其 Workload 和 PodGroup API 仍处于 beta 且默认禁用，扩缩器并未参与这一变化。当前通过 provisioning request 让工作负载一次性申请整组容量，并由 Kueue 预留配额、等待容量就绪后准入，但原子扩缩是尽力而为且依赖提供商支持。文章认为这仍是跨接缝的附加机制，而非共享理解，说明组调度问题尚未被根本解决。
集成 API 的走向值得加速器运营者关注
SIG-Autoscaling 的公开提案正在勾勒集成 API，让调度器看到可被供应的容量、表达跨容量的放置偏好并显式请求容量。其深层动机是流程：若扩缩容在功能设计初期就被视为一等关切，供应问题会在新放置原语成型时被考虑，而非等发布后由扩缩器补救。文章提醒，这些接口正在 SIG-Autoscaling 和 SIG-Scheduling 公开绘制，而非某家厂商产品中，运行加速器的团队既有切身利益，也有机会在设计定型前参与塑造。
Q&A
为什么AI工作负载下Pod会一直Pending，但集群其实还有GPU容量？
因为调度器和自动扩缩器对“可用节点”的判断不一致：自动扩缩器愿意添加的节点，调度器可能不愿意使用。例如节点不满足拓扑或设备共享要求，导致Pod无法调度，而加速器容量闲置。
Kubernetes动态资源分配（DRA）解决了AI加速器场景的什么问题？
DRA用结构化声明替代简单的设备计数，让工作负载能描述设备关系（如加速器与网卡同PCIe路径），调度器直接读取这些声明，从而支持预留容量、拓扑亲和和设备共享，减少调度器与扩缩器对硬件描述的歧义。
AI加速器的拓扑为什么对调度很重要？
加速器性能依赖本地NUMA域、共享PCIe路径的网卡以及高速互联的对等设备。拓扑是分层级的（同一总线、机架内快速互联、跨机架网络），大模型跨多服务器，保持设备就近能避免流量经过慢速跳转，否则性能下降。
设备共享中的分区和可消费容量有什么区别？
分区是把一个设备拆成多个隔离的固定实例；可消费容量则允许更细粒度，多个工作负载各取测量后的一部分，一个请求可由设备的一小部分满足。两者都旨在减少整设备分配带来的浪费，但可消费容量更灵活。
为什么有了DRA统一语言，还需要组调度？
组调度要求一组Pod全部调度或全不调度，而DRA只让双方对节点硬件有共同理解，不能保证协同行动。自动扩缩器仍逐个Pod推理，可能为组内少数Pending Pod添加节点却浪费容量，导致作业无法启动。
SIG-Autoscaling正在推动什么集成API？
正在设计让调度器和自动扩缩器直接对话的API：让调度器看到可供给的容量（而非仅现有节点）、表达跨容量的放置偏好、并显式请求容量。目的是在功能设计早期就考虑供给，减少事后弥补。
