2. 资源配额基础：Kubernetes ResourceQuota 与 LimitRange 的工作原理与配置语法

在 GitOps 交付体系中，资源配额（Resource Quota）与限制范围（LimitRange）是保障多团队、多环境集群稳定性的核心机制。ResourceQuota 从总量维度限制命名空间内的资源消耗上限，防止单个应用或团队“抢占”集群全部资源；LimitRange 则从单 Pod/容器维度设置默认请求（Request）与限制（Limit），避免未显式声明资源规格的 Pod 因默认值不合理而引发调度失败或资源争抢。两者配合使用，可构建“总量封顶 + 单实例约束”的双层资源治理模型。

2.1 ResourceQuota：命名空间资源总量控制

ResourceQuota 是 Kubernetes 内置的准入控制（Admission Controller）资源对象，作用于命名空间（Namespace）级别。当集群启用 ResourceQuota 准入插件后，每个命名空间内所有 Pod、Service、PersistentVolumeClaim 等对象的资源消耗总和不得超过 Quota 中声明的硬限制（Hard）。

2.1.1 核心字段与配置语法

以下是一个典型的 ResourceQuota YAML 配置，涵盖计算资源（CPU/内存）、存储资源（PVC 容量）与对象数量（Pod/Service 等）三类限制：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    # 计算资源：所有 Pod 的 requests 总和上限
    requests.cpu: "4"
    requests.memory: "8Gi"
    # 计算资源：所有 Pod 的 limits 总和上限
    limits.cpu: "8"
    limits.memory: "16Gi"
    # 存储资源：PVC 请求总容量
    requests.storage: "100Gi"
    # 对象数量限制
    pods: "20"
    services: "10"
    persistentvolumeclaims: "5"
    configmaps: "10"
    secrets: "10"
    replicationcontrollers: "10"

2.1.2 工作原理：准入控制与资源审计

ResourceQuota 的工作流程分为创建/更新校验和实时审计两个阶段：

1. 准入校验：当用户通过 API Server 创建或更新 Pod/PVC 等资源时，ResourceQuota 准入控制器会计算当前命名空间内该类型资源的已使用量（Usage），加上新请求的资源量，判断是否超过 spec.hard 中声明的上限。若超过，则拒绝请求并返回 403 Forbidden 错误。
2. 实时审计：Kubernetes 控制面会持续跟踪每个命名空间的资源使用量，并更新 ResourceQuota 的 status 字段。运维人员可通过 kubectl describe resourcequota <name> -n <namespace> 查看当前使用量与硬限制的对比。

2.2 LimitRange：单 Pod/容器资源约束与默认值注入

LimitRange 在命名空间级别为每个 Pod 或容器设置最小/最大资源约束，并在用户未显式声明 resources.requests 或 resources.limits 时注入默认值。这解决了两个常见问题：

• 资源浪费：未设置 requests 的 Pod 可能被调度到资源紧张的节点，导致节点过载。
• 配额绕过：若 Pod 不声明 limits，ResourceQuota 的 limits.cpu 限制将无法生效，用户可能通过不设 limits 的方式“绕过”总量控制。

2.2.1 配置语法与字段解析

apiVersion: v1
kind: LimitRange
metadata:
  name: team-a-limits
  namespace: team-a
spec:
  limits:
  - type: Container
    min:
      cpu: "100m"
      memory: "64Mi"
    max:
      cpu: "2"
      memory: "4Gi"
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"
    maxLimitRequestRatio:
      cpu: "4"
      memory: "4"
  - type: Pod
    max:
      cpu: "4"
      memory: "8Gi"

2.3 ResourceQuota 与 LimitRange 的协同工作流

下图展示了在 GitOps 交付流水线中，ResourceQuota 与 LimitRange 如何协同完成资源准入校验：

2.4 GitOps 环境下的配置策略与常见故障

2.4.1 多环境差异化配置

在 GitOps 仓库中，建议按环境目录结构组织 ResourceQuota 与 LimitRange 配置：

gitops-repo/
├── base/
│   ├── kustomization.yaml
│   ├── resourcequota.yaml        # 通用 Quota 模板（占位值）
│   └── limitrange.yaml           # 通用 LimitRange 模板
├── overlays/
│   ├── dev/
│   │   ├── kustomization.yaml
│   │   ├── resourcequota-patch.yaml  # 开发环境：CPU 4核，内存 8Gi
│   │   └── limitrange-patch.yaml     # 开发环境：默认 200m CPU
│   ├── staging/
│   │   ├── kustomization.yaml
│   │   ├── resourcequota-patch.yaml  # 预发环境：CPU 16核，内存 32Gi
│   │   └── limitrange-patch.yaml     # 预发环境：默认 500m CPU
│   └── prod/
│       ├── kustomization.yaml
│       ├── resourcequota-patch.yaml  # 生产环境：CPU 64核，内存 128Gi
│       └── limitrange-patch.yaml     # 生产环境：默认 1 CPU

2.4.2 常见故障排查清单

2.5 资源配额校准的监控与告警

仅配置 ResourceQuota 和 LimitRange 还不够，必须建立配额使用率监控机制，避免在配额耗尽时才被动响应。推荐在 Prometheus 中采集以下指标：

• kube_resourcequota{namespace="team-a", resource="requests.cpu"}：当前 CPU 请求使用量
• kube_resourcequota{namespace="team-a", resource="limits.memory"}：当前内存限制使用量
• kube_resourcequota{namespace="team-a", resource="pods"}：当前 Pod 数量

在 Grafana 中设置告警规则：当配额使用率超过 80% 时触发 Warning，超过 95% 时触发 Critical。告警通知应发送至 GitOps 团队的即时通讯工具（如 Slack、钉钉），以便及时调整配额或扩容集群。