3. Kubernetes 资源配额（ResourceQuota）概念：命名空间级别配额、CPU/内存限制、存储与对象计数

在 GitOps 交付流水线中，资源配额（ResourceQuota）是保障多租户集群稳定性与公平性的第一道防线。ResourceQuota 作用于命名空间级别，通过硬性限制防止单个团队或应用过度消耗集群资源，从而避免“吵闹邻居”效应。本章将系统解析 ResourceQuota 的核心概念、配置维度与实战校准方法。

3.1 命名空间级别配额：作用域与生效机制

ResourceQuota 是 Kubernetes 内置的准入控制机制，其作用域严格限定在单个命名空间内。一旦在命名空间中创建 ResourceQuota 对象，该命名空间下所有 Pod、PersistentVolumeClaim（PVC）、Service 等资源的创建与更新请求都必须通过配额校验。

关键原则： ResourceQuota 是“硬限制”（Hard Limit），而非“请求限制”（Request Limit）。超过配额的操作会被 API Server 直接拒绝，并返回 403 Forbidden 错误。

以下是一个典型的 ResourceQuota YAML 配置示例，展示了命名空间级别的多维限制：

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"
    persistentvolumeclaims: "10"
    requests.storage: "100Gi"
    pods: "20"
    services: "10"
    configmaps: "15"
    secrets: "15"
    count/deployments.apps: "5"
    count/statefulsets.apps: "3"
最佳实践： 在 GitOps 仓库中，将 ResourceQuota 与命名空间声明（Namespace YAML）放在同一目录下，通过 Kustomize 或 Helm 统一管理，确保配额与命名空间生命周期一致。

3.2 CPU 与内存限制：Requests 与 Limits 的配额映射

ResourceQuota 对 CPU 和内存的限制分为两个维度：requests（预留资源）和 limits（上限资源）。这两个维度独立计数，且必须同时满足才能通过准入检查。

资源类型 配额字段 说明 典型单位
CPU 请求 requests.cpu 所有 Pod 的 CPU request 总和上限 核心数（如 4、0.5）
CPU 上限 limits.cpu 所有 Pod 的 CPU limit 总和上限 核心数（如 8、2）
内存请求 requests.memory 所有 Pod 的内存 request 总和上限 字节（如 8Gi、512Mi）
内存上限 limits.memory 所有 Pod 的内存 limit 总和上限 字节（如 16Gi、1Gi）
常见陷阱： 如果只设置 limits.cpu 而未设置 requests.cpu，Kubernetes 会自动将 request 值设为与 limit 相同。这可能导致实际预留资源超出预期，造成资源浪费。建议在 GitOps 策略中强制同时声明 requests 和 limits。

3.3 存储配额：PVC 数量与总容量双重控制

存储资源的配额管理包含两个独立维度：PVC 对象数量和存储总容量。两者必须同时配置才能有效控制存储消耗。

  • PVC 数量限制： persistentvolumeclaims: "10" —— 限制命名空间内最多可创建 10 个 PVC 对象。
  • 存储总容量限制： requests.storage: "100Gi" —— 限制所有 PVC 的存储请求总和不超过 100Gi。
  • 按 StorageClass 细分： 支持针对特定 StorageClass 设置独立配额，例如 requests.storage/fast-ssd: "50Gi"。
GitOps 校准建议： 在 Helm values 中为每个环境（dev/staging/prod）定义不同的存储配额基线，通过 Git 分支差异自动触发配额变更审批流程。

3.4 对象计数配额：控制 Kubernetes 资源数量

除了计算和存储资源，ResourceQuota 还支持对 Kubernetes 原生对象进行计数限制，防止命名空间内对象数量失控导致 etcd 压力过大。

对象类型 配额字段格式 示例值 适用场景
Pod pods 20 限制并发运行 Pod 数量
Service services 10 控制微服务数量
ConfigMap configmaps 15 防止配置对象泛滥
Secret secrets 15 控制敏感信息数量
Deployment count/deployments.apps 5 限制工作负载数量
StatefulSet count/statefulsets.apps 3 控制有状态服务数量
注意： 对象计数配额使用 count/<resource>.<group> 格式。对于核心 API 组（如 Pod、Service），可直接使用简写 pods、services；对于 apps 组资源，必须使用完整格式 count/deployments.apps。

3.5 ResourceQuota 校验流程与 Scope 选择器

ResourceQuota 支持通过 scopes 字段进一步细化配额作用范围，实现更精细的资源管控。

ResourceQuota 准入校验流程 创建/更新请求 ResourceQuota 准入控制器 Scope 匹配检查 资源用量累加 拒绝请求（403） 允许创建/更新 Scope 支持：BestEffort / NotBestEffort / Terminating / NotTerminating

Scope 选择器允许配额仅对特定 QoS 类或生命周期状态的 Pod 生效，常见组合包括：

  • BestEffort： 仅限制 QoS 为 BestEffort 的 Pod（未设置 requests/limits）。
  • NotBestEffort： 限制 QoS 为 Burstable 或 Guaranteed 的 Pod。
  • Terminating： 限制设置了 activeDeadlineSeconds 的 Pod。
  • NotTerminating： 限制未设置 activeDeadlineSeconds 的 Pod。

3.6 配额监控与 GitOps 校准策略

在 GitOps 实践中，ResourceQuota 的配置不是一次性的，而是需要持续校准。以下是通过 kubectl describe quota 查看当前使用量的示例：

# 查看命名空间 team-alpha 的配额使用情况
kubectl describe quota team-alpha-quota -n team-alpha

# 输出示例
Name:            team-alpha-quota
Namespace:       team-alpha
Resource         Used  Hard
--------         ----  ----
requests.cpu     2.5   4
requests.memory  4Gi   8Gi
limits.cpu       5     8
limits.memory    10Gi  16Gi
pods             12    20
persistentvolumeclaims  3  10
requests.storage       30Gi  100Gi
GitOps 校准流程：
  1. 通过 Prometheus 或 kubectl top 采集实际资源使用趋势。
  2. 在 Git 仓库中更新 ResourceQuota YAML 的 hard 字段。
  3. 提交 PR 触发 CI 流水线，自动计算配额利用率并生成校准建议。
  4. 合并后 Argo CD 自动同步至目标集群。
← 上一章 📖 返回目录 下一章 →