想象你住进一栋共享公寓楼：楼上深夜蹦迪，楼下水管爆裂，隔壁装修的电钻声嗡嗡不停——这栋楼还能住得安心吗？分布式集群就是这样一栋楼：不同的团队（租户）共享同一批物理服务器，谁都想多占点 CPU、内存、带宽和磁盘。物业公司（调度器）的职责，就是让每户都住得安稳：先制定“邻里公约”（隔离标准），再给每个房间加装隔音墙（cgroups 隔离）和独立水电表（配额管理）；还要装一个“噪声检测器”盯住深夜蹦迪的住户（噪声租户检测），并在某户临时缺资源时允许借用公共储物间（弹性借用）。本文就用这栋公寓楼的故事，带你理解多租户资源隔离从“为什么需要”到“怎么落地”的完整链路，让抽象的分布式调度概念变得触手可及。

岗位关联

多租户资源隔离是云原生与大数据平台架构师的基本功。掌握它能让你在高并发共享集群中设计出互不干扰的资源方案，在容量规划与故障排查中直击要害，是迈向高阶工程师的关键技术栈。

目录
  1. 可视化演示
  2. 隔离需求背景
  3. 隔离技术基础
  4. 网络存储隔离
  5. 配额管理体系
  6. 噪声租户检测
  7. 弹性借用机制
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示CPU shares权重分配的时间片比例、噪声租户的检测报警，以及空闲租户资源弹性借用与回收机制，可切换三种模式观察。

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

CPU权重分配 cgroups按shares权重分配CPU时间片 权重2048与1024竞争时按2:1分配 时间片 ∝ 权重比例 CPU空闲时忙碌租户可使用全部空闲资源。

隔离需求背景

假设一栋公寓楼里住着四家公司：楼上做直播，楼下跑报表，隔壁训练模型。起初各自安好，直到直播公司发现：报表任务一启动，直播画面就卡顿，弹幕延迟飙到三秒。这不是邻里吵架，而是共享楼宇的物理现实——CPU、内存、网络、磁盘，谁都能抢，谁抢谁快。

在分布式集群里，这个场景叫“多租户共享”：多个团队（租户）的容器与任务被调度到同一批物理节点上。共享降低了硬件成本、提升了资源利用率，但也引入了干扰——一个租户的突发负载会挤压邻居的 CPU 时间片、网络带宽与磁盘 IO 吞吐。更严重的是，失败的隔离会扩大故障域：一个租户的内存泄漏触发 OOM，可能拖垮同节点上的所有服务。

因此隔离的第一个问题不是“怎么隔离”，而是“隔离到什么程度”。工程上常用“慢速比”（Slowdown）度量：测同一任务在独占节点与共享节点上的完成时间之比。比值越大，说明干扰越严重，隔离效果越差。

回到公寓楼故事：物业第一步不是急着砌墙，而是先制定“邻里公约”——明确谁在什么情况下会受影响、影响多大算超标。有了评判标准，才能决定隔音墙砌多厚、水电表怎么分。

Si=Ti共享Ti独占S_i = \frac{T_i^{\text{共享}}}{T_i^{\text{独占}}}
慢速比 S_i 表示租户 i 在共享环境下的性能损失：S=1 代表零干扰，S=2 代表任务耗时翻倍。
  1. 定义 S_i（慢速比）S_i 是租户 i 在共享集群中相对独占环境的性能损失指标，值越大干扰越严重。
    Si=Ti共享Ti独占S_i = \frac{T_i^{\text{共享}}}{T_i^{\text{独占}}}
  2. T_i^{\text{独占}}（独占耗时）节点只有租户 i 一个任务时，作业完成需要的时间，作为无干扰基线。
    Ti独占=孤立运行时的完成时间T_i^{\text{独占}} = \text{孤立运行时的完成时间}
  3. T_i^{\text{共享}}（共享耗时）多租户并发时同一作业的实际完成时间，被抢资源时会明显变大。
    Ti共享=并发运行时的完成时间T_i^{\text{共享}} = \text{并发运行时的完成时间}
  4. 判定阈值当 S_i 超过 1.5 时判定隔离不达标，需要干预；1.5 是业界常用的可接受慢速比。
    是否达标={是Si≤1.5否Si>1.5\text{是否达标} = \begin{cases} \text{是} & S_i \le 1.5 \\ \text{否} & S_i > 1.5 \end{cases}

隔离技术基础

明确了“要隔离到什么程度”，物业开始动工。第一道工序是给每户装隔音墙与独立水电表。Linux 内核恰好提供了现成的“墙”：cgroups 与命名空间（namespace）。cgroups（控制组）能把一组进程圈进一个“房间”，并对这个房间里的 CPU、内存等资源设置上限与权重；命名空间则更进一步，把进程看到的视图隔离——自己的进程列表、网络栈、文件挂载点，都像独享整台机器。

CPU 隔离最常用的参数是 cpu.shares 权重。它不限制绝对核数，而是规定竞争发生时的分配比例：权重 200 的租户拿到的 CPU 时间是权重 100 租户的两倍。内存隔离则用 memory.limit 设定硬上限，超过即触发 OOM 回收或杀死进程。这两者叠加，就构成“房间规则”：cgroups 管用量，namespace 管视野。

隔音墙不是一堵墙，而是一整套“房间规则”：cgroups 管用量上限，namespace 管视野隔离。两者配合，租户们在同一栋楼里各过各的日子，互不窥探、互不侵犯。

Pi=wi∑j=1nwj×CP_i = \frac{w_i}{\displaystyle\sum_{j=1}^{n} w_j} \times C
P_i 是租户 i 在 CPU 争抢时获得的资源量：权重占比越高，分到的 CPU 时间越多，但总和不超节点总资源 C。
  1. w_i（租户权重）cpu.shares 中为租户 i 配置的权重值，代表其在竞争中的“话语权”。
    wi=租户 i 的 cpu.shares 值w_i = \text{租户 i 的 cpu.shares 值}
  2. 权重总和同层所有租户权重之和，作为归一化的分母。
    ∑j=1nwj=w1+w2+⋯+wn\sum_{j=1}^{n} w_j = w_1 + w_2 + \cdots + w_n
  3. 权重占比租户 i 的权重除以总和，得到它应得的份额比例。
    wi∑j=1nwj=租户 i 的份额比例\frac{w_i}{\displaystyle\sum_{j=1}^{n} w_j} = \text{租户 i 的份额比例}
  4. 乘以总资源 C份额比例乘以节点总 CPU 资源，就是租户 i 在竞争时可获得的资源量。
    Pi=份额比例×CP_i = \text{份额比例} \times C

网络存储隔离

墙砌好了，可楼里的水管和宽带是共用的。半夜一户疯狂下载，全楼网速崩盘；一户日志刷屏，大家磁盘 IO 一起遭殃。隔离不仅要管计算侧，还要管网络与存储——否则计算隔离做得再好，公共通道依然能把邻居拖下水。

网络隔离的常见做法是给每个租户设置带宽上限，用令牌桶算法控制流量：令牌按固定速率产生，数据包必须拿到令牌才能发出。存储隔离则限制 IOPS 与吞吐——即使租户突发写日志，也不能占满磁盘队列。GPU、网卡等设备则通过设备插件或份额调度实现独占或按比例共享。

水管虽共用，但每户都装上限流阀，谁也别想独占整栋楼的水压。网络与存储的隔离，保证了公共通道的公平，也补全了隔离的最后一块拼图。

B(t+Δt)=min⁡(B(t)+ρ×Δt,  Bmax⁡)B(t + \Delta t) = \min\left(B(t) + \rho \times \Delta t,\; B_{\max}\right)
令牌桶公式：桶里令牌数 B 随时间按速率 ρ 增长，但最多攒到桶容量 B_max；数据包每发一个就消耗一个令牌，超出速率只能排队。
  1. B(t)（当前令牌数）时刻 t 桶内剩余的令牌数量，代表此刻允许突发流量的额度。
    B(t)=时刻 t 桶内令牌数B(t) = \text{时刻 t 桶内令牌数}
  2. 填充速率 ρ令牌每秒生成的速率，等于该租户被允许的长期平均带宽。
    ρ=带宽上限（字节/秒）\rho = \text{带宽上限（字节/秒）}
  3. 时间增量 Δt两次计算之间的时间差，Δt 越大积累的令牌越多。
    Δt=时间步长\Delta t = \text{时间步长}
  4. 桶容量 B_max令牌桶的最大容量，决定单次突发的最大爆发量，防止无限积攒。
    Bmax⁡=最大突发令牌数B_{\max} = \text{最大突发令牌数}
  5. 取 min 运算令牌数最多填满桶容量，多余的直接丢弃，从而把突发限制在可控范围内。
    min⁡(⋅,  Bmax⁡)=超出部分不累计\min(\cdot,\; B_{\max}) = \text{超出部分不累计}

配额管理体系

有了墙和限流阀，物业还要回答一个更现实的问题：每户到底允许多少资源？这就是配额管理。配额是租户的资源“账本”，决定了它能申请多少、占用多少，也是调度器做决策的依据。

配额分两层：节点级配额约束一台机器上某租户的用量上限，防止单机超卖；命名空间级配额则跨节点汇总——租户在十个节点各用 5 核，汇总后不得超过命名空间的总配额。调度器每次调度都会做配额校验，请求超出剩余配额就排队等待。聪明的集群还会允许“超卖”：租户申请总量之和可以超过物理容量，赌的是大家不会同时用满，超卖比例 η 越高利用率越高，但争抢风险也越大。

配额就像水电表额度：额度以内随便用，超出的部分就要找物业（调度器）审批。报得多不如规划得准——配额体系让“抢资源”变成“按预算花资源”。

Qns=(Cnode−Rreserve)×(1−η)Q_{\text{ns}} = \left(C_{\text{node}} - R_{\text{reserve}}\right) \times \left(1 - \eta\right)
命名空间可分配配额 Q_ns：从节点总资源 C_node 中扣除系统保留 R_reserve 后，再按超卖比例 η 打折，得到安全可承诺的配额。
  1. C_node（节点总资源）单台物理节点上的 CPU 或内存总量，是配额计算的起点。
    Cnode=节点物理资源总量C_{\text{node}} = \text{节点物理资源总量}
  2. R_reserve（系统保留）为操作系统、调度器、监控组件预留的资源，防止系统组件被租户挤死。
    Rreserve=系统组件保留资源R_{\text{reserve}} = \text{系统组件保留资源}
  3. 超卖比例 η允许申请总量超出物理容量的比例，η 越大利用率越高、风险也越大。
    η=超卖比例（如 0.2 表示允许超卖 20%）\eta = \text{超卖比例（如 0.2 表示允许超卖 20\%）}
  4. 乘积得到配额扣除保留后再打折，得到调度器可安全承诺给命名空间的配额上限。
    Qns=(总资源 - 保留)×(1 - 超卖比例)Q_{\text{ns}} = \text{(总资源 - 保留)} \times \text{(1 - 超卖比例)}

噪声租户检测

公约、墙、水表都齐了，可总有些住户半夜蹦迪。更麻烦的是，蹦迪不是天天有——偶尔一次突击加载模型，CPU 瞬间打满。物业需要一个可靠的“噪声检测器”，既不能放过真正的扰民者，也不能冤枉正常住户。

工程上不直接看瞬时指标，因为抖动人人都有一点。做法是用 EWMA（指数加权移动平均）对用量做平滑：近期用量权重高，历史用量慢慢衰减。平滑后的用量超过配额的某个阈值（如 85%）并持续一段时间，才判定为噪声租户。检测到噪声后，处置手段包括：触发配额限流把用量压回、降低调度权重、把部分负载迁移到空闲节点、通知租户整改。目标不是惩罚，而是让所有租户的体验回到公约线以内。

物业的智慧在于“容忍正常生活，打击恶意扰民”：平滑曲线就是那个不偏不倚的裁判，只在真正持续超标时亮红牌。噪声检测不是让住户噤声，而是让所有人都遵守公序良俗。

Ut=α ut+(1−α)Ut−1U_t = \alpha \, u_t + \left(1 - \alpha\right) U_{t-1}
噪声判定：UtQ>θ\text{噪声判定：} \frac{U_t}{Q} > \theta
EWMA 平滑公式：瞬时用量 u_t 乘以权重 α 加上历史平滑值 U_{t-1} 乘以 (1-α)，得到平滑用量 U_t；当它超过配额 Q 的 θ 比例时，判定为噪声。
  1. u_t（瞬时用量）当前采样时刻租户的实际资源使用量，抖动大、噪音多。
    ut=时刻 t 的瞬时资源用量u_t = \text{时刻 t 的瞬时资源用量}
  2. α（平滑系数）取值在 0 到 1 之间，α 越大越敏感、越容易跟随瞬时波动。
    α=平滑系数（常用 0.3）\alpha = \text{平滑系数（常用 0.3）}
  3. U_t（平滑用量）加权平均后的平稳用量，瞬时突刺被历史值“中和”掉。
    Ut=αut+(1−α)Ut−1U_t = \alpha u_t + (1-\alpha) U_{t-1}
  4. 配额 Q 与阈值 θ用平滑用量除以配额，得到配额占用率，超过 θ（如 0.85）才触发。
    UtQ>θ⇒判定为噪声租户\frac{U_t}{Q} > \theta \Rightarrow \text{判定为噪声租户}

弹性借用机制

噪声租户被限流后也会委屈：我只是今晚确实需要更多资源。完全锁死配额太浪费——隔壁明明空着房间。于是物业引入了“公共储物间”：空闲资源池。当租户需求超过基础配额，可以先从空闲池借用余量，把闲置资源用起来。

借用量不是无限：最多取“需求缺口”与“空闲池余量 × 借用比例 r”两者中较小的那个。而且借用是临时行为，不是私有化。回收机制优先保障原配额所有者：一旦持有配额的租户需求回升，或空闲池水位下降，调度器会抢占（preempt）借用的低优先级负载，把资源还给主人——借来的终究要还。

一条完整的公寓楼公约至此闭环：先有隔离标准，再砌隔音墙，装限流阀，分水电配额，装噪声检测器，最后开放公共储物间——有借有还，邻里和谐。资源隔离的终极目标，正是在共享与公平之间找到那条最优的平衡线。

Qeff=Qbase+min⁡(D−Qbase,  F×r)Q_{\text{eff}} = Q_{\text{base}} + \min\left(D - Q_{\text{base}},\; F \times r\right)
有效配额 Q_eff 等于基础配额 Q_base 加上借用量；借用量取需求缺口 D-Q_base 与空闲池余量 F 乘以借用比例 r 中的较小值。
  1. Q_base（基础配额）租户通过配额体系正式申请到的资源量，是隔离承诺的底线。
    Qbase=租户正式配额Q_{\text{base}} = \text{租户正式配额}
  2. D（当前需求）租户此刻实际希望使用的资源量，可能因业务高峰超过基础配额。
    D=租户当前资源需求D = \text{租户当前资源需求}
  3. 需求缺口需求超过配额的部分，就是要通过借用填补的缺口。
    D−Qbase=需求缺口D - Q_{\text{base}} = \text{需求缺口}
  4. F × r（可借上限）空闲池余量 F 乘以借用比例 r，防止某租户一次性掏空公共资源。
    F×r=本次可借用的最大余量F \times r = \text{本次可借用的最大余量}
  5. 取 min 决策实际借用量取缺口与可借上限的较小者，既满足需要又留有安全边际。
    min⁡(D−Qbase,  F×r)=实际借用量\min\left(D - Q_{\text{base}},\; F \times r\right) = \text{实际借用量}

AI 应用场景

Kubernetes 多租户集群隔离运维

阶段：分布式调度与资源管理

解决的问题：多个业务线共享一套 Kubernetes 集群时，一个 namespace 的突发任务会占满节点 CPU 与内存，拖垮在线服务；人工核对配额费时且易漏。利用 ResourceQuota + LimitRange 实现命名空间级配额，配合 NetworkPolicy 做网络隔离，再用 Descheduler 自动疏散资源紧张节点上的 Pod。

具体案例：某互联网公司中间件团队将 Kafka、Redis、日志采集分属三个 namespace，为高峰期的日志采集单独设大配额，平时配额回收进空闲池；双 11 大促前通过弹性借用临时扩容队列资源，值班工程师通过监控面板观察 Quota 使用率，噪声 Pod 被自动限流并告警。

大数据平台 YARN 多队列调度

阶段：分布式计算资源调度

解决的问题：数据团队（ETL、实时计算、模型训练）共享 YARN 集群，训练任务抢占资源导致 ETL 超时。通过 Capacity Scheduler 配置队列容量保证实现隔离，队列间弹性借用提升利用率，配合抢占机制保障核心任务的资源供给。

具体案例：某数据中台将队列按业务线划分，核心 ETL 队列容量 50% 保证，训练队列允许借用空闲容量，但定时作业提交时触发抢占回收；平台工程师配置了噪声任务自动降级策略，降低其 map 并发度，保障核心链路 P99 延迟。

云数据库托管服务防“吵闹邻居”

阶段：多租户存储与计算隔离

解决的问题：云数据库实例共享物理机，一个实例的高 IO 会严重影响同机邻居。通过 cgroup v2 的 io.max 限制实例 IOPS，CPU 配额保证计算隔离；检测到实例持续超配额后自动限流并通知用户升配，形成“检测-限流-告警-升配建议”的自动化链路。

具体案例：某云厂商 RDS 团队用监控曲线识别噪声实例，某客户数据库在促销期间 IO 突发，系统自动将其 IOPS 限流并推送升配建议，周围实例的读写延迟因此保持稳定，避免了大规模投诉。

Python 演示

python66 行
class Tenant:    """一个租户: 拥有基础配额与权重."""     def __init__(self, name, quota, weight):        self.name = name        self.quota = quota        self.weight = weight        self.smooth = 0.0  # EWMA 平滑后的用量        self.debt = 0.0     def update(self, demand, alpha=0.3):        self.smooth = alpha * demand + (1 - alpha) * self.smooth        gap = demand - self.quota        self.debt = gap if gap > 0 else 0.0  class ClusterScheduler:    """调度器: 负责配额分配、噪声检测与弹性借用."""     def __init__(self, node_capacity, reserve_ratio=0.1):        self.capacity = node_capacity        self.reserved = node_capacity * reserve_ratio        self.free_pool = node_capacity - self.reserved        self.tenants = []     def add_tenant(self, tenant):        self.tenants.append(tenant)        self.free_pool -= tenant.quota     def cgroup_share(self, tenant):        total = sum(t.weight for t in self.tenants)        return tenant.weight / total     def noise_detect(self, threshold=0.85):        noisy = []        for t in self.tenants:            if t.smooth / t.quota > threshold:                noisy.append(t.name)        return noisy     def elastic_borrow(self, tenant, demand, ratio=0.5):        gap = demand - tenant.quota        if gap <= 0:            return 0.0        return min(gap, self.free_pool * ratio)  def simulate():    sched = ClusterScheduler(node_capacity=400)    sched.add_tenant(Tenant("tenant-A", quota=80, weight=2))    sched.add_tenant(Tenant("tenant-B", quota=60, weight=1))    sched.add_tenant(Tenant("tenant-C", quota=80, weight=2))     demands = [90, 85, 110, 200, 220, 180, 95, 80]    for step, demand in enumerate(demands):        tenant = sched.tenants[2]        tenant.update(demand)        noisy = sched.noise_detect()        share = sched.cgroup_share(tenant)        borrow = sched.elastic_borrow(tenant, demand) if noisy else 0.0        print("step={} demand={} smooth={:.1f} share={:.2f} noisy={} borrow={:.1f}".format(            step, demand, tenant.smooth, share, noisy, borrow))  if __name__ == "__main__":    simulate()
目的：模拟一个 400 核集群中三个租户的隔离调度，演示 EWMA 噪声检测、cgroup 权重分配与弹性借用如何协同工作。
  1. self.smooth = alpha * demand + (1 - alpha) * self.smooth这是 EWMA 平滑公式的落地实现，用历史值中和瞬时抖动。
  2. if t.smooth / t.quota > threshold噪声判定的核心逻辑：平滑用量与配额的比值超过 0.85 即判定为噪声租户。
  3. return min(gap, self.free_pool * ratio)弹性借用的核心约束：取需求缺口与空闲池余量乘以比例中的较小值。
  4. self.free_pool -= tenant.quota每加入一个租户就扣减空闲池，模拟配额分配后公共余量减少。
  5. total = sum(t.weight for t in self.tenants)计算所有租户权重总和，用于归一化 CPU 份额。

常见误区

误区“我给每个租户都配了 CPU 和内存限额，隔离不就搞定了吗？反正超了会被限制住。”

正解配额只是静态上限。真正的隔离还要看动态行为：突发流量在到达限额之前，已经挤占了共享缓存、带宽与 IO 队列；检测与限流（如 EWMA 平滑 + 阈值触发）决定了多快能把噪声压回去。就像公寓楼装了水表，但如果没装限流阀，水管爆裂前的水压冲击已经影响邻居了。

为何常见：配额是配置里最直观可见的部分，而检测与处置是运行时逻辑，看不见也容易被忽略。

误区“cgroups 已经把 CPU 和内存管住了，网络和磁盘自然也不用担心。”

正解cgroups 的 CPU/内存控制主要管计算侧；网络带宽需要 TC/令牌桶或 CNI 插件，磁盘 IO 需要 blkio/io.max 或存储系统 QoS。每个维度有各自的限流阀，不能指望一堵墙挡住所有噪声。比如一个租户疯狂刷日志填满磁盘队列，cgroups 的 CPU 限额根本拦不住。

为何常见：提到隔离就联想到容器，而容器技术里最显眼的是 cgroups，网络存储的实现藏在更底层，容易被忽视。

误区“某个租户不够用，直接从邻居的配额里抢不就完了？反正大家共享集群。”

正解弹性借用只能借“空闲池”余量——即尚未分配的预留与低峰期闲置，而不是已经在使用的配额。借用还受比例上限约束，并且可被回收：原所有者需求回升时，借用负载会被抢占归还。抢占（preemption）是强制手段，借用是余量调剂，两者本质不同。

为何常见：把抢占与借用混为一谈，忽略了隔离的核心是“互不干扰”——如果允许随便抢，隔离就失去了意义。

误区“每台机器都给租户设了上限，跨节点的总量还管它干嘛？”

正解单节点上限保证的是“局部不超卖”，但租户在 100 个节点各用 5 核，总量可能达 500 核，远超它应得的整体份额。命名空间级配额在调度入口做聚合校验，防止租户总量失控。两者是局部与全局的关系，缺一不可。

为何常见：只看到单机视角，没有建立集群全局的资源账本意识，遇到跨节点资源不均的问题时才追悔莫及。

误区“CPU 一瞬间冲到 90%，这就是噪声租户，赶紧限流！”

正解瞬时尖峰可能只是正常的任务启动、GC 抖动或流量洪峰，直接限流会误伤。需要 EWMA 平滑加上持续超过阈值（如配额 85% 保持若干秒）才判定，用时间换准确性。这就像物业不会因为某户半夜开了 5 分钟音响就报警，而是确认持续扰民才上门。

为何常见：直觉上“尖峰=异常”很自然，但生产环境指标天然抖动，缺乏平滑的阈值判断会把正常波动当病治。

面试题

Q1. 多租户资源隔离最核心的目标是什么？

单选题 · easy

  • A.让租户之间互相无法访问数据
  • B.让租户互不干扰按配额使用资源← 正确答案
  • C.让所有租户获得完全相同的性能
  • D.让单个租户独享集群全部节点

答案：B。隔离的核心是“互不干扰”：每个租户按自己的配额稳定使用资源，突发负载不拖垮邻居。A 是安全隔离的范畴，C 不现实（共享必然有波动），D 违背共享初衷。就像公寓楼的隔音墙是为了各过各的日子，而不是让每户都住独栋。

Q2. Linux cgroups 中 cpu.shares 参数的作用是什么？

单选题 · mid

  • A.规定租户使用的绝对 CPU 核数上限
  • B.在竞争时按权重比例分配 CPU 时间← 正确答案
  • C.限制租户进程的内存使用上限
  • D.隔离租户之间的网络带宽流量

答案：B。cpu.shares 是相对权重而非绝对限制：只有 CPU 争抢时，才按权重比例分配时间片；空闲时允许超额使用。A 错在“绝对”，C 是 memory.limit 的职责，D 是 TC/带宽控制的职责。相当于公寓楼里“谁嗓门大谁先说”的议事规则。

Q3. 命名空间（namespace）隔离主要解决什么问题？

单选题 · mid

  • A.物理 CPU 与内存的资源分配问题
  • B.进程视图与资源可见性的隔离问题← 正确答案
  • C.磁盘 IO 速率的限制与控制问题
  • D.集群节点之间的网络延迟问题

答案：B。命名空间隔离的是“视野”：让租户进程只能看到自己的进程列表、网络栈和挂载点，仿佛独享系统。CPU/内存分配由 cgroups 负责，IO 限速由 blkio 负责，网络延迟则是物理问题。就像每家每户各有各的门牌和窗帘，互不窥探。

Q4. 识别噪声租户的核心依据通常是什么？

单选题 · easy

  • A.租户申请配额时上报的大小
  • B.平滑用量超过配额的一定阈值← 正确答案
  • C.租户代码提交到仓库的频率
  • D.租户任务所在节点的数量

答案：B。噪声判定看“实际用量”而非“申请量”：EWMA 平滑后的用量除以配额，超过阈值（如 85%）且持续一段时间才触发。A 是静态声明，C 与资源无关，D 与干扰无关。物业抓的是“实际扰民”的证据，而不是住户自报的作息表。

Q5. 多租户资源隔离通常覆盖哪些维度？

多选题 · mid

  • A.CPU 与内存的计算资源隔离← 正确答案
  • B.网络带宽与存储 IO 的隔离← 正确答案
  • C.租户之间的安全边界隔离← 正确答案
  • D.租户计费账单之间的隔离

答案：ABC。隔离覆盖计算（CPU/内存）、网络（带宽）、存储（IOPS）与安全边界四个维度；其中安全边界通过命名空间和权限控制实现。D 是财务层面的账户隔离，不属于资源隔离范畴，也不影响性能。

Q6. 关于弹性借用机制，下列说法正确的是哪一项？

单选题 · hard

  • A.借用资源来自其他租户已经占用的配额
  • B.借用仅允许在空闲池余量内进行且可回收← 正确答案
  • C.借用是无条件抢占低优先级租户的资源
  • D.借用后该租户的配额会永久性得到增加

答案：B。弹性借用只能借空闲池余量，且受到比例上限约束，原拥有者需要时可回收。A 错在借的是“空闲”而非“已占用”；C 是把抢占与借用混淆；D 错在借用是临时行为，不改变基础配额。就像借用公共储物间，主人要用时必须归还。

Q7. 关于资源配额管理，以下哪些描述是正确的？

多选题 · mid

  • A.节点级配额只约束单台机器上的用量← 正确答案
  • B.命名空间级配额跨节点汇总后生效← 正确答案
  • C.超卖可以提升集群整体的资源利用率← 正确答案
  • D.配额设得越大自动带来更强的隔离效果

答案：ABC。节点级管局部、命名空间级管全局，两者配合才完整；超卖牺牲部分安全性换取利用率。D 错：配额越大隔离越弱而非越强，隔离强度取决于限制是否有效执行，而不是配额大小。

Q8. 节点资源预留的主要目的是什么？

单选题 · easy

  • A.给系统组件留出安全运行余量← 正确答案
  • B.提高租户可申请的配额上限
  • C.减少租户需要支付的费用成本
  • D.加快任务在节点上的调度速度

答案：A。系统保留资源是为了让操作系统、调度器、监控等组件不被租户挤死，保证集群本身的稳定性。B 与预留背道而驰，C 是计费问题，D 与调度速度无关。就像公寓楼必须留出消防通道和物业用房。

Q9. 检测到噪声租户后，常见的处置手段包括哪些？

多选题 · hard

  • A.触发配额限流将用量压回正常水位← 正确答案
  • B.动态迁移部分负载到其他空闲节点← 正确答案
  • C.永久删除该租户部署的全部应用
  • D.通知租户并限制其突发带宽← 正确答案

答案：ABD。处置目标是恢复公约秩序而非惩罚：限流、迁移、带宽限制、整改通知都是标准手段。C 过于激进，隔离系统不会因为一次噪声就删除用户应用，这违背了多租户共存的设计原则。

Q10. 弹性借用中「归还」动作的典型触发条件是什么？

单选题 · extreme

  • A.借用时长达到固定期限就立即强制回收
  • B.原配额所有者需求回升且空闲池压力上升← 正确答案
  • C.被借用方申请了比当前更高的资源优先级
  • D.集群重启后系统自动重新分配所有配额

答案：B。归还是“按需”而非“定时”：当配额所有者需求回升、或空闲池水位下降时，调度器优先保障原主人，抢占借用负载。A 错在固定期限不灵活；C 中借用方优先级提升反而可能延长借用；D 与归还机制无关。这就像公共储物间的主人回来了，借用的东西就要腾出来。