📚 课程目录第3章资源配额模型概述

3. 资源配额模型概述：配额模型的分层思想

资源配额模型是策略即代码在云原生基础设施治理中的核心实践。其核心思想是将资源配额的管理从“单一平面”拆解为基础设施层、平台层和应用层三个相互独立又彼此关联的层次。每一层关注不同的抽象粒度、控制对象和策略语义，通过分层解耦实现配额策略的复用性、可审计性和自动化。

设计原则：分层配额模型遵循“关注点分离”原则。基础设施层管“硬边界”，平台层管“租户隔离”，应用层管“业务弹性”。三层之间通过标准化的策略接口进行数据传递，避免跨层耦合。

3.1 分层模型总览

下表从控制粒度、策略载体、典型对象和变更频率四个维度，对比三个层次的核心差异：

维度	基础设施层	平台层	应用层
控制粒度	物理/虚拟资源（CPU、内存、存储、网络带宽）	命名空间、项目、租户、服务网格	工作负载、容器组、微服务实例
策略载体	云服务商 IAM 策略、OpenStack 配额、Kubernetes Node 资源预留	OPA/Gatekeeper 约束模板、Kyverno 集群策略	Kubernetes ResourceQuota、LimitRange、自定义准入 Webhook
典型对象	计算节点、存储卷、网络接口、IP 地址池	命名空间、服务账户、RBAC 角色、Ingress 网关	Deployment、StatefulSet、Pod、ConfigMap
变更频率	低（月度/季度规划）	中（按项目生命周期）	高（持续交付/弹性伸缩）

3.2 基础设施层：硬边界与容量规划

基础设施层位于模型最底部，直接对应物理或虚拟化资源池。该层的配额策略通常由基础设施运维团队定义，目的是防止单一租户或工作负载耗尽集群的底层容量。策略以“上限”形式存在，一旦超出则直接拒绝资源分配请求。

资源类型：CPU 核心数、内存总量、持久化存储容量、网络出/入带宽、GPU 卡数。
策略示例：“每个计算节点最多分配 32 个 vCPU 和 128 GiB 内存”、“单租户存储配额上限 10 TiB”。
实现工具：OpenStack 的 Quota 管理、AWS Service Quotas、Kubernetes Node Allocatable 配置。

  关键约束：基础设施层的配额策略一旦生效，平台层和应用层无法绕过。例如，若基础设施层限制某节点组最多 64 GiB 内存，平台层即使配置了更大的命名空间配额，实际调度也会被基础设施层截断。

3.3 平台层：租户隔离与策略抽象

平台层在基础设施层之上引入逻辑边界，将物理资源池划分为多个隔离的租户空间。该层的配额策略由平台工程团队或SRE 团队管理，通过策略即代码引擎（如 OPA/Gatekeeper）统一执行。平台层策略通常包含“软限制”和“硬限制”两种模式：软限制触发告警，硬限制强制拒绝。

资源类型：命名空间数量、服务账户数量、Ingress 规则数、ConfigMap 大小、集群角色绑定数。
策略示例：“每个项目命名空间最多创建 50 个 Pod”、“生产环境命名空间必须启用 Pod 安全策略”。
实现工具：OPA Gatekeeper 约束模板、Kyverno 集群策略、Kubernetes 准入控制器。

常见陷阱：平台层策略容易与基础设施层策略产生冲突。例如，平台层允许某命名空间申请 100 个 Pod，但基础设施层节点组仅能容纳 80 个 Pod 的资源总量。此时应优先遵循基础设施层的硬边界，并在平台层策略中增加“节点容量校验”规则。

3.4 应用层：工作负载级弹性控制

应用层位于模型最上层，直接面向开发团队和应用运维。该层的配额策略关注单个工作负载或微服务实例的资源使用行为，包括请求量、限制量、突发上限和优先级。应用层策略通常以 Kubernetes 原生 ResourceQuota 和 LimitRange 为载体，结合自定义准入 Webhook 实现更精细的控制。

资源类型：Pod 的 CPU request/limit、内存 request/limit、临时存储、GPU 请求、容器重启次数。
策略示例：“所有 Pod 的 CPU limit 不得超过 request 的 2 倍”、“内存 request 不得低于 256 MiB”、“无状态工作负载必须设置 Pod 中断预算”。
实现工具：Kubernetes ResourceQuota、LimitRange、Vertical Pod Autoscaler、自定义准入 Webhook。

3.5 分层协作关系

三层模型并非孤立运行，而是通过策略继承和冲突优先级机制协同工作。下图展示了配额策略在三个层次之间的数据流与决策顺序：

3.6 分层策略的代码化表达

在策略即代码实践中，每一层的配额策略都通过声明式语言（如 Rego、CUE、JSON Schema）定义。以下示例展示三层策略在 OPA Gatekeeper 中的简化表达：

# 基础设施层策略：节点 CPU 总量限制
package infra.node_cpu_limit
violation[{"msg": msg}] {
  sum(input.spec.node.resources.cpu) > 32
  msg := "节点 CPU 总量不得超过 32 核心"
}

# 平台层策略：命名空间 Pod 数量限制
package platform.namespace_pod_limit
violation[{"msg": msg}] {
  count(input.review.object.spec.pods) > 50
  msg := "单命名空间 Pod 数量不得超过 50"
}

# 应用层策略：Pod 内存 request 下限
package app.pod_mem_min
violation[{"msg": msg}] {
  input.review.object.spec.containers[_].resources.requests.memory < "256Mi"
  msg := "每个容器内存 request 不得低于 256Mi"
}

  分层执行顺序：在 Kubernetes 准入控制链中，基础设施层策略通常作为 MutatingWebhook 最先执行，平台层策略作为 ValidatingWebhook 中间执行，应用层策略最后执行。这种顺序确保硬边界优先于软约束。

3.7 分层模型的优势与适用场景

采用三层配额模型设计，相比单层扁平化策略，具有以下显著优势：

职责分离：基础设施团队、平台团队、应用团队各自管理所属层的策略，互不干扰。
策略复用：平台层策略可被多个应用共享，基础设施层策略可被多个平台共享。
故障隔离：某一层的策略变更错误不会直接导致其他层的配额失控。
审计清晰：每层策略的变更日志和生效范围明确，便于合规审计。