📚 课程目录第3章命名空间资源配额

3. 命名空间资源配额：ResourceQuota 对象、CPU/内存配额、存储配额、对象数量配额

在多租户集群中，如果没有资源配额约束，单个租户（命名空间）可能因异常或恶意行为消耗集群全部资源，导致其他租户的服务不可用。Kubernetes 的 ResourceQuota 对象正是为此而生——它为每个命名空间设置资源使用上限，确保租户间的资源公平性与集群稳定性。

3.1 ResourceQuota 对象概述

ResourceQuota 是一个命名空间级别的 API 资源，由集群管理员创建。它定义了两大类配额：计算资源配额（CPU、内存）和 对象数量配额（Pod、Service、PVC 等）。一旦启用，命名空间中所有 Pod 的容器必须设置 requests 和 limits，否则创建将被拒绝。

关键原则： ResourceQuota 是“硬上限”（hard limit），而非“软限制”。当命名空间资源使用量达到配额时，后续创建请求会返回 403 Forbidden。配额不会影响已有资源，仅阻止新资源的创建。

3.2 CPU 与内存配额

CPU 和内存配额是资源隔离的核心。Kubernetes 允许对 requests（预留量）和 limits（上限）分别设置配额，实现精细控制。

资源类型	配额字段	单位	说明
CPU	`requests.cpu`	核心数（如 1、500m）	所有容器 CPU requests 总和上限
CPU	`limits.cpu`	核心数	所有容器 CPU limits 总和上限
内存	`requests.memory`	字节（如 1Gi、512Mi）	所有容器内存 requests 总和上限
内存	`limits.memory`	字节	所有容器内存 limits 总和上限

以下是一个典型的 ResourceQuota YAML 示例，为命名空间 team-alpha 设置 CPU 和内存配额：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"

注意： 如果命名空间中已有 Pod 未设置 requests/limits，创建 ResourceQuota 后这些 Pod 不会受影响，但后续创建新 Pod 时必须显式设置。建议在创建命名空间时即关联 ResourceQuota，避免遗留问题。

3.3 存储配额

存储配额控制命名空间内所有 PersistentVolumeClaim（PVC）的存储总量。Kubernetes 支持按存储类（StorageClass）分别设置配额，实现不同性能层级的存储隔离。

配额字段	说明
`requests.storage`	所有 PVC 存储请求总和上限（如 100Gi）
`persistentvolumeclaims`	PVC 对象数量上限
`requests.storage/<storage-class-name>`	按存储类细分的存储配额

示例：为命名空间 team-beta 设置存储配额，限制 SSD 存储类总量不超过 50Gi：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-quota
  namespace: team-beta
spec:
  hard:
    requests.storage: "100Gi"
    persistentvolumeclaims: "10"
    requests.storage/ssd-storage: "50Gi"

3.4 对象数量配额

对象数量配额用于限制命名空间中各类 Kubernetes 资源的数量，防止单个租户创建过多对象导致 API Server 压力过大或 etcd 存储膨胀。

配额字段	资源类型	典型上限
`pods`	Pod	100
`services`	Service	50
`configmaps`	ConfigMap	100
`secrets`	Secret	50
`persistentvolumeclaims`	PVC	20
`replicationcontrollers`	ReplicationController	20
`resourcequotas`	ResourceQuota	1

完整示例：为命名空间 team-gamma 设置对象数量配额：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-count-quota
  namespace: team-gamma
spec:
  hard:
    pods: "50"
    services: "20"
    configmaps: "30"
    secrets: "20"
    persistentvolumeclaims: "10"

3.5 ResourceQuota 生效流程与配额监控

下图展示了 ResourceQuota 从创建到生效的完整流程，以及配额耗尽时的拒绝机制：

3.6 配额查看与调试

管理员和租户可以通过以下命令查看命名空间的配额使用情况：

# 查看命名空间的所有 ResourceQuota
kubectl get resourcequota -n team-alpha

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

# 输出示例：
# Name:            compute-quota
# Namespace:       team-alpha
# Resource         Used  Hard
# --------         ---   ---
# requests.cpu     2     4
# requests.memory  4Gi   8Gi
# limits.cpu       3     8
# limits.memory    6Gi   16Gi

  最佳实践：
  为每个租户命名空间创建至少一个 ResourceQuota，覆盖计算资源和对象数量。
使用 requests.storage/<storage-class> 按存储类隔离，避免租户占用高性能存储。
结合 LimitRange 对象设置 Pod 默认 requests/limits，防止因未设置配额导致创建失败。
定期监控 kubectl describe resourcequota 的 Used 字段，接近 Hard 时及时扩容或通知租户清理。

3.7 多租户场景下的配额规划策略

下表总结了不同租户类型下的推荐配额配置，帮助你在实际集群中快速决策：

租户类型	CPU 配额	内存配额	存储配额	Pod 数量
开发/测试	requests: 2, limits: 4	requests: 4Gi, limits: 8Gi	50Gi	20
生产-小型	requests: 8, limits: 16	requests: 16Gi, limits: 32Gi	200Gi	50
生产-大型	requests: 32, limits: 64	requests: 64Gi, limits: 128Gi	1Ti	200
系统组件	requests: 4, limits: 8	requests: 8Gi, limits: 16Gi	100Gi	30

通过合理配置 ResourceQuota，你可以为每个租户划定清晰的资源边界，避免“吵闹邻居”问题，同时为集群管理员提供可观测的配额使用数据，支撑容量规划与成本分摊。