3、ResourceQuota 对象详解：命名空间级别的资源总量控制机制

ResourceQuota 是 Kubernetes 中用于在命名空间（Namespace）级别实施资源总量控制的 API 对象。它定义了整个命名空间内所有 Pod、容器、持久卷声明等对象可以消耗的资源上限，防止单个命名空间无限制地占用集群资源，从而保障多租户环境下的资源公平性和集群稳定性。

3.1 ResourceQuota 的核心作用

与 LimitRange（作用于单个 Pod/容器）不同，ResourceQuota 作用于聚合层面。其主要目标包括：

• 总量硬限制：限制命名空间内所有 Pod 的 CPU/内存请求（Requests）和限制（Limits）总和。
• 对象数量限制：限制命名空间内可创建的 Pod、Service、ConfigMap、PVC 等对象的数量。
• 存储资源限制：限制命名空间内所有 PVC 的存储请求总量。
• 服务质量保障：防止“吵闹邻居”现象，确保关键业务命名空间获得足够的资源配额。

3.2 ResourceQuota 的资源类型与作用域

ResourceQuota 支持对以下三类资源进行配额限制：

3.3 ResourceQuota 的工作机制与调度影响

当 ResourceQuota 被创建并生效后，Kubernetes 的准入控制器（Admission Controller）会在每次创建或更新 Pod 时进行配额校验。如果当前命名空间内的资源使用量加上新 Pod 的请求量超过了配额上限，API Server 将拒绝该请求，并返回 403 Forbidden 错误。

这种机制对调度亲和性调整有直接影响：

• 调度前校验：即使调度器（Scheduler）找到了一个满足节点资源的节点，如果命名空间配额不足，Pod 依然无法创建。
• 亲和性策略失效场景：当节点亲和性或 Pod 间亲和性将大量 Pod 调度到同一命名空间时，可能迅速耗尽该命名空间的 ResourceQuota，导致后续 Pod 无法调度。
• 资源碎片化：不合理的配额设置可能导致命名空间内 CPU 配额充足但内存配额耗尽，造成资源碎片。

3.4 ResourceQuota 的 YAML 定义与示例

以下是一个典型的 ResourceQuota 配置示例，它限制了命名空间 production 的资源总量：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: production-quota
  namespace: production
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"
    pods: "50"
    services: "10"
    configmaps: "20"
    persistentvolumeclaims: "10"
    requests.storage: "100Gi"
    ssd.storageclass.storage.k8s.io/requests.storage: "50Gi"
    hdd.storageclass.storage.k8s.io/requests.storage: "50Gi"

3.5 配额监控与状态查看

创建 ResourceQuota 后，可以通过以下命令查看当前命名空间的资源使用情况和配额上限：

# 查看所有 ResourceQuota
kubectl get resourcequota -n production

# 查看详细配额和使用量
kubectl describe resourcequota production-quota -n production

describe 命令的输出会显示类似以下内容：

Name:            production-quota
Namespace:       production
Resource         Used  Hard
--------         ----  ----
requests.cpu     5     10
requests.memory  10Gi  20Gi
limits.cpu       12    20
limits.memory    25Gi  40Gi
pods             30    50
services         5     10
configmaps       8     20

3.6 ResourceQuota 与调度亲和性的联动分析

在调度亲和性调整场景中，ResourceQuota 的冲突通常表现为以下模式：

• 亲和性聚合效应：Pod 间亲和性将多个 Pod 调度到同一命名空间，导致该命名空间配额迅速耗尽，而其他命名空间仍有大量空闲配额。
• 节点资源 vs 配额资源：调度器优先考虑节点资源（CPU/Memory），但即使节点资源充足，如果命名空间配额不足，Pod 依然无法运行。这会造成“节点空闲但 Pod 无法调度”的假象。
• 解决方案：在调整亲和性策略时，必须同步评估命名空间的 ResourceQuota 余量，必要时通过 kubectl describe quota 实时监控配额使用率，并考虑动态调整配额或拆分命名空间。