---
title: "AI负载如何改写Kubernetes自动扩缩容：调度器与扩缩器必须说同一种硬件语言 - Angryecho"
description: "长期以来，Kubernetes把「调度」和「自动扩缩容」分成两套控制回路：调度器把 Pod 放到已有节点上，自动扩缩器在 Pod 放不下时再加节点。普通可互换算力时代，两套回路不必深度互通。GPU 等加速器与 AI 负载把这条分工推到了边界——节点看起来还有余量，Pod 却一直 Pending；昂贵加速器可能因此空转。"
canonical_url: "https://www.angryecho.com/c/DevOps/p/P2TBBoroVxBLBpZkCqTlh"
meta:
  "og:description": "长期以来，Kubernetes把「调度」和「自动扩缩容」分成两套控制回路：调度器把 Pod 放到已有节点上，自动扩缩器在 Pod 放不下时再加节点。普通可互换算力时代，两套回路不必深度互通。GPU 等加速器与 AI 负载把这条分工推到了边界——节点看起来还有余量，Pod 却一直 Pending；昂贵加速器可能因此空转。"
  "og:image": "https://www.angryecho.com/_og/d/c_Post%2Ctitle_~5ZCQ5qe9572R%2Cdescription_~5ZCQ5qe95LiA5LiL77yM5bCx5LiK5ZCQ5qe9572R44CC%2CpostId_P2TBBoroVxBLBpZkCqTlh%2Crevision_~MjAyNi0xMC0yN1QwMjo1Nzo0OS4yMjMzNTBa%2Cp_Ii9jL0Rldk9wcy9wL1AyVEJCb3JvVnhCTEJwWmtDcVRsaCI%2Cs_NBELnXRGgn4U2xOJ.png"
  "og:image:height": "630"
  "og:image:type": image/png
  "og:image:width": "1200"
  "og:title": AI负载如何改写Kubernetes自动扩缩容：调度器与扩缩器必须说同一种硬件语言
---

> Index of every page on this site: [llms.txt](https://www.angryecho.com/llms.txt)

# **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》](https://www.cncf.io/blog/2026/10/19/how-ai-workloads-are-reshaping-kubernetes-autoscaling/)，2026年10月19日。

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

排序方式 :

### **成为第一条评论！**

Nobody's responded to this post yet. Add your thoughts and get the conversation going.

```json
{"@context":"https://schema.org","@graph":[{"@id":"https://www.angryecho.com/c/DevOps/p/P2TBBoroVxBLBpZkCqTlh#post","@type":"DiscussionForumPosting","commentCount":0,"dateModified":"2026-10-27T02:57:49.223Z","datePublished":"2026-10-19T04:00:00.000Z","description":"长期以来，Kubernetes把「调度」和「自动扩缩容」分成两套控制回路：调度器把 Pod 放到已有节点上，自动扩缩器在 Pod 放不下时再加节点。普通可互换算力时代，两套回路不必深度互通。GPU 等加速器与 AI 负载把这条分工推到了边界——节点看起来还有余量，Pod 却一直 Pending；昂贵加速器可能因此空转。","headline":"AI负载如何改写Kubernetes自动扩缩容：调度器与扩缩器必须说同一种硬件语言","isPartOf":"https://www.angryecho.com/c/DevOps","mainEntityOfPage":"https://www.angryecho.com/c/DevOps/p/P2TBBoroVxBLBpZkCqTlh","text":"长期以来，Kubernetes把「调度」和「自动扩缩容」分成两套控制回路：调度器把 Pod 放到已有节点上，自动扩缩器在 Pod 放不下时再加节点。普通可互换算力时代，两套回路不必深度互通。GPU 等加速器与 AI 负载把这条分工推到了边界——节点看起来还有余量，Pod 却一直 Pending；昂贵加速器可能因此空转。AWS 工程师 Sajjan Gundapuneedi 与 Neelendra Bhandari 在2026年10月19日的 CNCF 博客里，把问题拆成「预约容量、拓扑、共享切分、团调度」几条线。[1]\n\n预约（Reservations） 并不新鲜：加速器供给紧、空转贵，团队常提前锁定容量。扩缩器决定「要不要加节点」时，还得判断新节点是否落在已付费预约上，而不是只盯现货供给。[1]\n\n拓扑（Topology） 讲的是设备怎么连，而不只是数量。加速器依赖同 NUMA 域的 CPU/内存、同 PCIe 路径的网卡、以及与同伴加速器的高速互联；大模型还会跨多台服务器，对「放在一起」的要求远超单机。过去 K8s 常把加速器当成整数计数，调度只匹配「要几个」。动态资源分配（Dynamic Resource Allocation，DRA）补上结构化声明：工作负载可以描述「加速器 + 给它喂数据的网卡」这类关系，调度器直接读这些声明；感知 DRA 的扩缩器也开始用同一套信息做容量模拟，但各实现支持程度仍不一致。[1]\n\n共享（Sharing） 则把整卡浪费变成可切分：可分区设备把一张卡拆成隔离实例；可消费容量（consumable capacity）允许多个负载各取一部分。调度器跟踪这些分配，DRA 感知的扩缩器开始用同一模型评估候选节点。切细了可能留下碎片，合理的最小步长能把浪费压到低于「整卡独占」的老办法。[1]\n\n共享词汇还不够。团调度（gang scheduling） 要求一组 Pod 要么一起调度、要么都不调度。上游工作负载感知调度（Workload / PodGroup，目前仍为 beta、默认关闭）让调度器把一组当成原子单位；扩缩器却仍多按单个 Pod 思考，可能只给团里几只 Pod 加了节点，作业永远起不来，容量反而被占住。当前的桥接之一是 provisioning request：工作负载一次性向扩缩器要整组容量；配合 Kueue 等准入检查，可先占配额、等容量就绪再放行，但原子扩容仍是尽力而为，依赖云厂商支持。[1]\n\n社区下一步讨论的是：让调度器看见「可以开出来但还没有」的容量，让扩缩偏好与显式请求成为一等接口，并在设计新放置原语时就把扩缩一起想进去。对跑加速器的人来说，Pod Pending 时别先断定「区里没卡了」——先查调度器与扩缩器是否对「什么叫可用节点」意见一致。[1]\n\n来源\n\n\n\n[1] CNCF Blog：Sajjan Gundapuneedi & Neelendra Bhandari，《How AI workloads are reshaping Kubernetes autoscaling》，2026年10月19日。\n\n#Kubernetes #自动扩缩容 #DRA #AI基础设施 #CNCF","url":"https://www.angryecho.com/c/DevOps/p/P2TBBoroVxBLBpZkCqTlh","author":{"@type":"Person","name":"Anil Mavian","url":"https://www.angryecho.com/u/P7H10332459"},"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":0},{"@type":"InteractionCounter","interactionType":"https://schema.org/DislikeAction","userInteractionCount":0},{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":0},{"@type":"InteractionCounter","interactionType":"https://schema.org/ShareAction","userInteractionCount":0}]}]}
```

## Sitemap

See the full [sitemap](https://www.angryecho.com/sitemap.md) for all pages.