📚 课程目录第3章 Kubernetes资源配额（ResourceQuota）原理

3. Kubernetes 资源配额（ResourceQuota）原理：Namespace级别资源限制、CPU/内存/存储的硬限制与软限制

3.1 资源配额的核心作用与层级

ResourceQuota 是 Kubernetes 内置的准入控制机制，用于在 Namespace 级别 对聚合资源消耗进行硬性约束。它解决的是多租户场景下的“资源抢占”问题——防止单个团队或应用无限制地消耗集群 CPU、内存或存储，从而保障其他工作负载的稳定性。

ResourceQuota 与 LimitRange 的区别：

维度	ResourceQuota	LimitRange
作用范围	Namespace 级别聚合	Pod / Container 级别
控制目标	总资源上限（CPU/内存/存储/对象数）	单个容器的 min/max/default
触发时机	创建/更新 Pod 时校验总和	创建/更新 Pod 时注入默认值或校验边界
典型场景	租户隔离、成本控制	容器规格标准化、防止资源浪费

最佳实践：ResourceQuota 与 LimitRange 通常配合使用。LimitRange 为每个容器设置默认 request/limit，ResourceQuota 确保 Namespace 总消耗不超过预算。两者缺一不可。

3.2 硬限制（Hard）与软限制（Soft）

ResourceQuota 支持两种配额类型：

硬限制（Hard）：上限。一旦 Namespace 内资源使用量达到该值，所有新的 Pod 创建请求将被拒绝（返回 403 Forbidden），直到现有资源被释放。
软限制（Soft）：建议性上限。Kubernetes 不会强制拒绝创建，但会记录 ExceededGracePeriod 事件。软限制通常与 spec.scopeSelector 配合，用于灰度迁移或临时突发场景。

属性	硬限制	软限制
YAML 字段	`spec.hard`	`spec.soft`
强制行为	超过即拒绝	超过仅告警
宽限期	无	可配置 `spec.softGracePeriod`
典型用途	生产环境严格预算	开发环境弹性上限

3.3 可配额的资源类型

ResourceQuota 支持三类资源维度的配额：

计算资源：requests.cpu、requests.memory、limits.cpu、limits.memory
存储资源：requests.storage、persistentvolumeclaims、特定 StorageClass 的 requests.storage.<sc-name>
对象计数：pods、services、configmaps、secrets、replicationcontrollers、resourcequotas 等

  关键指标：在生产环境中，requests.cpu 和 requests.memory 是最常用的配额维度。对象计数配额（如 pods、secrets）常被忽略，但却是防止 etcd 过载的重要防线。

3.4 ResourceQuota 工作流程

下图展示了 ResourceQuota 在 Pod 创建时的准入控制流程：

3.5 典型 ResourceQuota 配置示例

以下是一个生产级 ResourceQuota 配置，同时包含硬限制和软限制：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: production-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "20"
    requests.memory: "40Gi"
    limits.cpu: "40"
    limits.memory: "80Gi"
    requests.storage: "500Gi"
    persistentvolumeclaims: "10"
    pods: "50"
    services: "10"
    configmaps: "20"
    secrets: "20"
  soft:
    requests.cpu: "15"
    requests.memory: "30Gi"
  softGracePeriod:
    requests.cpu: "7d"
    requests.memory: "7d"
  scopeSelector:
    matchExpressions:
      - operator: In
        scopeName: PriorityClass
        values:
          - high-priority

注意：软限制的宽限期（softGracePeriod）从资源首次超过软限制开始计时。如果宽限期结束后资源仍未降回软限制以下，Kubernetes 会持续记录 ExceededGracePeriod 事件，但不会自动驱逐 Pod。你需要结合外部监控（如 Prometheus + Alertmanager）来触发告警或自动扩缩容。

3.6 配额作用域（ScopeSelector）

ResourceQuota 支持通过 scopeSelector 将配额规则限定到特定范围的 Pod：

作用域名称	描述	适用场景
`BestEffort`	仅 QoS 为 BestEffort 的 Pod	限制低优先级批处理任务
`NotBestEffort`	排除 BestEffort 的 Pod	保障在线服务的资源预算
`Terminating`	`activeDeadlineSeconds` 被设置的 Pod	限制有超时时间的任务
`NotTerminating`	未设置 `activeDeadlineSeconds` 的 Pod	守护进程集、长期服务
`PriorityClass`	按 PriorityClass 名称匹配	多优先级资源隔离

3.7 配额监控与校准策略

在 GitOps 工作流中，ResourceQuota 的校准需要结合持续监控：

基线采集：使用 kubectl describe quota -n <ns> 或 Prometheus 的 kube_resourcequota 指标采集当前使用率。
利用率分析：关注 Used / Hard 比率。建议告警阈值：80% 警告，95% 临界。
GitOps 更新：将 ResourceQuota YAML 存储在 Git 仓库中，通过 Argo CD / Flux 自动同步。修改配额时走 PR 审批流程。
动态调整：结合 HPA 和 VPA 数据，每两周评估一次配额合理性，避免资源碎片或浪费。

  性能调优要点：ResourceQuota 的校验发生在 API Server 的准入控制阶段，对 etcd 的读压力与 Namespace 内 Pod 数量成正比。当单个 Namespace 的 Pod 数超过 1000 时，建议拆分 Namespace 或使用 scopeSelector 缩小校验范围，避免准入控制成为性能瓶颈。

3.8 常见问题与避坑指南

问题	原因	解决方案
Pod 创建失败，提示 `exceeded quota`	Namespace 资源总和已达 hard 限制	检查 `kubectl describe quota`，释放无用资源或提升配额
配额未生效	ResourceQuota 未创建或未指定正确 Namespace	确认 `kubectl get quota -n <ns>` 存在且状态为 Active
存储配额不准确	PVC 的 storage 请求未计入配额	确保 ResourceQuota 包含 `requests.storage` 和 `persistentvolumeclaims`
软限制未触发告警	未配置 `softGracePeriod` 或监控未订阅事件	配置 Prometheus 告警规则，监听 `kube_resourcequota` 指标

ResourceQuota 是 Kubernetes 多租户资源治理的基石。在 GitOps 实践中，将 ResourceQuota 作为基础设施代码的一部分进行版本管理，配合自动化监控和告警，才能实现真正的“资源配额校准与性能调优”。