正在加载，请稍候
智能体自己申请算力后，集群控制面里按人设计的默认值开始漏。拆解身份、配额与组调度三处改造，附最小权限清单与四步迁移路线。
Kubernetes v1.37 在 2026 年 8 月发布，把动态资源分配（DRA）的扩展资源支持送进了 GA，官方博客同期还在讨论 Agent Sandbox 与 AI Gateway 工作组。这一版共包含 67 项增强。做大模型应用开发的人应该读出弦外之音：申请算力的一方，正在从人变成智能体。
过去十年的平台设计默认「资源申请人」是人。这个默认值藏在几乎每一个 API 字段里。
这三条一旦不成立，围绕「人」设计的默认值就会开始漏。漏的方式有两种：配额被合法地占满、审计日志里查不到主语。
要判断自己处在哪个阶段，可以先对照从需求拆解到上线的关键节点梳理，看平台治理排在交付流程的哪一步。
第一个要改的是身份。v1.37 把 Pod 证书与集群信任包又推进了一步，方向很明确：让工作负载自己带着可验证的身份去访问其他系统，而不是长期借用一个共享的 ServiceAccount。
落到实处是两件互相咬合的事。
不要把同类智能体全部塞进同一个 ServiceAccount。用绑定到 Pod 的证书做双向认证，凭据随 Pod 生命周期生灭，任务结束即失效。审计日志里才追得到「是哪个任务要了这块卡」，而不是只留下一句「某个进程申请了四块加速器」。
人按席位算配额，智能体按任务类算。下面这份清单最小可行，配额与权限分开管，权限只给「申请」这一件事。
# 1) 按任务类限总量，不按席位
apiVersion: v1
kind: ResourceQuota
metadata:
name: llm-task-quota
namespace: llm-agent-prod
spec:
hard:
requests.nvidia.com/gpu: "4"
pods: "20"
---
# 2) 只给「申请」，不给「绕过」
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: agent-self-service
namespace: llm-agent-prod
rules:
- apiGroups: ["resource.k8s.io"]
resources: ["resourceclaims"]
verbs: ["create", "get", "delete"]
# 注意：故意不给 nodes / pods / deployments 的写权限
关键在 verbs 那一行。智能体需要的是「申请一张资源声明」，不是「改集群」。很容易踩的坑是图省事给一个聚合的 edit 角色——一旦给了，一个写错的重试循环就能改掉同一命名空间里其他负载的副本数。这不是理论风险，是权限模型和调用模式不匹配的必然结果。
第二处改造发生在控制面自身。2026 年有三个变化最值得关注。
动态资源分配把「我要 1 个 GPU」升级成「我要一块满足这些属性的加速器」。扩展资源支持在 v1.37 转为 GA，团队为这个里程碑连续推了三个版本。
差别在哪？以前靠设备插件，一个节点上 8 张卡就是 8 个整数位，谁抢到算谁的。现在用声明式选择器，可以在清单里写清显存下限、互联方式、架构代次。对大模型应用开发来说，这直接决定推理服务是能跑起来，还是「调度成功、一加载就爆显存」。
v1.37 把 Workload 与 PodGroup 这两个 API推到了新的里程碑，并把抢占也提升到组级别，解决的是「编排任务半启动」这个老问题。
一个 8 副本的并行推理任务，如果只调起 5 个 Pod，剩下 3 个占着配额不干活，前 5 个在等它们的数据。组调度让这 8 个 Pod 作为整体被接受，或整体被拒绝。
水平自动扩缩在 v1.37 支持缩到 0 副本，且默认开启。对按需触发的智能体任务链，这意味着没有任务时不必为「待命」付机器钱。
| 维度 | 面向人的旧默认 | 2026 年的做法 | 对应能力 |
|---|---|---|---|
| 身份 | 长期共享账号 | 任务级短期凭据 | Pod 证书与信任包 |
| 配额 | 按席位 | 按任务类 | 配额对象 + 精细角色 |
| 资源描述 | 整数计数 | 属性选择器 | 动态资源分配 |
| 启动方式 | 逐个 Pod | 整组接受或拒绝 | 组调度与组级抢占 |
| 空闲成本 | 常驻待命 | 无任务即缩到 0 | 自动扩缩缩零 |
第三个改造点最容易被忽略，但它决定了前两件事能不能规模化。
智能体一旦跨集群申请资源，同一份声明在 A 集群能过、在 B 集群被拒，排查成本极高——你面对的是两个版本基线的行为差异，不是自己的代码缺陷。社区在 2026 年的动作很集中：一边成立 AI Gateway 工作组收敛 AI 流量的入口规则，一边推进针对 AI 负载的统一兼容性认证方向，让「这套配置在哪些发行版上合规」有一个共同答案。
把智能体当成无状态 Web 服务来调度，配额是会被「占满但不用」的。八个 Pod 只起来五个，另外三个拿住了配额在等——从调度器视角看它没违规，从业务视角看这批卡白烧。
组调度能力就是为了关掉这个缺口。在它落地之前，只能给每个任务留冗余配额，成本直接上浮，上浮多少还完全靠拍脑袋。
所有智能体共用一个账号，日志里只能看到「某个进程申请了四块卡」，看不到是哪个任务、哪次对话、哪个用户触发的。等真出事要回溯，能拿到的只有一堆没有主语的记录。
身份和配额这两件事必须一起改。只改配额，你能拦住超额；只改身份，你能查到是谁；两件都改，才能既拦得住又查得清。
平台侧怎么组织这类改造，可以参考三家海外企业的智能体生产复盘——他们共同的经验是先建平台、再放量。
常见的失误是把第 2 步和第 4 步并行：权限先放开、回收机制还没建起来，配额会在两周内被历史任务占满，之后所有新任务都排不上队。
不必。多数团队只需用到集群已经提供的能力，比如按任务类的配额、组调度、缩到零。真正需要改控制面行为的，是自建平台、并要给内外部多个团队提供算力池的那一类团队。
扩展资源支持已转正式可用，说明核心接口稳定。但该特性族里仍有若干处于试验阶段的子能力，请按自己实际使用的发行版逐项确认，不要只看版本号。
按任务类，不按席位。同一类任务共享一个配额池，池子上限由平台侧定。不要让每个智能体实例自带配额，否则并发一上来，配额碎片会先于算力成为瓶颈。
不冲突，但顺序要对。组调度管的是「能不能一起起来」，缩零管的是「没事时别占着」。先保证整组能起来，再决定空闲态缩不缩。
取决于你用托管集群还是自建。托管集群主要是身份与配额治理，通常一到两个平台工程师按迭代推进即可；要改调度行为，则需要按季度规划。
权限与配额治理本质上是交付节奏的一部分。我们交付过的项目案例里有完整的落地顺序，需要讨论你所在集群的具体边界，可以联系我们直接说明现状。