4. 资源配额基础：ResourceQuota对象、LimitRange对象、配额作用域与优先级

在准入控制链路中，资源配额是影响OPA策略评估延迟的关键前置因素。Kubernetes通过ResourceQuota和LimitRange两个核心API对象实现多租户资源管控，而配额作用域与优先级机制则决定了配额生效的粒度与顺序。理解这些基础组件，是分析OPA延迟瓶颈的前提。

4.1 ResourceQuota对象：命名空间级资源硬约束

ResourceQuota作用于整个命名空间，聚合所有Pod、PVC等对象的资源请求与限制，一旦超出配额则拒绝创建。其核心字段分为三类：

以下是一个典型的ResourceQuota YAML定义：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    count/deployments.apps: "10"
    count/services: "5"

4.2 LimitRange对象：Pod/容器级别的默认值与边界

LimitRange为命名空间内的每个Pod或容器设置资源默认值（default）与最小/最大值（min/max），在Pod创建时由准入控制器自动注入。其作用域比ResourceQuota更细，直接影响单个工作负载的资源声明。

4.3 配额作用域：精细化控制配额生效范围

ResourceQuota支持通过scopes字段限定配额仅对特定状态的资源生效，避免全局配额过于粗放。常见作用域包括：

• Terminating：仅统计activeDeadlineSeconds已设置的Pod（通常为Job类工作负载）。
• NotTerminating：仅统计未设置activeDeadlineSeconds的Pod（如Deployment）。
• BestEffort：仅统计QoS为BestEffort的Pod（无资源请求与限制）。
• NotBestEffort：仅统计QoS为Burstable或Guaranteed的Pod。
• PriorityClass：通过scopeSelector匹配特定优先级类。

作用域组合使用可实现多层级配额隔离，例如：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: batch-quota
spec:
  hard:
    requests.cpu: "2"
    requests.memory: 4Gi
  scopes:
    - Terminating
    - NotBestEffort

上述配额仅对设置了activeDeadlineSeconds且非BestEffort的Pod生效。

4.4 优先级与配额优先级类

Kubernetes 1.18+ 引入配额优先级类（PriorityClass）机制，允许ResourceQuota通过scopeSelector匹配特定优先级，实现按优先级隔离资源池。优先级类本身通过scheduling.k8s.io/v1 API定义，其value字段决定调度顺序，而配额系统利用该值进行统计分组。

优先级对配额的影响体现在两个层面：

1. 调度优先级：高优先级Pod在资源竞争时优先被调度，但配额仍受命名空间总量限制。
2. 配额优先级：通过scopeSelector的operator: In匹配多个优先级类，实现不同优先级Pod的配额隔离。

以下展示优先级类与配额作用域的组合配置：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: high-priority-quota
spec:
  hard:
    requests.cpu: "2"
    requests.memory: 4Gi
  scopeSelector:
    matchExpressions:
      - operator: In
        scopeName: PriorityClass
        values: ["high", "critical"]

4.5 配额评估顺序与OPA延迟影响

在准入控制链路中，资源配额相关对象的评估顺序直接影响OPA策略的输入数据量与评估复杂度：