📚 课程目录第3章 ResourceQuota创建与配置

3、ResourceQuota 创建与配置：YAML 示例、kubectl apply、查看配额状态

在多租户集群中，ResourceQuota 是租户资源边界的“第一道防线”。本章将演示如何通过 YAML 声明式定义配额、使用 kubectl apply 提交到集群，并通过多种命令查看配额生效状态。掌握这些操作是后续诊断配额冲突的基础。

3.1 标准 ResourceQuota YAML 结构

一个完整的 ResourceQuota 对象包含 apiVersion、kind、metadata 和 spec 四个核心字段。spec.hard 定义资源上限，spec.scopes 可选地限定配额生效范围。

字段路径	必填	说明	示例值
`apiVersion`	是	API 版本	`v1`
`kind`	是	资源类型	`ResourceQuota`
`metadata.name`	是	配额名称，需在命名空间内唯一	`tenant-a-quota`
`metadata.namespace`	是	配额绑定的命名空间	`tenant-a`
`spec.hard`	是	资源硬限制键值对	`pods: "10"`
`spec.scopes`	否	配额生效范围（如 `BestEffort`）	`[NotTerminating]`

3.2 完整 YAML 示例：多维度配额

以下 YAML 为租户 team-alpha 定义了一套涵盖计算资源、存储资源与核心对象数量的配额：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-alpha-quota
  namespace: team-alpha
spec:
  hard:
    # 计算资源
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    # 存储资源
    requests.storage: "50Gi"
    persistentvolumeclaims: "5"
    # 核心对象
    pods: "20"
    services: "10"
    secrets: "20"
    configmaps: "20"
    replicationcontrollers: "10"
    resourcequotas: "1"
    services.loadbalancers: "2"
    services.nodeports: "3"

最佳实践：始终同时设置 requests 和 limits，避免因只限制 limits 导致 Pod 请求过量调度。对于存储，建议同时限制 requests.storage 和 persistentvolumeclaims 数量，防止单个 PVC 过大。

3.3 使用 kubectl apply 创建配额

将上述 YAML 保存为 quota-team-alpha.yaml，执行以下命令创建配额：

# 创建命名空间（如果尚未创建）
kubectl create namespace team-alpha

# 应用 ResourceQuota
kubectl apply -f quota-team-alpha.yaml

# 验证创建结果
kubectl get resourcequota -n team-alpha

输出示例：

NAME               AGE
team-alpha-quota   12s

3.4 查看配额状态：三种核心命令

创建完成后，需要确认配额是否生效以及当前使用量。以下三种命令覆盖不同粒度的查看需求：

查看概要：kubectl get quota -n <namespace> —— 显示名称和年龄。
查看详细使用量：kubectl describe quota -n <namespace> —— 列出每个资源的 Used 和 Hard 值。
查看 YAML 完整状态：kubectl get quota -n <namespace> -o yaml —— 包含 status.used 字段，适合脚本解析。

执行 kubectl describe quota team-alpha-quota -n team-alpha 的典型输出：

Name:            team-alpha-quota
Namespace:       team-alpha
Resource         Used  Hard
--------         ----  ----
configmaps       2     20
limits.cpu       2     8
limits.memory    4Gi   16Gi
persistentvolumeclaims 0 5
pods             3     20
requests.cpu     1     4
requests.memory  2Gi   8Gi
requests.storage 10Gi  50Gi
secrets          5     20
services         2     10

关键字段解读：Used 列显示当前命名空间内所有资源的总消耗量，Hard 列是配额上限。当 Used 接近或等于 Hard 时，后续创建请求将被拒绝，并返回 403 Forbidden 错误。

3.5 配额创建与状态检查流程

下图展示了从 YAML 定义到配额生效的完整链路，以及管理员如何通过命令获取状态反馈：

3.6 常见创建错误与排查

错误现象	可能原因	解决方案
`Error from server (AlreadyExists)`	同一命名空间下配额名称重复	使用 `kubectl delete quota <name> -n <ns>` 删除旧配额后重新创建
`error: unable to parse`	YAML 缩进错误或字段名拼写错误	使用 `kubectl apply --dry-run=client -f file.yaml` 预校验
配额创建成功但 `Used` 显示为 `0`	命名空间内尚无匹配资源，或配额 `scopes` 过滤了现有资源	检查 `spec.scopes` 配置，确认资源类型是否在配额范围内
`Forbidden: exceeded quota` 立即出现	当前命名空间已有资源超出新配额上限	先清理超量资源，或适当放宽配额 `Hard` 值

3.7 使用 --dry-run 预检 YAML

在正式提交前，推荐使用 --dry-run=client 进行客户端预检，避免语法错误导致集群拒绝：

kubectl apply -f quota-team-alpha.yaml --dry-run=client -o yaml

该命令会解析 YAML 并输出最终提交的对象，但不实际写入 etcd。如果输出中包含完整的 spec.hard 字段且无错误提示，说明 YAML 格式正确。

注意：--dry-run=client 只能检查客户端语法，无法检测配额值是否与集群现有资源冲突（如配额设置低于当前使用量）。后者需要通过 kubectl describe quota 查看 Used 与 Hard 的对比来确认。

3.8 多租户场景下的配额初始化清单

在为每个租户创建配额时，建议遵循以下初始化步骤，确保配额与租户实际需求匹配：

评估基线：根据租户承诺的 SLA 确定 CPU/Memory 的 requests 和 limits。
设置对象上限：限制 Pod、Service、ConfigMap 数量，防止资源泄露。
预留存储配额：结合存储类设置 requests.storage 上限。
应用并验证：使用 kubectl apply 创建后，立即执行 kubectl describe quota 确认 Used 初始值为 0。
通知租户：将配额上限文档化，避免租户在创建资源时遇到意外拒绝。