AI负载如何改写Kubernetes自动扩缩容：调度器与扩缩器必须说同一种硬件语言

长期以来，Kubernetes把「调度」和「自动扩缩容」分成两套控制回路：调度器把 Pod 放到已有节点上，自动扩缩器在 Pod 放不下时再加节点。普通可互换算力时代，两套回路不必深度互通。GPU 等加速器与 AI 负载把这条分工推到了边界——节点看起来还有余量，Pod 却一直 Pending；昂贵加速器可能因此空转。AWS 工程师 Sajjan Gundapuneedi 与 Neelendra Bhandari 在2026年10月19日的 CNCF 博客里，把问题拆成「预约容量、拓扑、共享切分、团调度」几条线。[1]

预约（Reservations） 并不新鲜：加速器供给紧、空转贵，团队常提前锁定容量。扩缩器决定「要不要加节点」时，还得判断新节点是否落在已付费预约上，而不是只盯现货供给。[1]

拓扑（Topology） 讲的是设备怎么连，而不只是数量。加速器依赖同 NUMA 域的 CPU/内存、同 PCIe 路径的网卡、以及与同伴加速器的高速互联；大模型还会跨多台服务器，对「放在一起」的要求远超单机。过去 K8s 常把加速器当成整数计数，调度只匹配「要几个」。动态资源分配（Dynamic Resource Allocation，DRA）补上结构化声明：工作负载可以描述「加速器 + 给它喂数据的网卡」这类关系，调度器直接读这些声明；感知 DRA 的扩缩器也开始用同一套信息做容量模拟，但各实现支持程度仍不一致。[1]

共享（Sharing） 则把整卡浪费变成可切分：可分区设备把一张卡拆成隔离实例；可消费容量（consumable capacity）允许多个负载各取一部分。调度器跟踪这些分配，DRA 感知的扩缩器开始用同一模型评估候选节点。切细了可能留下碎片，合理的最小步长能把浪费压到低于「整卡独占」的老办法。[1]

共享词汇还不够。团调度（gang scheduling） 要求一组 Pod 要么一起调度、要么都不调度。上游工作负载感知调度（Workload / PodGroup，目前仍为 beta、默认关闭）让调度器把一组当成原子单位；扩缩器却仍多按单个 Pod 思考，可能只给团里几只 Pod 加了节点，作业永远起不来，容量反而被占住。当前的桥接之一是 provisioning request：工作负载一次性向扩缩器要整组容量；配合 Kueue 等准入检查，可先占配额、等容量就绪再放行，但原子扩容仍是尽力而为，依赖云厂商支持。[1]

社区下一步讨论的是：让调度器看见「可以开出来但还没有」的容量，让扩缩偏好与显式请求成为一等接口，并在设计新放置原语时就把扩缩一起想进去。对跑加速器的人来说，Pod Pending 时别先断定「区里没卡了」——先查调度器与扩缩器是否对「什么叫可用节点」意见一致。[1]

来源

[1] CNCF Blog：Sajjan Gundapuneedi & Neelendra Bhandari，《How AI workloads are reshaping Kubernetes autoscaling》，2026年10月19日。

#Kubernetes #自动扩缩容 #DRA #AI基础设施 #CNCF