📚 课程目录第4章创建第一个 Resource Quota

4. 创建第一个 Resource Quota：编写 YAML 定义 CPU 与内存配额

在 Kubernetes 集群中实施资源管控的第一步，是编写一个声明式的 Resource Quota 对象。本节将引导你从零创建第一个配额定义，并通过 kubectl apply 将其部署到目标命名空间。

4.1 配额定义的核心字段

一个标准的 Resource Quota YAML 包含以下关键部分：

字段路径	说明	示例值
`apiVersion`	Resource Quota 所属 API 版本	`v1`
`kind`	资源对象类型	`ResourceQuota`
`metadata.name`	配额名称，在命名空间内唯一	`compute-quota`
`metadata.namespace`	配额生效的目标命名空间	`team-alpha`
`spec.hard`	硬性限制的键值对集合	`requests.cpu: "4"`

4.2 编写第一个 YAML 定义

以下 YAML 为命名空间 team-alpha 定义了 CPU 与内存的请求（requests）和限制（limits）配额：

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"

字段解读：

requests.cpu：所有 Pod 的 CPU 请求总和不得超过 4 核。
requests.memory：所有 Pod 的内存请求总和不得超过 8 GiB。
limits.cpu：所有 Pod 的 CPU 限制总和不得超过 8 核。
limits.memory：所有 Pod 的内存限制总和不得超过 16 GiB。

4.3 部署与验证流程

将上述 YAML 保存为 compute-quota.yaml，然后执行以下命令：

# 部署 Resource Quota
kubectl apply -f compute-quota.yaml

# 查看已创建的配额
kubectl get resourcequota -n team-alpha

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

部署成功后，kubectl describe 的输出会显示当前已使用量（Used）与硬限制（Hard）的对比，帮助运维人员快速掌握资源水位。

4.4 配额生效后的行为变化

一旦 Resource Quota 部署完成，Kubernetes 准入控制器会在以下场景触发校验：

创建 Pod：如果新 Pod 的 requests/limits 导致命名空间总量超出配额，API Server 会拒绝创建并返回错误。
更新 Pod：如果更新操作增加了资源请求或限制，且超出剩余配额，同样会被拒绝。
创建其他资源：配额同样作用于 Deployment、StatefulSet、Job 等控制器创建的 Pod。

常见陷阱：如果命名空间中已存在 Pod 的总资源请求已经超过新配额的硬限制，kubectl apply 仍然会成功创建 Resource Quota 对象，但后续任何新的 Pod 创建操作都会被拒绝，直到现有 Pod 被删除或配额被放宽。

4.5 配额声明式管理的核心流程

下图展示了从 YAML 编写到配额生效的完整链路：

4.6 多资源类型配额对比

除了 CPU 和内存，Resource Quota 还可以管理存储和对象数量。下表对比了常见的配额维度：

资源类别	配额键	单位	典型场景
CPU 请求	`requests.cpu`	核数（如 `4`）	限制总 CPU 预留量
CPU 限制	`limits.cpu`	核数（如 `8`）	限制总 CPU 突发上限
内存请求	`requests.memory`	字节（如 `8Gi`）	限制总内存预留量
内存限制	`limits.memory`	字节（如 `16Gi`）	限制总内存突发上限
存储声明	`requests.storage`	字节（如 `100Gi`）	限制 PVC 总容量
Pod 数量	`count/pods`	整数	限制命名空间 Pod 总数

4.7 最佳实践与避坑指南

  推荐做法：
  始终为每个命名空间设置 requests.cpu 和 requests.memory，防止资源争抢。
在测试环境先使用宽松配额，观察实际使用量后再收紧。
结合 LimitRange 为未显式设置 requests/limits 的 Pod 提供默认值。

常见错误：

忘记指定 metadata.namespace，导致配额应用到 default 命名空间。
配额值写为小数（如 0.5）时未使用字符串引号，YAML 解析可能失败。
只设置 limits 而不设置 requests，导致 Pod 调度时资源预留不足。

通过本节操作，你已经成功创建并部署了 Kubernetes 集群中的第一个 Resource Quota。这个声明式对象将自动约束命名空间内所有工作负载的资源使用，为后续的证书轮换与发布证据管理提供了稳定的资源基线。