📚 课程目录第2章资源配额（ResourceQuota）基础

资源配额（ResourceQuota）概念：Namespace 级别资源限制的原理与 YAML 定义

在 Kubernetes 多租户或团队共享集群的场景中，如果没有资源配额约束，单个 Namespace 中的 Pod 或工作负载可能无限制地消耗集群的 CPU、内存、存储等资源，导致其他 Namespace 的服务因资源争抢而性能下降甚至不可用。ResourceQuota 正是 Kubernetes 提供的 Namespace 级别资源隔离与限制机制，它从性能调优的视角来看，是控制循环中“准入控制”与“资源预算”的关键一环。

ResourceQuota 的核心原理

ResourceQuota 作用于 Namespace 级别，通过 Admission Controller（准入控制器）在资源创建或更新时进行校验。其核心流程如下：

定义配额：管理员在 Namespace 中创建 ResourceQuota 对象，声明该 Namespace 内所有 Pod 可使用的资源上限（如 CPU 总量、内存总量、PVC 数量等）。
准入校验：当用户在该 Namespace 中创建 Pod、Service、PVC 等资源时，Kubernetes API Server 的准入控制器会检查当前 Namespace 的已使用资源量 + 新请求资源量是否超过配额。
拒绝或允许：如果超出配额，API Server 会直接拒绝该请求并返回错误；如果未超出，则允许创建并更新该 Namespace 的资源使用计数。
资源使用量跟踪：Kubernetes 通过 ResourceQuota 控制器持续跟踪每个 Namespace 的资源实际使用量，并更新 ResourceQuota 的 Status 字段，供调度器和用户查询。

性能调优提示： ResourceQuota 的校验发生在 API Server 的准入阶段，不会影响运行时的 Pod 性能。但合理设置配额可以避免因资源争抢导致的 Pod 驱逐或节点过载，从而间接提升控制循环的稳定性。

ResourceQuota 的 YAML 定义详解

ResourceQuota 的 YAML 定义主要包含 spec.hard 字段，用于声明资源上限。以下是一个典型的 ResourceQuota 示例：

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"
    requests.nvidia.com/gpu: "1"
    persistentvolumeclaims: "10"
    pods: "20"
    configmaps: "30"
    services: "10"
    secrets: "20"

资源配额的关键字段分类

分类	字段示例	说明	性能调优关注点
计算资源	`requests.cpu`, `limits.memory`	限制 Pod 的 CPU 和内存请求/限制总和	避免 CPU 过度订阅导致节点 CPU 饥饿；防止内存超限触发 OOM
扩展资源	`requests.nvidia.com/gpu`	限制 GPU、FPGA 等特殊硬件资源	确保 GPU 等稀缺资源不被单个 Namespace 独占
存储资源	`requests.storage`, `persistentvolumeclaims`	限制 PVC 数量和存储容量总和	防止存储卷数量过多导致 etcd 压力增大
对象数量	`pods`, `services`, `configmaps`, `secrets`	限制 Namespace 内各类 Kubernetes 对象的数量	控制 API Server 和 etcd 的存储压力，避免对象数量膨胀

ResourceQuota 的 Scope 与优先级

ResourceQuota 支持通过 spec.scopes 字段对特定状态的 Pod 进行更精细的配额控制。常见的 Scope 包括：

BestEffort：仅限制 QoS 为 BestEffort 的 Pod（未设置 requests 和 limits）。
NotBestEffort：限制 QoS 不是 BestEffort 的 Pod（即 Burstable 或 Guaranteed）。
Terminating：限制设置了 activeDeadlineSeconds 的 Pod。
NotTerminating：限制未设置 activeDeadlineSeconds 的 Pod。

  性能调优实践： 在 Operator 控制循环中，如果 Operator 创建的 Pod 属于 Guaranteed QoS（设置了与 limits 相等的 requests），建议使用 NotBestEffort Scope 单独分配配额，避免与 BestEffort 的测试 Pod 争抢资源预算。

ResourceQuota 的 Status 与监控

创建 ResourceQuota 后，可以通过 kubectl describe resourcequota 查看当前使用量：

Name:            compute-quota
Namespace:       team-a
Resource         Used     Hard
--------         ----     ----
requests.cpu     2.5      4
requests.memory  5Gi      8Gi
limits.cpu       4.5      8
limits.memory    10Gi     16Gi
pods             12       20
persistentvolumeclaims  3  10

在 Operator 控制循环中，可以通过 Kubernetes API 动态读取 ResourceQuota 的 Status，实现资源预算感知的调度逻辑：

// 伪代码示例：在 Operator 中检查当前 Namespace 的 CPU 配额余量
quota, err := clientset.CoreV1().ResourceQuotas(namespace).Get(ctx, "compute-quota", metav1.GetOptions{})
if err != nil {
    // 处理错误
}
usedCPU := quota.Status.Used["requests.cpu"]
hardCPU := quota.Status.Hard["requests.cpu"]
// 如果余量不足，则暂停创建新的 Pod 或选择其他 Namespace
if usedCPU.Value() >= hardCPU.Value() {
    // 触发回退逻辑
}

注意： ResourceQuota 的 Status 更新存在短暂延迟（通常几秒内）。在 Operator 控制循环中，如果连续快速创建大量 Pod，可能会出现“配额余量判断通过但实际创建时被拒绝”的情况。建议在 Operator 中实现重试机制或使用 Informer 监听 ResourceQuota 的更新事件。

性能调优视角下的 ResourceQuota 设计建议

合理设置 requests 与 limits 比例：避免将 limits.cpu 设置得过大而 requests.cpu 过小，导致 CPU 过度订阅引发节点性能抖动。
为关键 Operator 预留配额：如果 Operator 负责管理核心业务 Pod，建议在 Namespace 中单独创建 ResourceQuota 并预留 20%-30% 的余量，避免因其他工作负载突发导致 Operator 无法创建必要的 Pod。
监控配额使用率：通过 Prometheus 采集 ResourceQuota 的 kube_resourcequota 指标，设置告警规则（如使用率超过 80%），提前扩容或调整配额。
避免对象数量配额过小：pods、services 等对象数量配额设置过小会频繁触发拒绝，增加 API Server 的无效请求负载。建议根据实际业务规模设置，并预留 50% 的缓冲。