3. ResourceQuota 实战配置：为 Namespace 设置资源预算

ResourceQuota 是 Kubernetes 中实现多租户资源隔离与成本控制的核心策略对象。通过为每个 Namespace 配置 ResourceQuota，平台团队可以精确限制 CPU、内存、存储以及各类对象（Pod、Service、ConfigMap 等）的数量上限，防止单个团队或应用“资源暴走”影响集群整体稳定性。本节将围绕三类配额进行实战配置：计算资源配额、存储资源配额和对象数量配额。

3.1 计算资源配额：CPU 与内存上限

计算资源配额控制 Namespace 内所有 Pod 的 CPU 和内存总和上限，分为 Requests（请求量）和 Limits（限制量）两个维度。Requests 用于调度决策，Limits 用于运行时压制。

成本调优要点：设置 Limits 配额可防止 Pod 突发占用过多宿主机资源；设置 Requests 配额可确保调度公平性。建议为生产 Namespace 同时配置 requests.cpu、requests.memory、limits.cpu、limits.memory 四项。

3.1.1 配置示例：计算资源 ResourceQuota

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "4"        # 所有 Pod CPU Request 总和不超过 4 核
    requests.memory: "8Gi"   # 所有 Pod Memory Request 总和不超过 8 GiB
    limits.cpu: "8"          # 所有 Pod CPU Limit 总和不超过 8 核
    limits.memory: "16Gi"    # 所有 Pod Memory Limit 总和不超过 16 GiB

3.1.2 配额生效验证

创建 ResourceQuota 后，使用 kubectl describe quota compute-quota -n team-alpha 查看当前使用量。若新创建 Pod 的请求量超出剩余配额，API Server 将拒绝创建并返回 403 Forbidden 错误。

常见错误：未设置 Limits 时，Pod 可能使用宿主机全部空闲资源，导致成本失控。建议在 ResourceQuota 中同时限制 requests 和 limits，并保持 limits/requests 比例不超过 2:1。

3.2 存储资源配额：持久卷声明上限

存储配额控制 Namespace 内所有 PersistentVolumeClaim（PVC）的存储总量上限，支持按存储类（StorageClass）分别限制。

3.2.1 配置示例：存储 ResourceQuota

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-quota
  namespace: team-alpha
spec:
  hard:
    persistentvolumeclaims: "10"              # PVC 对象总数不超过 10 个
    requests.storage: "500Gi"                 # 所有 PVC 存储总量不超过 500 GiB
    ssd.storageclass.storage.k8s.io/requests.storage: "200Gi"  # SSD 存储类总量不超过 200 GiB
    hdd.storageclass.storage.k8s.io/requests.storage: "300Gi"  # HDD 存储类总量不超过 300 GiB
成本优化提示：为不同存储类设置独立配额，可引导团队优先使用低成本存储（如 HDD），避免高成本 SSD 被非关键应用占用。定期审计 PVC 实际使用率，回收闲置卷。

3.3 对象数量配额：控制资源密度

对象数量配额限制 Namespace 内各类 Kubernetes 对象的最大数量，防止单个 Namespace 创建过多对象导致 etcd 压力过大或 API Server 响应变慢。

3.3.1 常用对象配额项

配额键 作用对象 典型上限 成本影响
pods Pod 总数 100 控制并发 Pod 数量，间接限制资源消耗
services Service 总数 50 减少不必要的 Service 资源浪费
configmaps ConfigMap 总数 50 避免大量小 ConfigMap 占用 etcd 存储
secrets Secret 总数 50 控制敏感信息数量，降低管理成本
persistentvolumeclaims PVC 总数 20 限制存储卷数量，减少底层存储开销

3.3.2 配置示例：对象数量 ResourceQuota

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

3.4 综合 ResourceQuota 配置与校验流程

下图展示了为 Namespace 设置完整资源预算的配置流程与校验关系：

ResourceQuota 综合配置与校验流程 1. 创建 Namespace 2. 计算资源配额 CPU / Memory 3. 存储资源配额 PVC 数量 / 存储总量 4. 对象数量配额 Pod / Service / ConfigMap 5. 校验与审计 Namespace 资源预算视图 • CPU Request: 2.5 / 4 核 • Memory Request: 5 / 8 GiB • PVC 存储: 120 / 500 GiB • Pod 数量: 18 / 50 • Service 数量: 5 / 20 • ConfigMap 数量: 8 / 30 成本优化建议 • 闲置 PVC 回收：3 个未挂载 • 超配 Pod 降配：2 个 CPU 闲置 • 存储类迁移：SSD→HDD 可节省 40% • 删除无主 ConfigMap：5 个 • 合并小 Service：3 个可合并

3.5 多配额组合与冲突处理

当 Namespace 同时存在多个 ResourceQuota 对象时，Kubernetes 会取所有配额的交集作为实际生效上限。例如，若两个 ResourceQuota 分别限制 Pod 数量为 50 和 30，则实际生效上限为 30。

最佳实践：建议每个 Namespace 只使用一个 ResourceQuota 对象，将所有配额项集中管理。若必须使用多个，需确保配额项不冲突，并定期使用 kubectl describe quota 检查生效状态。

3.6 配额变更与成本调优联动

ResourceQuota 的调整应基于实际使用数据。通过 kubectl get quota -n team-alpha -o yaml 查看当前使用量，结合 Prometheus 监控数据，可以识别出资源浪费点：

  • CPU 超配严重：若 limits.cpu 使用率长期低于 50%，可适当降低配额上限，释放资源给其他 Namespace。
  • 存储闲置：若 PVC 存储使用率低于 30%，可回收未挂载卷或迁移至低成本存储类。
  • 对象数量膨胀：若 ConfigMap 或 Secret 数量接近上限但实际使用率低，应清理冗余对象。
注意：降低配额上限可能导致正在运行的 Pod 被驱逐（若 Pod 的 Request 超过新配额）。建议在业务低峰期调整，并提前通知相关团队。

3.7 实战校验命令速查

操作 命令 说明
创建配额 kubectl apply -f quota.yaml 应用 ResourceQuota YAML 文件
查看配额详情 kubectl describe quota <name> -n <ns> 显示配额上限与当前使用量
列出所有配额 kubectl get quota -n <ns> 查看 Namespace 下所有 ResourceQuota
检查 Pod 是否被配额限制 kubectl describe pod <pod> -n <ns> 查看 Events 中是否有配额拒绝记录
更新配额 kubectl edit quota <name> -n <ns> 在线修改配额值

通过以上配置与校验方法，平台团队可以为每个 Namespace 建立清晰的资源预算边界，在保障应用稳定运行的同时，实现可量化的成本控制。

← 上一章 📖 返回目录 下一章 →