配额机制概述

Resource Quota 是 Kubernetes 中用于管控命名空间资源消耗的核心机制。该机制以 Namespace 为边界进行资源隔离，每个命名空间仅能绑定一个 ResourceQuota 实例。启用配额约束后，若未显式声明资源参数，系统会借助 LimitRange 注入默认值。一旦命名空间内的资源总量触及上限，后续的资源创建请求将被直接拒绝。

启用条件与配置路径

在 API Server 层面，需确保准入控制器链中包含 ResourceQuota 插件。完成该配置后，即可在目标命名空间内部署配额规则对象。

配额维度详解

计算资源

指标项	说明
requests.cpu / limits.cpu	CPU 请求量与上限
requests.memory / limits.memory	内存请求量与上限

存储资源

• requests.storage：存储总容量限制，如 500Gi
• persistentvolumeclaims：PVC 实例数量上限
• <storageclass-name>.storageclass.storage.k8s.io/requests.storage：指定 StorageClass 的容量配额
• <storageclass-name>.storageclass.storage.k8s.io/persistentvolumeclaims：指定 StorageClass 的 PVC 数量配额

对象计数

可限制的对象类型包括：Pod、ReplicationController、ConfigMap、Secret、ResourceQuota、PersistentVolumeClaim、Service（及子类 LoadBalancer、NodePort）等。

LimitRange 默认约束

集群中若未对容器设置资源参数，其 CPU 和内存将处于无限制状态。LimitRange 为命名空间提供最小值、最大值及默认值的兜底策略：

apiVersion: v1
kind: LimitRange
metadata:
  name: default-constraints
spec:
  limits:
  - type: Pod
    max:
      cpu: "2"
      memory: 1Gi
    min:
      cpu: 200m
      memory: 6Mi
  - type: Container
    default:
      cpu: 300m
      memory: 200Mi
    defaultRequest:
      cpu: 200m
      memory: 100Mi
    max:
      cpu: "2"
      memory: 1Gi
    min:
      cpu: 100m
      memory: 3Mi

服务质量等级（QoS）

Kubernetes 依据资源声明方式将 Pod 划分为三个服务质量等级，优先级依次递减。

Guaranteed（有保障）

满足条件：Pod 内所有容器的每种资源均设置了非零的 limit，且 limit 与 request 完全相等。若仅声明 limit 而未声明 request，系统会自动将 request 同步为 limit 值。

# 场景一：显式声明 limit 与 request 且数值一致
containers:
- name: app-frontend
  resources:
    limits:
      cpu: 10m
      memory: 1Gi
    requests:
      cpu: 10m
      memory: 1Gi
- name: app-backend
  resources:
    limits:
      cpu: 100m
      memory: 100Mi
    requests:
      cpu: 100m
      memory: 100Mi

# 场景二：仅声明 limit，request 隐式等同 limit
containers:
- name: cache-node
  resources:
    limits:
      cpu: 500m
      memory: 512Mi

Best-Effort（尽力而为）

满足条件：Pod 内所有容器的所有资源均未设置 request 与 limit。

containers:
- name: debug-shell
  resources: {}
- name: temp-tool
  resources: {}

Burstable（可突发）

不满足 Guaranteed 与 Best-Effort 条件的 Pod 均归入此等级。常见情形包括：部分容器未指定资源、limit 与 request 不匹配、或不同资源类型的声明程度不一致。未指定 limit 时，其实际生效值为所在节点的资源容量。

# 情形一：部分容器缺失资源声明
containers:
- name: web-server
  resources:
    limits:
      cpu: 10m
      memory: 1Gi
    requests:
      cpu: 10m
      memory: 1Gi
- name: sidecar-agent

# 情形二：跨容器资源声明不对称
containers:
- name: data-processor
  resources:
    limits:
      memory: 1Gi
- name: api-gateway
  resources:
    limits:
      cpu: 100m

# 情形三：单容器 request 与 limit 声明不全
containers:
- name: batch-worker
  resources:
    requests:
      cpu: 10m
      memory: 1Gi
- name: helper