📚 课程目录第4章配额分配策略

4、配额分配策略：基于角色的分配、基于项目的分配、基于优先级的抢占策略

配额分配这件事，说白了就是「怎么分蛋糕」。蛋糕就那么大，分给谁、分多少、谁先吃，这三个问题搞不清楚，资源管控就是一句空话。我这些年见过太多团队，配额策略拍脑袋定，结果线上天天打架——大数据团队说跑不动，AI 团队说训练卡死，运维夹在中间两头挨骂。

今天咱们就把这三种主流分配策略掰开揉碎。你想想看，它们其实对应了三种不同的管理视角：角色看的是「你是谁」，项目看的是「你要干什么」，优先级看的是「你急不急」。

核心观点：没有完美的分配策略，只有适合场景的组合拳。我个人的习惯是「角色定基线、项目定弹性、优先级定兜底」。

4.1 基于角色的分配：你是谁，决定了你能拿多少

这是最基础、也最常用的策略。它的逻辑很简单：把用户或服务账号归到不同的角色组，每个组有固定的配额上限。比如「数据工程师」组给 200 核 CPU、「算法研究员」组给 500 核 GPU、「运维组」给 50 核。

我在项目中遇到过一个问题：某公司把所有开发人员都塞进一个「developer」角色，结果有人跑模型训练占满资源，其他人连编译代码都排队。后来我们按职能拆成「dev-compute」「dev-gpu」「dev-light」三个角色，每个角色配额独立，问题就解决了。

实践建议：角色粒度不要太粗也不要太细。我一般控制在 5~8 个角色组，超过 10 个管理成本会急剧上升。每个角色组建议设置「硬上限」和「软上限」——硬上限是打死不能超的，软上限允许短时借用。

角色分配的核心配置项通常包括：

角色名称：唯一标识，建议用业务语义命名，如 role:data-engineer
资源类型：CPU、内存、GPU、存储、网络带宽等
配额上限：值（如 200 核）或百分比（如集群总量的 20%）
超配策略：是否允许超配、超配比例、超配时长限制
生效范围：全局、指定集群、指定命名空间

举个例子，在 Kubernetes 中基于角色的配额配置大概长这样：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: quota-data-engineer
  namespace: team-data
spec:
  hard:
    requests.cpu: "200"
    requests.memory: "512Gi"
    limits.cpu: "400"
    limits.memory: "1Ti"
    persistentvolumeclaims: "20"
  scopeSelector:
    matchExpressions:
      - operator: In
        scopeName: PriorityClass
        values:
          - role-data-engineer

注意：角色分配容易踩的坑是「角色膨胀」。我曾经见过一个团队搞了 30 多个角色，每个角色配额都不同，最后没人记得清谁该用哪个。建议定期（每季度）审视角色列表，合并低频角色。

4.2 基于项目的分配：按业务需求动态切分

项目分配比角色分配更灵活。它不看你是什么身份，而是看你当前在做什么事。同一个工程师，做 A 项目时拿 100 核，做 B 项目时可能只拿 20 核——因为项目的重要程度和资源需求不同。

我比较推荐的做法是「项目预算制」。每个项目在立项时申请资源预算，审批通过后配额自动生效。项目结束后配额回收，不浪费。这样既避免了资源闲置，也方便财务核算——每个项目花了多少资源，一目了然。

项目分配的关键参数：

参数	说明	推荐值
项目生命周期	配额的有效期，到期自动回收	按项目周期设定，最长不超过 1 年
资源预算	项目可使用的最大资源量	按历史数据 + 业务增长预估
弹性比例	允许超出预算的比例	10%~30%，视资源池富余程度
回收策略	项目结束后资源如何处理	立即回收 / 保留 7 天缓冲期

这里有个实际案例。某互联网公司的 AI 训练平台，最初所有项目共用一个大资源池。结果「双十一大促模型」和「日常推荐模型」抢资源，大促模型经常被挤掉。后来我们改成项目级配额：大促项目预留 60% GPU，日常项目 30%，剩下 10% 作为共享缓冲。从此再没出过问题。

关键经验：项目分配一定要和成本核算挂钩。我习惯在配额审批时同时生成「资源账单」，每周推送给项目负责人。让他们看到「用了多少资源、花了多少钱」，自然就会主动优化资源使用效率。

4.3 基于优先级的抢占策略：关键时刻的保命手段

前面两种策略都是「和平时期」的分配方式。但线上总有突发情况——比如核心业务出故障需要紧急扩容、大促流量突然暴涨、重要模型需要提前上线。这时候就需要优先级抢占策略上场了。

抢占策略的核心思想很简单：低优先级的任务给高优先级的任务让路。但实现起来有很多细节要处理。

我一般把优先级分为三个等级：

Critical（关键）：线上核心业务、SLA 保障任务。抢占时直接驱逐低优任务。
High（高优）：重要但允许短时等待。可以抢占，但需要优雅退出。
Normal（普通）：日常任务、批处理作业。被抢占时自动重试。

在 Kubernetes 中，优先级抢占通过 PriorityClass 实现：

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: critical
value: 1000000
globalDefault: false
description: "核心业务，最高优先级，可抢占任何低优任务"
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high
value: 500000
globalDefault: false
description: "高优任务，可抢占 normal 任务"
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: normal
value: 100000
globalDefault: true
description: "普通任务，被抢占时自动重试"

避坑指南：我曾经遇到过一个问题——优先级设置得太激进，导致低优任务永远跑不完。比如 critical 任务持续占用资源，normal 任务一直被抢占，最后 normal 任务积压了上千个。后来我们加了「最大抢占次数」和「最小运行时间」两个限制：每个任务至少运行 5 分钟才允许被抢占，每个任务最多被抢占 3 次。这样既保证了高优任务的及时性，也给了低优任务存活空间。

抢占策略还需要考虑「连锁反应」。比如你抢占了一个任务，它释放的资源可能被多个高优任务争抢，导致资源碎片化。我建议配合「资源预留」机制：给 critical 任务预留一部分独占资源，剩下的才走抢占逻辑。

4.4 三种策略如何组合使用

实际生产中，很少只用一种策略。我总结了一个「三层漏斗」模型：

第一层（角色分配）：划定大边界。比如「AI 团队最多用 60% 集群资源」。
第二层（项目分配）：在角色边界内细分。比如「AI 团队下的 A 项目用 30%，B 项目用 20%」。
第三层（优先级抢占）：在项目内部动态调整。比如 A 项目的 critical 任务可以抢占同项目的 normal 任务。

这样组合的好处是：既有宏观管控，又有微观弹性。不会因为某个项目突发需求而影响整个团队的资源平衡。

我的习惯：每季度做一次「配额健康度检查」。看看各角色、各项目的配额使用率，低于 50% 的考虑回收，高于 90% 的考虑扩容。同时检查抢占事件日志——如果某个优先级频繁触发抢占，说明配额分配不合理，需要调整。

最后说一句：配额分配不是一锤子买卖。它需要持续观察、持续调整。你不可能一开始就设计出完美的策略，但你可以通过数据驱动的方式，让策略越来越贴近实际需求。