假设你是一栋大型员工公寓的物业管家，洗衣房、健身房、充电桩都由园区统一供应。每个部门领到一张电子饭卡，卡上写着这个月最多能刷多少洗衣币、多少充电时长、多少加班晚餐。资源配额就是这张饭卡背后的会计系统：它不关心你具体住哪个房间，只关心“整个园区的资源够不够分、公不公平”。Slurm 像提前包桌的团餐柜台，K8s 像流水线自助取餐；配额在两边分别体现为账号树上的消费上限和命名空间里的 ResourceQuota。只要把配额管好，既不会让某部门刷爆卡，也不会让资源闲置发霉。

岗位关联

学会资源配额，你就拿到了在共享集群里既不让租户“饿肚子”也不让算力“被浪费”的治理钥匙，这是云平台调度工程师的基本功。

目录
  1. 可视化演示
  2. 配额总览：一张饭卡定边界
  3. Slurm账户：包桌的分层饭卡
  4. Slurm约束：限菜、公平与拦截
  5. K8s配额：命名空间的令牌盒
  6. 超额管控：透支、抢占与重启
  7. 动态调整：给饭卡自动加菜
  8. 效率平衡：SLA与利用率的跷跷板
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示Slurm QoS公平调度max-min分配、K8s命名空间配额软硬限制及GPU共享三种模式，支持模式切换。

本节配有交互动效（进入视口后自动加载，约 3KB）。

QoS公平调度 按优先级max-min公平分配 需求超配时按份额均分 alloc_i=min(dem_i, R/n) 高优先级QoS先满足需求再均分剩余

配额总览：一张饭卡定边界

园区食堂一到饭点就排长队。行政部给每个部门发了一张电子饭卡，A 部门这个月最多打 100 份饭，B 部门最多打 50 份。这个额度不是存款，而是消费上限：厨师会按上限备料，但如果你不在饭点来，没有人为你保留专属座位。资源配额就是这个逻辑在算力集群里的延续。

在 Slurm 和 K8s 组成的算力集群里，“饭卡额度”就是 CPU 核时、GPU 卡时、内存等资源的上限。Slurm 通过账户与 QoS 限制作业占用，K8s 通过命名空间里的 ResourceQuota 限制 Pod 请求。配额让多个租户共享同一批物理机，谁也不能独占算力，谁也不会被邻居悄悄饿死。

用一个简洁的公式表示余额变化：

饭卡让食堂不敢多刷，也让食堂不必盲目多备菜。配额真正解决的不是“怎么炒菜”，而是“每个部门能点多少菜”的边界问题。

Bi(t)=Qi−∑j∈Pirj(t)B_i(t) = Q_i - \sum_{j \in \mathcal{P}_i} r_j(t)
公式说：租户 i 的剩余配额 = 配额上限 - 当前所有作业/容器请求的资源之和。余额一旦变负，新任务就会被拒绝或排队等待。
  1. 租户配额 Q_i管理员给租户 i 设置的消费上限，比如 32 颗 GPU。
    QiQ_i
  2. 在跑任务集合 P_i该租户当前正在运行或占用了资源额度的作业集合。
    Pi\mathcal{P}_i
  3. 单任务请求 r_j(t)作业 j 在时刻 t 申请的 CPU、GPU 或内存大小。
    rj(t)r_j(t)
  4. 剩余配额 B_i(t)实时余额。如果小于 0，说明这个租户已经被“限额”拦住。
    Bi(t)=Qi−∑j∈Pirj(t)B_i(t) = Q_i - \sum_{j \in \mathcal{P}_i} r_j(t)

Slurm账户：包桌的分层饭卡

公司团建去食堂包桌，总负责人拿到一张大饭卡，再分给各个事业部，事业部又分给项目组。Slurm 的账户树就是这个“包桌分卡”的结构：最上面是 root 账户，下面挂部门账户，再往下挂用户。用户必须绑定某个账户和 QoS，这条绑定关系叫 association。

账户树的每一层都可以设置限制。总公司规定一桌最多点 30 道菜，部门规定最多点 20 道，个人规定最多点 5 道，QoS 又说最多 15 道。真正能点的菜数不是哪一个说了算，而是所有限制里最紧的那一个。

包桌一层层分饭卡，最后每个人能吃的菜，取决于那条最紧的红线。这就是 Slurm 账户树的核心治理哲学：分层授权，层层收紧。

Leff=min⁡(LRoot,LAcct,LUser,LQOS)L_{\text{eff}} = \min \left( L_{\text{Root}}, L_{\text{Acct}}, L_{\text{User}}, L_{\text{QOS}} \right)
公式说：Slurm 的层级限制像多层安检，任何一个环节卡住，最终生效限制就取最小值。
  1. Root 级限制 L_Root集群管理员对整个账户树设置的全局天花板。
    LRootL_{\text{Root}}
  2. 部门账户限制 L_Acct某个账户下所有任务加起来不能超过的上限。
    LAcctL_{\text{Acct}}
  3. 用户关联限制 L_User单个用户或单个 association 能用的最大资源。
    LUserL_{\text{User}}
  4. QoS 限制 L_QOS服务质量等级上附加的 MaxTRES、GrpTRES 等配额。
    LQOSL_{\text{QOS}}
  5. 有效限制 L_eff取四者的最小值，任务实际能用的资源不会越过这条线。
    Leff=min⁡(LRoot,LAcct,LUser,LQOS)L_{\text{eff}} = \min \left( L_{\text{Root}}, L_{\text{Acct}}, L_{\text{User}}, L_{\text{QOS}} \right)

Slurm约束：限菜、公平与拦截

有了账户树还不够，还得给每张卡写清楚“点菜规则”。Slurm 里常用的约束有三类：MaxTRES 限制单个作业能申请的硬件资源；GrpTRES 限制整个组内所有作业加起来的资源总和；Fairshare 则决定排队时谁先被照顾。

Fairshare 很像食堂里“按过往食量排序”的公平规则。今天你吃多了，明天你的优先级就低一些；别人一直没吃饱，系统会多给他机会。为了看懂公平度，可以把它写成归一化用量：

当作业的请求超过 MaxTRES 或 GrpTRES 时，Slurm 会在提交阶段直接拒绝，连排队的机会都不给。这就是“提交拦截”：饭卡余额不足，点菜系统直接报错，而不是让你先坐下再被赶走。

FSi=Ui/wi∑j=1nUj/wjFS_i = \frac{U_i / w_i}{\sum_{j=1}^{n} U_j / w_j}
公式说：租户 i 的公平度 = 自身单位权重使用量 ÷ 所有租户单位权重使用量之和。FS 大于 1 表示用超了，优先级会被压低。
  1. 实际用量 U_i租户 i 累计消耗的 CPU 核时或 GPU 卡时。
    UiU_i
  2. 权重 w_i管理员给租户设定的重要程度或购买份额。
    wiw_i
  3. 单位权重用量 U_i/w_i把用量除以权重，用于公平比较。
    Uiwi\frac{U_i}{w_i}
  4. 归一化公平度 FS_i如果 FS_i 远超 1，说明该租户正在透支历史“信用额度”。
    FSi=Ui/wi∑j=1nUj/wjFS_i = \frac{U_i / w_i}{\sum_{j=1}^{n} U_j / w_j}

K8s配额：命名空间的令牌盒

K8s 把集群看成一个个自助餐档口，每个档口叫 namespace。管理员在每个命名空间里放一个 ResourceQuota，就像在档口门口放一只令牌盒，规定这个档口最多消耗多少 CPU、内存、GPU。

ResourceQuota 并不是按“实际吃进去”扣钱，而是按“点单时声明的 request 和 limit”扣钱。一个 Pod 写 requests: cpu: 2，就相当于在令牌盒里先取走 2 个 CPU 令牌；limits: memory: 4Gi，就取走 4GB 内存限量令牌。LimitRange 还会给没有写 request 或 limit 的 Pod 补默认值，防止有人钻空子。

自助餐档口不会等客人吃完了才说话，而是点单时就看令牌够不够。K8s 的准入控制器在 Pod 创建前检查 ResourceQuota，超了就拒绝创建，从源头保护命名空间的公平。

∑p∈nsreq(p)≤Qreq,∑p∈nslim(p)≤Qlim\sum_{p \in \text{ns}} \mathit{req}(p) \le Q^{\text{req}}, \qquad\sum_{p \in \text{ns}} \mathit{lim}(p) \le Q^{\text{lim}}
公式说：命名空间内所有 Pod 的 request 总和不能超过 ResourceQuota 的 request 配额；所有 Pod 的 limit 总和也不能超过 limit 配额。
  1. 请求向量 req(p)Pod p 声明的 CPU/内存/GPU 请求量，相当于占座令牌。
    req(p)\mathit{req}(p)
  2. 限制向量 lim(p)Pod p 声明的资源上限，相当于“最多能吃到多少”。
    lim(p)\mathit{lim}(p)
  3. 请求配额 Q_reqResourceQuota 里的 requests.cpu、requests.memory 字段。
    QreqQ^{\text{req}}
  4. 限制配额 Q_limResourceQuota 里的 limits.cpu、limits.memory 字段。
    QlimQ^{\text{lim}}

超额管控：透支、抢占与重启

食堂偶尔也会“超卖”：饭卡总额度比实际备料多 20%，因为不是每个部门天天都来吃饭。算力集群也一样，配额超卖能提高利用率，但也意味着真正抢起来时，必须有人让座。

Slurm 和 K8s 都准备了抢占机制。Slurm 里高优先级 QOS 的作业可以挤掉低优先级作业；K8s 里 PriorityClass 决定 Pod 的排队顺序，高优先级 Pod 可以驱逐低优先级 Pod。抢占不是“乱抢”，它需要比较优先级和 QoS 等级，牺牲低价值任务，保护高价值任务。

超卖就像飞机多卖了几张票：如果没有人实际升级舱位，大家相安无事；一旦高优先级乘客出现，系统只能请低优先级乘客改签。配额管理不是反对超卖，而是让超卖永远有“赔偿预案”。

O=∑i=1nQiCclusterO = \frac{\sum_{i=1}^n Q_i}{C_{\text{cluster}}}
公式说：集群超卖率 = 所有租户配额总和 ÷ 集群可分配总容量。O 大于 1 表示超额订阅，这时必须靠优先级抢占来兜底。
  1. 租户配额之和把所有命名空间或账户的配额加起来。
    ∑i=1nQi\sum_{i=1}^n Q_i
  2. 集群可分配容量 C_cluster物理资源扣除系统预留后真正能分给用户的总量。
    CclusterC_{\text{cluster}}
  3. 超卖率 OO 越接近 1 越安全，O 大于 1 时风险上升，需要抢占机制配合。
    O=∑i=1nQiCclusterO = \frac{\sum_{i=1}^n Q_i}{C_{\text{cluster}}}

动态调整：给饭卡自动加菜

静态额度有一个问题：某部门这周项目冲刺，饭卡不够用；另一个部门休假，饭卡大量闲置。人工改配额太慢，所以现代平台会用闭环控制动态调整配额。

策略很简单：周期性采样租户的利用率，和理想目标比较。利用率长期高于目标，就适度加配额；利用率长期低于目标，就回收一部分额度交给别人。调节幅度和差额成正比，同时用最小值和最大值把饭卡额度钳制在安全区间。

动态调整像食堂经理每晚看剩菜率：剩太多就少备菜，排队太长就临时加窗口。配额不再是写在纸上一百年不变的规矩，而是跟着真实需求呼吸的治理工具。

Qt+1=clamp⁡(Qt+Kp⋅(Utarget−Uobserved), Qmin⁡, Qmax⁡)Q_{t+1} = \operatorname{clamp}\left(Q_t + K_p \cdot \left(U_{\text{target}} - U_{\text{observed}}\right),\, Q_{\min},\, Q_{\max}\right)
公式说：新配额 = 旧配额 + 调节系数 × 目标利用率与当前利用率的差额，最后夹在最小配额和最大配额之间。
  1. 当前配额 Q_t本轮开始前租户的饭卡余额上限。
    QtQ_t
  2. 比例系数 K_p调节力度，K_p 越大，配额变化越激进。
    KpK_p
  3. 差额 U_target - U_observed目标利用率减去实际利用率，正数表示该加菜，负数表示该减菜。
    Utarget−UobservedU_{\text{target}} - U_{\text{observed}}
  4. 钳制函数 clamp把结果限制在 Q_min 和 Q_max 之间，防止波动失控。
    clamp⁡(⋅,Qmin⁡,Qmax⁡)\operatorname{clamp}\left(\cdot, Q_{\min}, Q_{\max}\right)

效率平衡：SLA与利用率的跷跷板

配额管理的终极目标不是“限额”，而是让整个园区又公平又高效。完全卡死配额，租户的 SLA 稳了，但集群空闲资源会发霉；完全放开配额，利用率可能冲上去，但重要任务会被邻居挤垮。

因此平台会用一个加权满意度目标来指导配额决策。每个租户的满意度 = 实际用量 ÷ 配额，超过 1 按 1 算，再用权重汇总；同时所有租户配额之和不能超过集群容量加超卖上限。规划每一轮动态调整时，系统本质是在解这个平衡问题。

最好的食堂经理不是把饭卡卡得最死的人，而是让每个部门都刚好吃饱、又让后厨不浪费食材的人。资源配额治理，就是在 SLA 与利用率之间不停校准的那架天平。

---

Φ=∑i=1nwi⋅min⁡(UiQi, 1),∑i=1nQi≤C+Olim⁡\Phi = \sum_{i=1}^n w_i \cdot \min\left(\frac{U_i}{Q_i},\, 1\right), \quad\sum_{i=1}^n Q_i \le C + O_{\lim}
公式说：加权满意度 Φ 越高越好，但配额总和必须受容量和超卖上限约束。SLA 保护和资源利用率的跷跷板，最终被收进这一条公式。
  1. 满足度 U_i/Q_i当用量等于配额时达到满分，超过配额也按 1 计算，避免“过度贪婪”得高分。
    UiQi\frac{U_i}{Q_i}
  2. 取最小值运算把满足度封顶在 1，代表 SLA 已满足，不需要继续逼迫系统多给资源。
    min⁡(UiQi, 1)\min\left(\frac{U_i}{Q_i},\, 1\right)
  3. 租户权重 w_i不同租户的优先级不同，权重越大，满意度对总分的贡献越大。
    wiw_i
  4. 总配额约束所有租户配额之和不能超过物理容量加上允许的超卖上限。
    ∑i=1nQi≤C+Olim⁡\sum_{i=1}^n Q_i \le C + O_{\lim}

AI 应用场景

云厂商 AI 训练平台的租户配额治理

阶段：资源调度与多租户治理

解决的问题：多个算法团队共享 GPU 池时，重要训练任务总被批量推理任务挤占。传统做法只靠口头协调，出了问题互相扯皮。引入 K8s ResourceQuota 后，每个团队在 namespace 下都有明确的上限；再配合 PriorityClass，高优训练 Pod 能驱逐低优推理 Pod，保障核心业务 SLA。

具体案例：某云厂商的 AI 中台团队为 12 个内部团队设置 CPU/GPU 配额，月度考核里记录“配额使用率”和“被抢占次数”。动态调整模块根据近 7 天利用率自动把闲置组的 30% 额度临时借给冲刺团队，训练等待耗时下降 40%。

高校超算中心的 Slurm 账户树配额

阶段：HPC 作业调度与公平分配

解决的问题：高校超算中心有多个实验室，有的实验室长期占满 GPU，导致新用户排队时间数周。靠人工管理无法说服各方。用 Slurm 账户树把每个实验室挂成独立 account，设置 GrpTRES 和 Fairshare，作业提交时自动拦截超额请求，排队优先级按历史用量动态调整。

具体案例：某高校为 5 个学院建设账户树，每个学院下设多个导师子账户。管理员用 sacctmgr 设置每账户最多 200 个 CPU 核、20 块 GPU，Fairshare 权重按基金项目规模分配。运行一个学期后，最长排队时间从 14 天降到 3 天。

智算中心配额成本核算

阶段：成本计量与容量规划

解决的问题：智算中心采购 GPU 成本高，财务希望知道每个业务线到底用了多少算力。配额本身就是天然的成本计量单位：谁占了多少配额，谁就该承担多少成本。

具体案例：某智算中心把 ResourceQuota 和 Slurm 记账数据统一汇总，生成“每租户 GPU 卡时消耗报表”。动态调整配额后，空闲份额被回收，采购预算减少 20%，同时内部结算变得更透明。

Python 演示

python46 行
class QuotaLedger:    def __init__(self, total_capacity):        self.total_capacity = total_capacity        self.used = {}        self.quota = {}        self.priority = {}     def set_quota(self, tenant, amount, priority=0):        self.quota[tenant] = amount        self.priority[tenant] = priority        self.used.setdefault(tenant, 0)     def report_usage(self, tenant, amount):        self.used[tenant] = amount        return True     def remaining(self, tenant):        return self.quota.get(tenant, 0) - self.used.get(tenant, 0)     def overcommit_ratio(self):        return sum(self.quota.values()) / max(self.total_capacity, 1)     def blocked_requests(self):        return [t for t in self.quota if self.remaining(t) < 0]     def dynamic_adjust(self, tenant, target_ratio=0.8, kp=2, min_quota=1):        old_q = self.quota[tenant]        current_used = self.used.get(tenant, 0)        target = target_ratio * old_q        new_q = old_q + kp * (target - current_used)        new_q = max(min_quota, min(new_q, self.total_capacity))        self.quota[tenant] = new_q        return new_q if __name__ == '__main__':    ledger = QuotaLedger(total_capacity=100)    ledger.set_quota('group_a', 30, priority=1)    ledger.set_quota('group_b', 30, priority=2)    ledger.set_quota('group_c', 50, priority=3)    ledger.report_usage('group_a', 28)    ledger.report_usage('group_b', 32)    ledger.report_usage('group_c', 45)    print('remaining:', ledger.remaining('group_a'))    print('blocked:', ledger.blocked_requests())    print('overcommit:', ledger.overcommit_ratio())    print('adjust_a:', ledger.dynamic_adjust('group_a'))
目的：用最小模型演示多租户配额的余额计算、超卖率统计和基于利用率的动态调整。
  1. ledger.set_quota('group_a', 30, priority=1)给租户 group_a 设置 30 单位配额，并附带优先级。
  2. ledger.report_usage('group_a', 28)模拟该租户当前已使用 28 单位资源。
  3. def remaining(self, tenant):返回剩余配额 = 配额 - 已使用。
  4. def blocked_requests(self):找出所有剩余配额为负、提交新任务会被拒的租户。
  5. def overcommit_ratio(self):计算所有配额之和与总容量的比值，反映超卖风险。
  6. target = target_ratio * old_q把 80% 利用率当作调节目标。
  7. new_q = old_q + kp * (target - current_used)按差额成比例调整配额。
  8. new_q = max(min_quota, min(new_q, self.total_capacity))给新配额加上下限，防止失控。

常见误区

误区我给自己设了 32 核配额，就代表我一提交任务立刻能拿到 32 核；配额越大，性能越有保障。

正解配额只是“消费上限”，不是“专属座位”。饭卡有 100 元额度，不代表食堂必须为你留一整桌菜。K8s 的 ResourceQuota 只管准入，Slurm 的 GrpTRES 只管总量，真正的时间保障还要靠更高优先级、预留节点或单独 QoS。

为何常见：“quota”这个英文词容易让人联想到“留出一份”，而忽略了它本质是会计上限。

误区为了避免租户投诉任务失败，直接给每个团队设一个很大的配额，大家都开心。

正解配额全部放大会破坏公平。一个团队突发高负载时，可能把集群容量全部占满，其他团队连小任务都排不进去。配额治理的目标是“按需要、按权重分配”，不是“人人无限额度”。

为何常见：管理者只看到当下被拒绝的任务，看不到未来被饿死的其他租户，所以容易开闸放水。

误区既然都是“配额”，学会了 K8s 的 ResourceQuota，Slurm 也能照搬。

正解Slurm 是用账户树、association、QoS 和 GrpTRES 做分层限额，强调 CPU 核时、GPU 卡时等批处理作业的累计消耗；K8s 是用 namespace 里的 ResourceQuota 和 LimitRange 管理在线容器的 request/limit。两者 API、作用域和触发时机都不同，只是治理思想相似。

为何常见：初学调度时容易抽象成一个词“配额”，忽略了不同调度器的实现差别。

误区只要每个命名空间配置了 ResourceQuota，集群就永远不会被压垮。

正解ResourceQuota 只是在创建 Pod 时检查声明的请求量，并不能阻止运行时某个 Pod 把节点内存打爆。真正的稳定性还要靠 cgroup 限制、节点压力驱逐、PodPriority 抢占和监控告警协同完成。

为何常见：人们把“准入控制”误解成“实时保护”，不理解配额只是治理链条的第一环。

误区动态调整就是定时把配额调大，使用率就会自然上升。

正解如果业务根本不需要那么多资源，加配额只会让超卖率上升，不会让利用率上升。动态调整需要结合历史趋势、任务队列长度、优先级和物理容量，并且设置上下限，才能既照顾 SLA 又不浪费资源。

为何常见：看到“动态”两个字，误以为系统会自动产生资源，而忽略了资源总量仍然是物理有限的事实。

面试题

Q1. 在 Kubernetes 中，ResourceQuota 的作用范围是什么？

单选题 · easy

  • A.命名空间← 正确答案
  • B.单个节点
  • C.单个 Pod
  • D.整个集群

答案：A。ResourceQuota 是 namespace 级别的对象，用来限制整个命名空间内所有 Pod 的资源申请总量。节点和 Pod 不是它的作用域，集群级别的限制通常由总容量或策略引擎负责。

Q2. Slurm 账户树中，多层级配额同时存在时，最终生效限制通常怎么确定？

单选题 · mid

  • A.取最大值
  • B.取最小限制← 正确答案
  • C.所有限制相加
  • D.由用户自行选择

答案：B。Slurm 的层级限制像多层安检，任何一层卡住都不能通过。Root、账户、用户和 QoS 四个限制同时存在时，有效限制取最小值，保证最严格的那条红线“一票否决”。

Q3. 某租户配额 Q=100，当前已使用 U=120，那么剩余配额 B 是多少？

单选题 · easy

  • A.220
  • B.20
  • C.-20← 正确答案
  • D.0

答案：C。剩余配额 = 配额 - 已使用 = 100 - 120 = -20。负数表示该租户已经透支，新的资源请求会被配额系统拒绝或排队等待。

Q4. 以下哪些机制可以用来处理配额超卖带来的资源竞争？

多选题 · mid

  • A.优先级抢占← 正确答案
  • B.QoS 等级区分← 正确答案
  • C.无差别拒绝所有任务
  • D.Fairshare 公平调度← 正确答案

答案：ABD。超卖后需要区分“谁更重要”。K8s 用 PriorityClass 抢占，Slurm 用 QoS 和 Fairshare 调整排队优先级。无差别拒绝所有任务会破坏 SLA，不是正确做法。

Q5. Kubernetes 的 ResourceQuota 在何时检查资源是否超限？

单选题 · mid

  • A.Pod 被调度到节点时
  • B.Pod 创建请求到达 API Server 时← 正确答案
  • C.Pod 容器实际使用内存超限时
  • D.节点发生故障时

答案：B。ResourceQuota 由准入控制器在 Pod 创建/更新时拦截检查，而不是调度时或运行时。实际运行超限要靠 cgroup 和驱逐机制处理。

Q6. 动态调整配额公式为 Q_{t+1} = Q_t + K_p * (U_target - U_observed)。当前 Q_t=10，U_target=8，U_observed=9，K_p=2，那么新配额是多少？

单选题 · hard

  • A.8← 正确答案
  • B.9
  • C.10
  • D.12

答案：A。差额 = 8 - 9 = -1，K_p * 差额 = -2，新配额 = 10 - 2 = 8。观测利用率高于目标时，系统会适当回收配额，避免资源闲置。

Q7. Slurm 的 Fairshare 机制主要用于解决什么问题？

单选题 · mid

  • A.为租户预留物理节点
  • B.根据历史用量调整作业调度优先级← 正确答案
  • C.限制文件系统存储空间
  • D.自动扩容 GPU 数量

答案：B。Fairshare 根据租户历史用量与权重的比值调整调度优先级。用超了的租户优先级下降，用得少的租户更容易得到资源，从而实现长期公平。

Q8. 关于 Slurm 账户树配额和 K8s ResourceQuota，下列说法正确的是？

多选题 · hard

  • A.两者都用于限制租户资源使用← 正确答案
  • B.两者的 API 和作用域不同← 正确答案
  • C.两者都能直接预留物理资源
  • D.两者都可以与优先级抢占配合← 正确答案

答案：ABD。Slurm 用账户树和 QoS，K8s 用 namespace 与 ResourceQuota，都是限制手段但 API 和作用域不同。它们都只是“上限”，不直接预留物理资源；超卖后的竞争仍需抢占机制兜底。

Q9. 在 K8s 中，如果命名空间内所有 Pod 的 request 总和超过 ResourceQuota，新建 Pod 会发生什么？

单选题 · easy

  • A.正常创建并在节点排队
  • B.被 API Server 准入控制拒绝← 正确答案
  • C.自动删除某个旧 Pod
  • D.配额自动增加

答案：B。ResourceQuota 是硬限制，请求超限时准入控制器直接拒绝创建 Pod。它不会自动删除旧 Pod，也不会自动扩容配额。

Q10. 哪些措施有助于实现“既保障 SLA 又提高集群利用率”的配额治理目标？

多选题 · mid

  • A.对配额使用率做周期性监控← 正确答案
  • B.超卖配额并配置抢占机制← 正确答案
  • C.永远不设配额上限
  • D.根据利用率动态调整配额← 正确答案

答案：ABD。监控能看清真实需求，超卖加抢占能提高吞吐，动态调整能避免配额僵化。永远不设上限会破坏公平性，不是可持续的治理方案。