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

3. 资源配额模型概述：CPU、内存、连接数、请求速率（RPS）等核心配额指标

云原生网关的资源配额模型是流量治理与成本控制的基础。在 Kubernetes 生态中，网关实例（如 Envoy、Kong、APISIX）的资源配置直接决定了其处理能力与稳定性。本章将系统梳理 CPU、内存、连接数、请求速率（RPS）等核心配额指标的定义、度量方式及配置漂移的审计切入点。

3.1 核心配额指标分类与定义

资源配额指标可划分为 计算资源类 与 流量资源类 两大维度。计算资源类直接关联 Pod 的调度与运行稳定性；流量资源类则反映网关对请求的处理上限。下表列出了各指标的核心属性：

指标类别	指标名称	单位	典型配置位置	漂移风险等级
计算资源	CPU 限制	m（毫核）	Deployment / HPA	高
计算资源	内存限制	Mi / Gi	Deployment / LimitRange	高
流量资源	最大连接数	个	网关配置 / 上游集群	中
	请求速率（RPS）	req/s	Rate Limiter / 流量策略	高
	并发请求数	个	连接池 / 熔断配置	中

审计提示： CPU 与内存的配置漂移往往由 HPA 策略变更、资源超卖或手动调整引发；RPS 与连接数的漂移则多源于限流规则误删除、阈值修改或上游服务拓扑变化。审计时应优先关注这两类指标的基线偏离度。

3.2 计算资源配额：CPU 与内存

在云原生网关中，CPU 与内存的配额通常以 requests 和 limits 的形式定义在 Pod 规范中。CPU 是可压缩资源，超限会导致限流（throttling）；内存是不可压缩资源，超限会触发 OOM Kill。配置漂移的典型场景包括：

requests 与 limits 比例失调： 例如 requests 设置过高导致调度失败，或 limits 设置过低导致频繁限流。
HPA 目标阈值变更： 自动扩缩容策略的 CPU 目标利用率被修改，间接影响实际资源配额。
Namespace 级别 ResourceQuota 覆盖： 全局配额限制导致网关 Pod 的 requests 被强制截断。

# 典型网关 Deployment 资源配额片段
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-gateway
spec:
  template:
    spec:
      containers:
      - name: envoy
        resources:
          requests:
            cpu: "500m"      # 基线值
            memory: "512Mi"  # 基线值
          limits:
            cpu: "1000m"
            memory: "1Gi"

漂移审计要点： 对比 Git 仓库中的基线 YAML 与运行时实际生效的资源配置。使用 kubectl get pod -o yaml 提取实际值，与 CI/CD 流水线中的版本进行差异比对。任何非预期的 requests/limits 变更都应视为配置漂移事件。

3.3 流量资源配额：连接数与请求速率（RPS）

连接数与 RPS 是网关处理能力的直接体现。连接数配额通常作用于上游集群的连接池（Connection Pool），RPS 则通过全局或路由级别的限流器实现。这两类指标的配置漂移往往比计算资源更隐蔽，因为其配置可能分散在多个 CRD 或配置文件中。

指标	常见配置源	漂移检测方法	影响范围
最大连接数	Envoy Cluster / 上游 Service	对比连接池配置的 max_connections 字段	单上游集群
请求速率（RPS）	RateLimit CRD / 插件配置	审计限流规则的 unit 与 requests_per_unit	全局或路由级别
并发请求数	熔断器 / 连接池	检查 max_pending_requests 与 max_requests	单上游集群

以下是一个基于 Envoy 的限流配置示例，展示了 RPS 与连接数的典型定义方式：

# Envoy 限流配置片段
rate_limits:
  - actions:
    - generic_key:
        descriptor_value: "api-v1"
    limit:
      requests_per_unit: 1000   # 每秒 1000 请求
      unit: SECOND

# 连接池配置
circuit_breakers:
  thresholds:
    - priority: DEFAULT
      max_connections: 500      # 最大连接数
      max_pending_requests: 100
      max_requests: 200

3.4 配额指标间的关联与依赖

各配额指标并非孤立存在，它们之间存在强耦合关系。例如，RPS 的提升会直接推高 CPU 使用率，进而触发 HPA 扩容；连接数的增加会消耗更多内存，可能导致 OOM。理解这种关联性有助于审计时定位漂移的根因。

典型关联链路：

RPS 从 1000 突增到 3000 → CPU 利用率从 40% 升至 85% → HPA 触发扩容 → 新 Pod 启动 → 内存总量增加 → 若内存限制未同步调整，可能触发 OOM。
连接数从 200 升至 800 → 连接池耗尽 → 新请求被拒绝 → 客户端重试 → 进一步增加连接数 → 雪崩效应。

下图展示了核心配额指标之间的依赖关系与配置漂移的传播路径：

3.5 配置漂移的审计基线建立

要有效检测配额模型的配置漂移，必须建立明确的审计基线。基线应包含以下三个层次：

期望值基线： 从 Git 仓库中提取的 YAML 或 CRD 定义，作为配置的“黄金版本”。
运行时基线： 通过 Prometheus 或 Kubernetes API 采集的实时配置快照，反映实际生效值。
阈值基线： 允许的偏差范围（例如 CPU limits 偏差不超过 10%），超出范围即视为漂移事件。

审计命令示例：

# 提取运行时 CPU limits 并与 Git 基线对比
kubectl get pod -l app=api-gateway -o jsonpath='{.items[*].spec.containers[*].resources.limits.cpu}'
# 输出示例: "1000m 1000m 2000m"  → 发现第三个 Pod 的 limits 已漂移

通过上述指标体系的建立与基线对齐，审计人员可以系统性地识别云原生网关资源配额模型中的配置漂移，为后续的自动化修复与策略加固奠定基础。