4. 资源配额管理：ResourceQuota 对象详解
ResourceQuota 是 Kubernetes 内置的准入控制机制，用于限制命名空间（Namespace）级别的资源消耗总量。当多个团队或项目共享同一个集群时，ResourceQuota 可以防止某个 Namespace 过度占用集群资源，保障整体稳定性。本章将深入解析 ResourceQuota 的工作原理、配置方法及常见瓶颈。
4.1 ResourceQuota 核心概念
ResourceQuota 通过准入控制器 ResourceQuota 在 API 请求阶段拦截并校验资源创建/更新操作。如果操作会导致 Namespace 的资源总量超出配额，请求将被拒绝并返回错误。
关键特性：
- 作用范围： 仅作用于单个 Namespace，无法跨 Namespace 限制。
- 资源类型： 支持计算资源（CPU、内存）、存储资源（PVC 容量、存储类）、对象数量（Pod、Service、ConfigMap 等）。
- 生效时机： 在资源创建或更新时实时校验，不追溯历史资源。
- 默认行为： 未设置 ResourceQuota 的 Namespace 不受限制。
4.2 ResourceQuota 配置详解
ResourceQuota 使用 YAML 清单定义，支持三类资源限制：计算资源、存储资源 和 对象数量。以下是一个完整的配置示例：
apiVersion: v1
kind: ResourceQuota
metadata:
name: team-a-quota
namespace: team-a
spec:
hard:
# 计算资源
requests.cpu: "10"
requests.memory: "20Gi"
limits.cpu: "20"
limits.memory: "40Gi"
# 存储资源
requests.storage: "100Gi"
persistentvolumeclaims: "10"
# 对象数量
pods: "50"
services: "10"
configmaps: "20"
secrets: "20"
replicationcontrollers: "10"
resourcequotas: "1"
最佳实践： 始终同时设置
requests 和 limits 配额。仅设置 limits 可能导致 Pod 因 requests 过高而被拒绝，反之亦然。
4.3 资源配额类型对照表
| 资源类别 | 配额字段 | 说明 | 示例值 |
|---|---|---|---|
| 计算资源 | requests.cpu |
所有 Pod CPU 请求总和上限 | 10（核） |
requests.memory |
所有 Pod 内存请求总和上限 | 20Gi | |
limits.cpu |
所有 Pod CPU 限制总和上限 | 20（核） | |
limits.memory |
所有 Pod 内存限制总和上限 | 40Gi | |
| 存储资源 | requests.storage |
所有 PVC 存储请求总和上限 | 100Gi |
persistentvolumeclaims |
PVC 对象数量上限 | 10 | |
| 对象数量 | pods |
Pod 对象数量上限 | 50 |
services |
Service 对象数量上限 | 10 | |
configmaps |
ConfigMap 对象数量上限 | 20 | |
secrets |
Secret 对象数量上限 | 20 | |
replicationcontrollers |
ReplicationController 对象数量上限 | 10 | |
resourcequotas |
ResourceQuota 对象数量上限 | 1 |
4.4 配额作用域与优先级
ResourceQuota 支持通过 scopes 字段限定配额生效的 Pod 状态，实现更精细的控制：
- Terminating： 作用于
spec.activeDeadlineSeconds >= 0的 Pod（通常为 Job 或批处理任务）。 - NotTerminating： 作用于
spec.activeDeadlineSeconds为 nil 的 Pod（常驻服务）。 - BestEffort： 作用于 QoS 为 BestEffort 的 Pod（未设置 requests/limits）。
- NotBestEffort： 作用于 QoS 不为 BestEffort 的 Pod（设置了 requests/limits）。
常见陷阱： 如果同时创建多个 ResourceQuota 对象作用于同一个 Namespace，Kubernetes 会应用所有配额中最严格的限制。例如，一个配额限制 Pod 数量为 10，另一个限制为 20，则实际生效的是 10。
4.5 配额监控与瓶颈分析
ResourceQuota 的瓶颈通常表现为 资源碎片化 和 配额耗尽。以下命令用于诊断配额状态：
# 查看 Namespace 配额使用情况
kubectl get resourcequota -n team-a -o yaml
# 查看配额使用详情（包含当前使用量）
kubectl describe resourcequota team-a-quota -n team-a
# 输出示例：
# Name: team-a-quota
# Namespace: team-a
# Resource Used Hard
# -------- --- ---
# requests.cpu 8 10
# requests.memory 15Gi 20Gi
# limits.cpu 16 20
# limits.memory 32Gi 40Gi
# pods 45 504.6 配额冲突与解决方案
在实际运维中，ResourceQuota 可能引发以下冲突：
| 冲突场景 | 错误信息 | 解决方案 |
|---|---|---|
| Pod 未设置 requests/limits | failed quota: must specify limits.cpu |
为 Pod 添加资源请求和限制，或使用 LimitRange 设置默认值 |
| 配额耗尽 | exceeded quota: team-a-quota, requested: pods=1, used: pods=50, limited: pods=50 |
清理闲置资源，或申请增加配额 |
| 多个配额冲突 | quota: team-a-quota, team-b-quota |
删除冗余配额，确保每个 Namespace 只有一个 ResourceQuota |
| 存储类未指定 | must specify storage class |
在 PVC 中指定 storageClassName |
容量规划协同： ResourceQuota 是容量规划的执行层。在设置配额前，应通过历史监控数据（如 Prometheus）分析 Namespace 的资源使用趋势，设置合理的 Hard 值。建议预留 20% 的缓冲空间，避免频繁触发配额拒绝。
4.7 多租户场景下的配额策略
在共享集群中，推荐使用以下策略分配 ResourceQuota：
- 按团队分配： 每个团队一个 Namespace，配额基于团队历史使用量 + 预期增长。
- 按环境分配： 开发、测试、生产环境使用不同配额，生产环境配额更严格。
- 动态调整： 结合 Cluster Autoscaler 和 VPA，当集群资源充足时临时放宽配额。
- 审计与告警： 设置配额使用率告警（如使用量达到 80% 时触发通知）。