2. 配额管理核心概念：资源配额、配额类型与配额作用域
在多租户云原生平台中，配额管理是保障资源公平分配、防止单个租户资源滥用、实现故障域隔离的基础机制。本章围绕三个核心维度展开：资源配额（What）、配额类型（How）和配额作用域（Where），为后续配额冲突分析与租户恢复奠定概念基础。
2.1 资源配额：CPU / 内存 / 存储 / 网络
资源配额是对租户可消耗的物理或虚拟资源上限的量化定义。在 Kubernetes 及类似容器编排平台中，最常见的配额维度包括以下四类：
| 资源维度 | 典型单位 | 配额示例 | 说明 |
|---|---|---|---|
| CPU | 核心数（Core）或毫核（m） | requests.cpu: 4, limits.cpu: 8 | 限制租户 Pod 可使用的 CPU 时间片上限 |
| 内存 | 字节（MiB / GiB） | requests.memory: 8Gi, limits.memory: 16Gi | 限制租户 Pod 可使用的物理内存上限 |
| 存储 | 字节（GiB） | requests.storage: 100Gi | 限制租户可声明的持久卷（PVC）总容量 |
| 网络 | 带宽（Mbps）、连接数、IP 数量 | network.bandwidth: 100M, network.ingress: 50M | 限制租户出入流量带宽及并发连接数 |
实践要点：CPU 和内存配额通常区分
requests（调度保证）和 limits（硬上限）。存储配额需注意与 StorageClass 的绑定关系；网络配额在 CNI 插件层面实现，不同实现（Calico / Cilium / OVN）的语义略有差异。
2.2 配额类型：硬配额 / 软配额 / 预留配额
根据配额生效的严格程度和调度行为，配额分为三种类型。理解其差异是设计多租户故障域的关键。
| 配额类型 | 语义 | 超限行为 | 典型场景 |
|---|---|---|---|
| 硬配额（Hard Quota） | 上限，不可突破 | 请求被拒绝（HTTP 403 / Admission Deny） | 生产环境核心资源（CPU/内存） |
| 软配额（Soft Quota） | 建议上限，可临时突破 | 触发告警或驱逐优先级降低，但不立即拒绝 | 开发/测试环境、突发流量容忍 |
| 预留配额（Reserved Quota） | 保证可用容量，其他租户不可抢占 | 预留部分始终可用，超出部分按硬配额处理 | 关键业务租户、SLA 保障场景 |
常见误区：软配额不等于“无限制”。当租户持续超过软配额时，调度器可能触发 Pod 驱逐或 QoS 降级，导致服务不稳定。预留配额需要与集群的“超卖比”配合计算，否则会造成资源浪费。
2.3 配额作用域：Namespace / Node / Cluster 层级
配额作用域定义了配额约束生效的边界范围。在多租户架构中，作用域的选择直接影响故障隔离的粒度。
- Namespace 级作用域：最常用的隔离边界。每个租户对应一个或多个 Namespace，配额在此层级生效。Kubernetes 原生的
ResourceQuota对象即工作在此层级。 - Node 级作用域：限制租户在特定节点或节点组上的资源消耗。常用于“节点独占”或“节点池隔离”场景，配合
nodeSelector或topologyKey实现。 - Cluster 级作用域：全局配额，限制整个集群中某个租户的总资源消耗。通常由上层调度器或配额管理中间件（如 KubeVela、Volcano）实现。
下表对比三种作用域的关键差异：
| 作用域 | 隔离粒度 | 实现方式 | 故障域影响 |
|---|---|---|---|
| Namespace | 逻辑隔离 | ResourceQuota + LimitRange | 单 Namespace 故障不影响其他 Namespace |
| Node | 物理/拓扑隔离 | NodeSelector + 节点级配额控制器 | 节点故障仅影响该节点上的租户 |
| Cluster | 全局聚合 | 外部配额服务（Admission Webhook） | 全局配额耗尽将阻塞所有租户的创建请求 |
架构建议：推荐采用“Namespace 级为主 + Cluster 级兜底”的组合策略。Namespace 级提供细粒度隔离，Cluster 级防止租户跨 Namespace 累积资源超出预期。Node 级作用域仅在需要物理隔离（如 GPU 独占、金融合规）时启用。
2.4 配额冲突的根源：三维交叉
配额冲突往往不是单一维度的问题，而是资源、类型、作用域三个维度交叉作用的结果。以下是一个典型的冲突场景：
场景示例：租户 A 在 Namespace “tenant-a” 中设置了 CPU 硬配额 8 核，同时集群级配额控制器限制了该租户全局 CPU 不超过 10 核。当租户 A 在另一个 Namespace “tenant-a-backup” 中申请 4 核 Pod 时，Namespace 级配额允许（8 核未用满），但集群级配额拒绝（全局已用 8 核 + 新申请 4 核 > 10 核）。这种“作用域嵌套”导致的冲突是故障域恢复中最难排查的问题之一。