📚 课程目录第4章配额管理概念

4、配额管理概念：Kubernetes资源配额（ResourceQuota）、LimitRange机制、自定义配额模型

在 Kubernetes 集群中，配额管理是保障多租户稳定性与资源公平性的核心手段。本章将系统讲解原生 ResourceQuota、LimitRange 的工作原理，并引出面向 eBPF 校准场景的自定义配额模型，为后续 Kyverno 策略与 eBPF 数据联动奠定基础。

4.1 Kubernetes ResourceQuota 机制

ResourceQuota 是命名空间级别的资源约束对象，用于限制该命名空间内所有 Pod 的资源总和上限。它主要管控两类资源：计算资源（CPU、内存）与对象数量（Pod、Service、PVC 等）。

资源类型	示例配置	作用范围
CPU 总量	`limits.cpu: "16"`	所有容器 CPU limit 之和
内存总量	`limits.memory: "32Gi"`	所有容器 memory limit 之和
Pod 数量	`count/pods: "100"`	命名空间内 Pod 总数
PVC 数量	`count/persistentvolumeclaims: "50"`	命名空间内 PVC 总数

  关键行为：ResourceQuota 仅限制已创建资源的累计值，不干预单个 Pod 的资源配置。当创建新 Pod 导致配额超限时，API Server 会直接拒绝请求。

4.2 LimitRange 机制

LimitRange 弥补了 ResourceQuota 无法约束单个容器的缺陷。它在命名空间级别设置默认值、最小值与最大值，确保每个 Pod 或容器都落在合理区间内。

默认值（default）：当容器未显式设置资源 request/limit 时，自动注入。
最小/最大值（min/max）：强制校验容器资源声明是否越界。
比例约束（maxLimitRequestRatio）：限制 limit/request 比值，防止过度超卖。

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-limit-range
  namespace: default
spec:
  limits:
  - max:
      memory: 2Gi
    min:
      memory: 128Mi
    default:
      memory: 512Mi
    defaultRequest:
      memory: 256Mi
    type: Container

实践建议：在启用 ResourceQuota 的命名空间中，务必同时配置 LimitRange，否则未设置 request/limit 的 Pod 可能因无法通过配额校验而被拒绝。

4.3 原生配额的局限性

ResourceQuota 与 LimitRange 在静态资源管控场景下表现良好，但在 eBPF 校准场景中暴露出以下不足：

局限性	说明	对 eBPF 校准的影响
仅感知静态声明	只校验 Pod 创建时的资源声明，不追踪运行时实际使用量	无法发现内存泄漏或突发超用
无动态调整能力	配额变更需要重新创建 ResourceQuota 对象	无法根据 eBPF 采集的实时数据自动校准
粒度粗	最小作用域为命名空间，无法精细到 Pod 或容器级别	难以定位具体违规 Pod
无自定义指标支持	只能管控 Kubernetes 原生资源类型	无法约束 eBPF 监控的 fd 数量、网络带宽等指标

4.4 自定义配额模型设计

为满足 eBPF 配额校准需求，我们设计了一套三层自定义配额模型，将原生配额扩展为可感知运行时、可动态调整、可扩展指标维度的体系。

4.5 自定义配额模型核心组件

该模型在原生配额之上引入三个新组件，实现从静态到动态的跨越：

组件	职责	数据来源	更新频率
RuntimeQuota	定义运行时资源上限（如最大 fd 数、最大内存驻留量）	eBPF 采集器 + Prometheus	每 10 秒
QuotaCalibrator	对比实际用量与配额阈值，生成校准事件	eBPF 数据流	事件驱动
KyvernoPolicyHook	接收校准事件，执行准入控制或变更操作	Kyverno Webhook	实时

4.6 自定义配额 YAML 示例

以下是一个扩展后的自定义配额资源定义，融合了原生与运行时指标：

apiVersion: quota.ebpf-calibrator.io/v1
kind: RuntimeQuota
metadata:
  name: runtime-quota-high-priority
  namespace: production
spec:
  native:
    cpu: "8"
    memory: "16Gi"
    pods: 50
  runtime:
    maxFileDescriptors: 65535
    maxMemoryRSS: "12Gi"
    maxNetworkIngress: "500Mbps"
    maxSyscallRate: 10000
  action:
    onViolation: "ScaleDown"   # 可选：ScaleDown / Kill / Alert
    cooldownSeconds: 300

注意：自定义配额模型需要配合 Kyverno 的 mutate 和 validate 策略才能生效。在后续章节中，我们将详细实现 eBPF 数据到 Kyverno 策略的通信管道。

4.7 配额校准流程总览

结合上述模型，eBPF 配额校准的完整流程可概括为以下步骤：

静态准入：Pod 创建时，ResourceQuota + LimitRange 执行第一道校验。
运行时采集：eBPF 程序持续采集 Pod 级别的实际资源使用数据。
阈值比对：QuotaCalibrator 将实时数据与 RuntimeQuota 定义的上限对比。
事件触发：超出阈值时，生成校准事件并发送至 Kyverno。
策略执行：Kyverno 根据预定义策略执行补丁、驱逐或告警操作。

关键设计原则：自定义配额模型不替代原生配额，而是在其之上叠加运行时感知能力。原生配额负责“能不能创建”，自定义配额负责“能不能继续运行”。