4、资源配额（ResourceQuota）原理与配置

ResourceQuota 是 Kubernetes 内置的准入控制机制，用于限制命名空间（Namespace）级别的聚合资源消耗。在集群升级场景中，资源配额的校准直接关系到升级后工作负载的调度成功率与稳定性。若配额设置过紧，升级过程中新 Pod 可能因资源不足无法启动；若设置过松，则可能引发资源争抢，导致关键组件性能下降。

4.1 ResourceQuota 对象详解

ResourceQuota 是一个作用于 Namespace 的 API 对象，通过准入控制器 ResourceQuota 在 Pod 创建或更新时进行校验。其核心数据结构包含 spec.hard（硬限制）和 spec.scopes（作用域）两个关键字段。

4.2 作用域（Scopes）详解

作用域允许管理员针对不同 QoS 类或生命周期状态的 Pod 设置差异化的配额。在升级过程中，合理使用作用域可以避免突发性驱逐或临时 Pod 占用过多资源。

4.3 硬限制与软限制

ResourceQuota 支持两种限制模式：硬限制（Hard）和软限制（Soft）。硬限制是强制性的准入控制边界，一旦超过则拒绝创建新资源；软限制则用于监控和告警，不阻断资源创建。

4.3.1 硬限制（Hard Limit）

硬限制是 ResourceQuota 的默认行为。当 Namespace 内资源使用量达到 spec.hard 中定义的上限时，Kubernetes API Server 会拒绝任何导致超额的资源创建请求，并返回 403 Forbidden 错误。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: production
spec:
  hard:
    requests.cpu: "20"
    requests.memory: "40Gi"
    limits.cpu: "40"
    limits.memory: "80Gi"
    persistentvolumeclaims: "10"
    services: "20"

4.3.2 软限制（Soft Limit）

软限制通过 spec.scopeSelector 中的 matchExpressions 实现，配合 status.used 的监控数据触发告警。Kubernetes 本身不提供内置的软限制告警机制，通常需要结合 Prometheus + Alertmanager 实现。

groups:
- name: resourcequota-soft-limit
  rules:
  - alert: ResourceQuotaSoftLimit
    expr: |
      kube_resourcequota{type="used"}
      / ignoring(type)
      kube_resourcequota{type="hard"}
      > 0.8
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Namespace {{ $labels.namespace }} 资源使用率超过 80%"

4.4 跨 Namespace 的配额管理

在大型集群中，单一 Namespace 的配额管理往往不足以应对复杂的多团队、多环境场景。跨 Namespace 的配额管理通常通过以下三种模式实现：

1. 层级配额（Hierarchical Quota）：借助 kubectl-配额 插件或自定义控制器，在父 Namespace 设置总配额，子 Namespace 继承并分配子配额。
2. 配额池（Quota Pool）：通过 Admission Webhook 动态调整 ResourceQuota，实现 Namespace 间的配额借用与回收。
3. 全局配额聚合监控：使用 Prometheus 聚合所有 Namespace 的 kube_resourcequota 指标，实现跨 Namespace 的资源使用视图。

4.5 升级场景中的配额校准策略

在集群升级前，建议执行以下配额校准步骤：

1. 基线采集：使用 kubectl get resourcequota -A -o json 导出所有 Namespace 的当前配额与使用量。
2. 使用率分析：计算每个 Namespace 的 status.used / status.hard 比率，标记使用率超过 80% 的 Namespace。
3. 缓冲预留：对使用率超过 70% 的 Namespace，将硬限制提升 20%~30%，确保升级期间有足够的资源用于 Pod 重建。
4. 作用域拆分：将 BestEffort 和 NotTerminating 作用域的配额分离，避免临时 Pod 影响常驻服务。
5. 验证生效：通过 kubectl describe resourcequota -n <namespace> 确认配额更新已生效。